[HN Gopher] Android Studio's "Code contains easter egg" inspecti...
___________________________________________________________________
Android Studio's "Code contains easter egg" inspection (2019)
Author : mqus
Score : 119 points
Date : 2022-11-01 12:24 UTC (10 hours ago)
(HTM) web link (wh0.github.io)
(TXT) w3m dump (wh0.github.io)
| dontbenebby wrote:
| methyl wrote:
| Is this inspection an easter egg itself?
| lawgimenez wrote:
| It reminded me of isUserAGoat
| https://developer.android.com/reference/android/os/UserManag...()
| mysterydip wrote:
| "Used to determine whether the user making this call is subject
| to teleportations."
|
| As a non-android developer, I am now more confused.
| olibhel wrote:
| As a chromium task manager, I count teleported goats.
| ddulaney wrote:
| It's a reference to a very old (and since removed, at least
| in my version) Chrome Easter egg where Chrome Task Manager
| had a hidden column called "Goats Teleported".
|
| See
| https://bugs.chromium.org/p/chromium/issues/detail?id=31482
| hbn wrote:
| I'm pretty sure it used to return true if the user had Goat
| Simulator installed. Never played the game but I'm assuming
| there's something to do with teleportation in it.
| exikyut wrote:
| Yeah, it did O.o 2249 public boolean
| isUserAGoat() { 2250 if
| (mContext.getApplicationInfo().targetSdkVersion >=
| Build.VERSION_CODES.R) { 2251 return false;
| 2252 } 2253 // Caution: This is NOT
| @UserHandleAware (because mContext is getApplicationContext
| and 2254 // can hold a different userId), but for
| R+ it returns false, so it doesn't matter anyway.
| 2255 return mContext.getPackageManager() 2256
| .isPackageAvailable("com.coffeestainstudios.goatsimulator")
| ; 2257 }
|
| https://cs.android.com/android/platform/superproject/+/mast
| e...
| codedokode wrote:
| There is also a constant named "DISALLOW_FUN" [1]. Probably
| intended for corporate devices.
|
| [1]
| https://developer.android.com/reference/android/os/UserManag...
| jsmith45 wrote:
| Apparently that user restriction is actually tested in two
| places in the codebase. Having the restiction on your user
| will prevent access to the Android version easter egg. It
| will also prevent access to debug features in whatever
| "DocumentUI" is.
|
| I suppose third party apps could also test for it, and do
| things with it, but is is really just intended as a joke.
| lawgimenez wrote:
| Nice!
| mywittyname wrote:
| Wasn't there a function like, "isUserAMonkey()"? I recall
| seeing that years ago and got a chuckle out of it, but that
| reference doesn't include the function call.
| lawgimenez wrote:
| Yea there is that method. I think it has something to do with
| chaos monkey testing or some sort.
| [deleted]
| lupire wrote:
| Why would they use "Easter Egg" to describe "lightly obfuscated
| code"? They are two different things. Easter Eggs have no special
| need for obfuscation in source code, just in UI.
|
| Especially for Java, not JavaScript where source code is at least
| slightly relevant to the end user experience?
| Closi wrote:
| Probably because it's not looking for lightly obfuscated code,
| it's looking for hidden code (hidden by a unicode escape
| sequence).
| muststopmyths wrote:
| Because frequently Easter eggs are frowned upon at large
| companies and I suppose developers may still be trying to sneak
| them in by obfuscation. So this linter is trying to catch those
| cases
| MereInterest wrote:
| Historically, Easter eggs were implemented as a way of having
| a verifiable resume. To reduce employee bargaining power,
| companies didn't include developer names in software credits.
| So even if you worked on project X, even if you designed and
| wrote the entire program as was common at the time, the
| developer didn't have any proof they could use on their
| resume. But, if you sneak in an Easter Egg, especially one
| that displays your name, you could use that as proof.
|
| So, given the antagonistic relationship in which Easter Eggs
| originated, I'm not surprised that large companies would
| continue that antagonistic relationship.
|
| Source:
| https://en.wikipedia.org/wiki/Easter_egg_(media)#Origin
| bitwize wrote:
| In Japan, game companies forbade programmers from putting
| their real names in their games. It was an anti-poaching
| move, the studios didn't want their programmers hired out
| from under them.
|
| So the game programmers put aliases in instead. Hence why
| you see such strange names in games like Yu2, Nakazoo, Faw,
| S.Miyahon (who is actually Shigeru Miyamoto), etc.
| kabdib wrote:
| I stuck difficult-to-find easter eggs in my game cartridges
| precisely because I wanted to prove that I'd written them.
| The eggs are not spectacular, nor do they subtract from the
| player experience. It was just signing my name, when I
| wasn't allowed to.
|
| https://kotaku.com/donkey-kong-easter-egg-
| discovered-26-year...
| eesmith wrote:
| Your source points out while the term "Easter egg" was
| coined to describe a circumstance you mentioned, the
| concept is older, and used for circumstances other than
| what you described.
| jjeaff wrote:
| And we all know that the first and original use of a word
| is the only correct use of the word.
| BoorishBears wrote:
| Realistically this would be the best way to get your easter
| egg caught.
|
| Unicode escape characters in comments will draw most people's
| eyes immediately, it just doesn't look natural.
|
| Instead write the easter egg in completely plain sight
| attached to a boring change, make sure the PR is passing CI
| on the first try, and a reviewer will skim for exactly .5
| seconds before replying "LGTM!".
| JTbane wrote:
| For better effect, put the easter egg in a file and
| directory starting with "z" so it appears last in the pull
| request.
| marcosdumay wrote:
| zlib-interface: contains functions for displaying the
| author's name.
| BoorishBears wrote:
| People usually scroll straight down, so their eyes will
| dwell on the last contents
|
| Just past the fold at the top, but out of view from the
| bottom, would be the ideal place
| djur wrote:
| It seems like it could be a way to draw attention to
| potentially concealed code without making an inflammatory and
| possibly false accusation. Or it could just be that someone at
| JetBrains used this trick to hide an Easter Egg at some point.
| pabs3 wrote:
| This reminds me a bit of the "Trojan Source" paper.
|
| https://trojansource.codes/
| AshamedCaptain wrote:
| I do think that "Face Screaming in Fear" is indeed the only
| appropriate reaction to a compiler parsing escape sequences
| outside of character/string literals.
|
| Also, it seems strange to add a detector for this specific case
| instead of actually fixing the IDE's parser to match the
| language's correct syntax rules.
| cbhl wrote:
| My understanding is that the highlighting parser _is_ fixed to
| intentionally mis-parse to guarantee reasonable runtime
| complexity, and the lint check is a band-aid on top of it for a
| common type of adversarial input.
|
| If you do the full parse you can end up with adversarial inputs
| that result in cubic or exponential run-time complexity (see,
| for example, Pygments CVEs for comparable examples in this
| domain).
| kllrnohj wrote:
| Maybe jetbrains didn't want to fix the IDE parser for some
| reason? Although there's still value to that lint warning as
| lint isn't coupled to the IDE. So you'd get value out of that
| warning regardless of if you're using Android Studio or not, as
| well as value in CI or similar.
| [deleted]
| usrusr wrote:
| Fixing the parser as in properly switching back from comment
| coloring to code coloring? Won't tell you anything unless you
| look, and you might still miss it. The linter will ring alarm
| bells that someone is trying to hide code even if you never had
| the file in question on the screen.
|
| I feel tempted to bring up the counter argument "but someone
| should look at untrusted code thoroughly enough to not miss it
| anyways!", but that would be like abolishing safety belts and
| airbags because surely people would drive more safely.
| lolinder wrote:
| The only reason why this makes any sense as a threat vector
| is because Java code highlighting parsers and javac work
| differently. Sure, someone can still try it, but if they knew
| that every code highlighter would render it correctly they
| wouldn't bother.
| moffkalast wrote:
| And is also the appropriate reaction to using Android Studio.
| tadfisher wrote:
| I see you didn't use the Eclipse plugin (with Ant scripts,
| yay!).
|
| Dang I'm old.
| slaymaker1907 wrote:
| I'm guessing it's because handling escape sequences like these
| would have to be done in a separate pass over the source code.
| The escape sequence could be part of a separate token so you
| need to first resolve these escape sequences and then do
| tokenizing.
| zerocrates wrote:
| The fact that Java allows and parses Unicode escapes just
| everywhere in source is a real surprise. That it's the same
| syntax you see other languages use for string-literal-only
| escapes _and_ it 's the same as Java's own other character
| literal sequences really adds to the surprise.
|
| Is there any _non_ -sneaky usage of this feature out there in
| the world? I suppose given the massive amount of Java, there
| probably is.
| hahahGetbent wrote:
___________________________________________________________________
(page generated 2022-11-01 23:01 UTC)