> Generally speaking, programs used to have more Easter eggs. I can't recall a single one in the cloud era.
The problem with Easter Eggs in the web era is that as soon as one person finds it, everyone knows about it. Part of the fun in the boxed software era was that you either had to find it yourself or hear about it from a friend.
That being said, we did have an easter egg on reddit for a long time that very few people noticed. Robots.txt included this:
Sometime in the early 2010s there was a link to a livestream of an office fish tank (I think) in the site footer, but I can't find any mention of it online.
The lack of Easter eggs in programs I feel like is a combination of 3 things
1) more “professionalism” being expected in software. Computers aren’t quirky things anymore they’re “serious business” and “serious businesses don’t do quirky”. Or some other such nonsense.
2) Offense risk, something innocuous has serious potential to be taken wrong now or even at some future date. I worked on a system where we needed to impose some effectively arbitrary max limit on the number of items allowed to be configured. We eventually settled on “640k” and originally had an error if you exceed that that said “640k ought to be enough for anyone”. The devs who would have seen that message would have gotten the reference and hopefully had a good chuckle. But I’ve seen customers get short about innocuous jokes before and could easily have seen someone complaining that we weren’t taking their needs seriously.
3) Security liability. A lot of Easter eggs were distinct code paths or sometimes even entire tiny embedded applications. In an ever connected world where your credit card terminal might be the gateway to your entire customer database, any unnecessary code path is also a potential security hole and risk. No one really wants to be in the news because a cute joke their developers put in 4 years ago was the key to a massive exploit.
Still I do agree that I miss some the “personality” older software could have.
Given that (I think?) the "OK/Cancel" dialog of the original Mac is one of those 'foundational' UI conventions that was copied pretty directly by every GUI that came after it, I am very curious if our world wouldn't be full of "Do It" buttons if this episode hadn't taken place. Even the Start Menu could have been called the "Do" menu in that alternate universe.
Interestingly, Apple's HIG generally suggest avoiding "Ok" in favor of an action describing what will happen. So save dialogs say "Save" not "OK". The empty trash dialog says "Empty Trash". Still I guess that's more clear than "Do It"
This change most likely happened sometime in the early 1990s, though it’s possible it could’ve happened in the late 1980s. I have a PDF copy of the Macintosh Human Interface Guidelines from 1995 that recommends descriptive button text instead of “OK” and “Cancel.”
"your credit card terminal might be the gateway to your entire customer database."
That is not the way it works now. The standard is 4 levels of encryption, most have 8. Multiple sign-offs for every single code change.
Your credit card terminal is a gateway to the signtors transaction database, last transaction, balance, current transaction. Every single code path is mapped out meticulously, at least on the most popular ones, and crypto keys are not padded like the very cheap ones.
I remember FoxPro 2.5 said, "Better call MAACO, you just crashed!" in some circumstance. Thankfully that seemed to improve with resetting the computer the time I saw it.
If the file had been corrupted, I wouldn't have found it as funny.
I envy you having written this, because I've wanted to do the same. I'm the adhoc IT guy / CISO / etc. for a small medical practice. I have to jump through the PCI hoops quarterly because it's an ancient junk relic of a time where Infinite Trust Networking and monthly forced password rotation were en vogue.
And why do I have to do PCI stuff? Because we have a credit card scanner that patients use to pay for things. In any sane world, compliance would be on the manufacturer of the scanner: "hey, make devices that actually, you know, encrypt stuff reliably". But since we don't live in that world, I have to have a separate Ethernet drop to the card scanner, which plugs into its own dedicated port on the firewall, which completely segregates it from the rest of the LAN traffic. That isn't horrible in concept, but why? Our servers which store PHI don't have those stringent requirements, because the servers are secured. They don't have to trust that the network is kind and gentle, because they're designed with the idea that it's not. But not so the credit card scanner!
For extra fun, we also have to pay someone to run a PCI compliance scan against our external IP. Said IP listens on exactly one port: the one that doctors use to VPN into the office so that they can check their schedule from home. We got a failing score one year because the VPN appliance supported — not required, but supported — some less-than-perfect crypto algorithm. None of our clients were configured to use those protocols. I know. I configured them. But because the server supported them, we were temporarily[0] judged to be noncompliant because some attacker could, I don't know, hack in and pivot in to the firewall appliance and from their pivot to attack the poor downtrodden credit card scanner which, of course, can't be expected to defend itself from the hostile environment of doctor's office LAN.
PCI's a joke.
[0]It would be against the scanner's ToS to temporarily block that port in our inbound firewall long enough to get them to shut up about it, so I totally did not do that.
I also like the extension of this to other figures important to a community. I founded a community called MiloHax that centers around modding and learning from the game made by Harmonix Music Systems, and we serve X-Clacks-Overhead with Sir Terry's name as well as some other influential people, both inside and outside of the community.
They're security issues, that's why. Microsoft used to have fun ones in Windows and Office (including a Doom-like engine in Excel 95) but in the late 90s or early 2000s they were all taken out by corporate fiat, because they don't add value and may contain security vulnerabilities. Since then, Easter eggs in user-facing software were rare (except for maybe Google Search's "do a barrel roll" and that).
I know MS put the kibosh on most easter eggs after some "trustworthy software" initiative in the early 2000s, which I think was to assuage government concerns that they could also be sneaking malicious backdoors into their software (silly reasoning), or that there could be vulnerabilities caused by an easter egg (ehhh...maybe).
It's not unreasonable to think that Easter eggs might be written to contain back doors. Certainly any large software project that has workflow gaps where unvetted code can be introduced is a recipe for disaster.
Why make the backdoor obvious by incorporating an easter egg when you could just make one that does not draw attention to itself? You can still make non-obvious backdoors with this policy in place.
An Easter egg containing a funny animation can be used to distract from the malformed image that serves as a back door that exploits a bug in the image renderer.
Generally speaking, programs used to have more Easter eggs. I can't recall a single one in the cloud era. The only one remotely whimsical is PostHog.