Am I the only one not amused by easter eggs in software? It's code that I don't know about doing stuff that I don't know about. More code means more chances for bugs, maybe even bugs that results in security vulnerabilities. If the programmer snuck it in without management approval, it may mean code that isn't as thoroughly tested as the rest of the program.
I see an Easter egg as a sort of "finishing touch" - something added after everything else is done. Thus, if one occurs in software that appears to be buggy and/or unfinished, it definitely creates a bad impression for me, wheres if the software looks nearly perfect it has the opposite effect.
I somewhat agree - but given that no meaningful piece of software has ever shipped without bugs being punted (and bugs that weren't even known about), when is there really time to add an easter egg?
I agree with Easter Eggs in products. That being said another good example of an "Easter Egg gone wrong" was the games in Excel 95 and 97.
Excel 95 had a "Doom"-like 3D game. Excel 97 had a basic flight simulator. These were fun and weren't buggy, but here's the problem:
How much time do you think was lost in classrooms in particular after all the kids discovered there were games they could be playing instead of working? All of the built in Windows games were removed, and Flash/Java weren't installed. But you cannot remove these if you need Excel.
This was a legitimate issue in the 1990s. So much so that the school I attended gave anyone detention caught playing these games during class time(!). Yet every class there would be someone sitting in the corner playing away.
I find it hilarious that you're upset with easter eggs in principle because kids were distracted during class. I'm sure all those kids couldn't hack it in the real world because of these awful distractions.
> I find it hilarious that you're upset with easter eggs in principle because kids were distracted during class.
That's exactly the opposite of what I said, I said I liked Easter Eggs in principle but then gave an example of when they went wrong. The first line of my comment was: "I agree with Easter Eggs in products."
Easter Eggs are good, you just really have to consider the impact they're going to have (in terms of perception, usages, and bugs).
However it is unfortunate that they decided to conflate a product needed in a classroom (namely the Office suite) and a feature which is not (namely a game).
Microsoft's only responsibility is that their software is fit for purpose, and in this scenario it is not.
edit: 4 people downvoted, not a single reply? This place is turning into Reddit. Pathetic behaviour.
You aren't concerned with 'hidden' code - you're concerned about this now because you know it's there. Because it isn't hidden.
If you're worried about code doing things you don't know about then there's a heck of a lot more to VMWare that you could be concerned with. It's a huge, complex application. A few KB for a hidden game is irrelevant - you don't know what hundreds of MB of it actually does. If you're worried about things being hidden in apps then you run them in a trusted environment on tested hardware after you're audited the code (and removed the easter egg).
The only reason this should worry anyone is because VMWare potentially lost sales to organisations who do need to run audited code. I imagine they would have been supplied a version without the Easter Egg though.
Yes. It's a huge codebase. Why complicate it further by adding something 100% unnecessary? You cannot assume any bit of code no matter how small is irrelevant. If it's there it's potentially exploitable.
Because it's fun. As the industry matures, people seem to lose the sense of humuor - which is sad, because practical jokes and playfullness is what created said industry.
There is a time and place for humor. Important software is not one of them. When I run something on my machine I want it to do exactly what it is supposed to, nothing more and nothing less.
You won't be laughing if $RANDOM_EASTER_EGG has a bug that allows for remote code execution.
> There is a time and place for humor. Important software is not one of them.
Thing is, everyone seems to think the place and time is everywhere but not here and now. Companies today tend to have inflated sense of importance and gloominess stemming from what I believe is a mistaken understanding of professionalism.
> You won't be laughing if $RANDOM_EASTER_EGG has a bug that allows for remote code execution.
Hell yes I'll be laughing, I always laugh from remote code execution bugs ;). Anyway, you can argue that for any piece of code. Sure, an easter egg increases the surface of attack... by 0.1% or something.
Exactly. Anyone who objects to easter eggs because they may accidentally introduce vulnerabilities should be objecting much more strongly to features of the application that they don't need. If you want to know every aspect of a program, then you need to own the code and be brutal about stripping out features that you aren't currently using.
Strongly disagree; appropriate humour in "professional" software is just fine:
$ man tunefs
System Administration Commands tunefs(1M)
NAME
tunefs - tune an existing UFS file system
...
NOTES
You can tune a file-system, but you can't tune a fish.
I'm pretty sure the bulk of the code is in a disk image, and that binary is embedded instead of loaded from disk... the source for the image likely isn't in the same as an integrated egg generally speaking. They likely added one embed statement and a hotkey listener...
No, you're not the only one. I share your concern for all the reasons you cite.
I'm also concerned about the development process itself. Design reviews? Code reviews? Automated testing? CI/CD? What is the impact of an easter egg on these things? Were the eggs noticed and tacitly approved? What does this tell us about the process?
Do I want to rely on the product of that process?
Or are we saying we don't care?
I appreciate the idea behind the easter egg, the little human touch, the little flourish that says "look what I built", I really do. But, fundamentally, the software I use becomes part of the machine - and I want it to behave that way, like a reliable machine that does exactly what I expect and only what I expect. If I want a human touch, I'll reach out to a human. If I want a surprise, I'll read a book or play a game.
Imagine an easter egg in your car's navigation system. Won't that be cool! Not.
Easter eggs, especially in software that should be part of the machine, strike me as the height of unprofessional irresponsible behaviour. An f-u to management and to users that deserves its own resounding f-u, I'll use someone else's professional, reliable tools, thank you.
Were the eggs noticed and tacitly approved? What does this tell us about the process?
It doesn't tell us anything about the production process at VM because we don't know if they were noticed and approved or not noticed. Don't assume either way.
Imagine an easter egg in your car's navigation system.
A programmer that leaves an easter egg in some critical part of the software really isn't worth his salt. For the very first thing, it would be way too obvious (no longer qualifying as an easter egg), and second, for the reasons you mentioned.
The way this is implemented, I can't see any harm: Instead of getting something along the line "BLEEP LOADER NOT FOUND AT 0" (and you'll still get this if len(floppyimg)>0 ) you get pong.
Since the software is closed, there is no code you know about and everything in there is doing stuff you don't know about with the exception of the intended consequences of the software. All you have is the publisher's promise it does only what it's intended to do.
Having said that, putting an easter egg in there denotes some kind of love for the product. I like that.
In this case the majority of the easter egg code is running inside the VM sandbox. It's very unlikely but not impossible that the small amount of code needed to load the hidden disk image when a key combo is pressed would contain a major bug.
I've never had a job where we weren't constantly under tight (really, completely unreasonable) deadlines, so to me Easter Eggs always felt like a "fuck you losers" from developers at big, commercial software companies to developers at small, consulting software companies.
> I've never had a job where we weren't constantly under tight (really, completely unreasonable) deadlines
My guess would be the reason small/new shops have deadlines like that is because they're more likely to have less experienced managers. If it bothers you that much perhaps you should work at a larger company where the managers understand nine women can't make a baby in one month.
It would be acceptable if each easter egg lasted a maximum of one release, followed by a public post-mortem on the vulnerability identified in the release management process.
Easter eggs wouldn't be considered features (even if management-approved) because they are not advertised, and they do not perform a function related to the application. For example, if management approved a flight simulator in Excel '97, would you still consider if a 'feature' of Excel '97?
It was a feature (a property of the artifact) because it provided a signal about management priorities with respect to purchase criteria such as security. Microsoft eventually removed all Easter Eggs as part of their company-wide effort to fix their poor security reputation.
> Couldn't malware attempt to locate potential easter eggs in order to determine if they are in a honeypot?
No. This is a key combination against the UI. If the VM could send key combinations to the UI of the VMC then the software running on the VM could determine if it was in a "honeypot" (VM) with or without this easter-egg (e.g. send CTRL-ALT-INSERT and see if CTRL-ALT-DELETE is triggered within the VM's context, restart the VM, alter connected devices, and so on).
Also, yes, I think Easter Eggs are fine in a VMC. Particularly when they're only UI deep as is this case. The only software I wouldn't put easter eggs into is software which is "life-death critical" (aircraft control systems, industrial equipment, et al). But these kind of systems are sometimes designed to be mathematically proven safe with no possible conflating variables in the execution (so putting in easter eggs would be HUGELY expensive and likely wouldn't happen for that reason).
I think that there are millions of other aspects in a software (in vmware) which are much more important than easter egg or not easter egg. So the impact of an easter egg to this software quality is not significant.
There isn't really an explanation anywhere, but the colors that the game changes to in pride-mode look like original Apple logo colors - is that a hat tip?
Yes. Multiple meanings.. gay pride, but also pride in our work, and in producing the first product of its kind for Apple machines, and pride in the small team of us that made it happen within VMware.
