Easter Eggs

[aledain]

I have the desire to place an easter egg (*) in an application I am working on. Should I inform management that the egg will go in? Can/should I do this and what are the ramifications (legal, moral, ethical, etc). Does this fall into the category of malicious code (even if the code is benign).

And what about back doors. Has anyone placed one in software they have released?

Hmm, much to ponder.

cheers, Alex.

* An easter egg is a small amount of code added as a bit of fun by a programmer. Generally they can be a bit of fun or a bit of a time waster, and they are NEVER malicious, hence the cute name. Examples I have seen are (1) on Halloween ,the icon changes to a grinning Jack'o'Lantern, (2) an oscilloscope where if you hold down several keys at once it will start a game of TETRIS.

[Bryan]

I would definitely check with your management as far as easter eggs are concerned. If it's something that would contribute to the use of system resources, you might want to rethink it.

Back doors, depending on what type of software you're running can be a good things often times for support and troubleshooting. I've done easter eggs in the past on applications that stay in-house. I have yet to create a back door in anything I've written.

You just got done reading Digital Fortress didn't you?

yaorouseveethncs wecgewhyaaiortnu (<-- If you read the book, you'll get that)

[aledain]

You just got done reading Digital Fortress didn't you?

yaorouseveethncs wecgewhyaaiortnu (<-- If you read the book, you'll get that)

2259[/snapback]

No haven't read that, but have read some of his others. I'll now have to go out and buy it just to understand that cryptic comment ;-)

cheers, Alex.

[Barrie]

I have the desire to place an easter egg (*) in an application I am working on. Should I inform management that the egg will go in? Can/should I do this and what are the ramifications (legal, moral, ethical, etc). Does this fall into the category of malicious code (even if the code is benign).

And what about back doors. Has anyone placed one in software they have released?

Hmm, much to ponder.

cheers, Alex.

* An easter egg is a small amount of code added as a bit of fun by a programmer. Generally they can be a bit of fun or a bit of a time waster, and they are NEVER malicious, hence the cute name. Examples I have seen are (1) on Halloween ,the icon changes to a grinning Jack'o'Lantern, (2) an oscilloscope where if you hold down several keys at once it will start a game of TETRIS.

2242[/snapback]

Personally, I don't think there is a big problem with easter eggs, providing they are relatively small. There is so much disk space and memory available for peanuts that I wouldn't be bothered if any developer I supervised conjured up an easter egg. People sign their names on all types of work and I think it is healthy. It signifies pride, and promotes a team spirit and a sense of ownership. It's also fun. Never forget fun. :laugh:

As for back doors, which can consist of something as simple as an embedded password, I think it is a matter of practicality. I wrote an application that was VERY security sensitive, but had relatively unsophisticated users. If admin passwords were forgotten or wiped out, the system would emulate a brick if there wasn't a way to get in and wake it up.

Presently I am managing another system that is also security sensitive, where the operators have limited access (intentionally). It is a portable system that is used internationally. If something screws up, I have two choices; I can use my back door over the phone, or I can jump on a plane and fly to Australia, China or India with a box of CD's for a couple of hours work, and lose 2 days of system productivity and 4 days (minimum) of my productivity.

Management types will solemnly nod their heads when we talk about security, but when things go badly and the UberGeek is on holidays, the story (and priorities) change(s).

For anyone who is paranoid, it all comes down to trust. There are 4 possibilites:

1. The developer(s) will not implement back doors.

2. The developer(s) will implement backdoors and notify management, for ethical reasons.

3. The developer(s) will implement back doors for practical reasons and not notify managers, for practical reasons.

4. The developer(s) will implement backdoors and not notify management for non-ethical reasons.

If it is a big personal ethical dilemma, state your intentions, and justifications to the customer and come to an agreement on the approach (AND potential consequences) in writing.

Regardless of any policies, there is little, if any, real control over back doors, if the developer is competent. There is even less control over back doors if the developer is competent and malicious.

Generally, I think that there is far more risk from good old fashioned bugs due to insufficient testing, Murphy's Law, poor system architecture and poor developer selection than there is from back doors.

Further, none the above scenarios compare to many, many small minded people out there that are KNOWN to want to do your system harm, if you are 'net connected.

It's a question of balance and evaluation of risks and benefits. Just don't worry so much about terrorists that you forget to buckle your seat belt.

I apologize for any rambling in advance, but it is a non-trivial question that I have struggled with in the past.

Barrie

[aledain]

I apologize for any rambling in advance, but it is a non-trivial question that I have struggled with in the past.

2287[/snapback]

Hardly rambling, but a very instructive reply.

I think that you're right about the possibility of damage being minimal, and that the advantage of the "fun" aspect should not be ignored.

I agree too with your comment on the lack of a backdoor == loss of productivity. FWIW I have placed TRACE=TRUE as a possible configuration option in all(most?) of my applications for just such scenarios. Wading through a trace file can be more instructive than receiving a "it won't work" call ;-)

I suppose the backdoor should/can be treated differently than the easter egg because the backdoor can be used both maliciously and non, while the easter egg does tend/IS benign. It probably comes down to the client/bosses and their response when they one day locate the egg ... Will they be happy? (maybe) Will they be vengeful? (probably not).

An illustrative example of how eggs(?) can catch you out in a good way: I was working on a long project (several years) as the sole programmer and one day while programming onsite with the client looking over my shoulder I made a comment that a particular part of the code, if ever executed, would result in a zombie process being created in the system that just couldn't be deleted. I told him I had nailed (or so I thought) every possible check but just in case I will put put a dialog box in the very last case. He completely forgot about it, the software was commissioned and running successfully for over a year.

One day he rings me up quoting the dialog box "I am a zombie, you should never see me". Apparently, the IT people had beavered away for a few hours checking viruses etc in response to this message before calling him and he activating me. I thought it was funny, he found it amusing, their IT department ... well they're an IT department But the upshot was that one of their users had fiddled with the system files to try and do something fancy and my egg had finally hatched. I was able to locate the problem quickly by tracking back the LV code to tell them which file was "wrong". An egg saved the day!

cheers, Alex.

[Barrie]

Hardly rambling, but a very instructive reply.

*snip*

I was able to locate the problem quickly by tracking back the LV code to tell them which file was "wrong". An egg saved the day!

cheers, Alex.

2289[/snapback]

Thank you for those kind words. What you did, by implementing that zombie, was to ensure that all possible outcomes were covered; something that we all should do, but realistically, it is very difficult, if not impossible to programatically account for all scenarios.

One other issue about back doors or eggs that I missed, is that it can start a thought process in management of "Well, if he can do that what else can he ........"

This, by itself, can create an environment of confidence in competence, or of mistrust.

Regardless of the discipline, establishing rapport and trust is very important. (A little knowledge transfer doesn't hurt either )

Regards

Barrie

[Bryan]

No haven't read that, but have read some of his others. I'll now have to go out and buy it just to understand that cryptic comment ;-)

cheers, Alex.

2281[/snapback]

After your talk about backdoors and easter eggs, I thought you had read that book because they're mentioned in there.

I had done a very simple one that popped up a comical error message when a particular user logged in. Back at the time I didn't know they were called "easter eggs" until I read that book.

[aledain]

After your talk about backdoors and easter eggs, I thought you had read that book because they're mentioned in there. 

2323[/snapback]

And a quick google for "software easter eggs" reveals whole sites devoted to them! Didn't realise they were so prevalent. The first one I saw was in October 1995 where under Win3.1 the icon changed on Halloween.

You're right about trust. I think I will notify them of my intent to add the egg with their permission.

Anyone know of any eggs in LabVIEW?

cheers, Alex.

[JackHamilton]

Hmm, I should say this...but what the heck.

I did put an Easter Egg in some software once :ninja: - basically it would display a dialog box that "All parts would Pass Testing". Lucky for me to enable it - you had to press a key sequence - then press another Ctrl+key to get the dialog. (It was only a dialog - it did not effect the test ;-#)

The enable sequence disabled after the Easter Egg dialog display.

Well I got lucky because we showed ONE person at the plant and in about 2 weeks I was asked point blank by the Project Manager "If I put an Easter Egg in the test code". Keep in mind this was released code which was not for comercial use.

The person who watched only knew the final key sequence - not the enable. They could not ever get the dialog again. (Because QC wanted to take a look at it ).

As I was the only one who knew the enable sequence.."No sir! I replied".

The lesson learned was - make sure access to the egg is somewhat complex - the first idiot you show will show everybody in the plant and your goose is cooked!

[jbrohan]

There is a very simple solution to this whole problem of Easter Eggs. Put it in the Spec. The one line "At Halloween the cursor is a pumpkin" will probably provoke nothing more than a shrug. Some of us feel that customers don't read specifications very well anyway.

[aledain]

There is a very simple solution to this whole problem of Easter Eggs. Put it in the Spec. The one line "At Halloween the cursor is a pumpkin" will probably provoke nothing more than a shrug. Some of us feel that customers don't read specifications very well anyway.

2520[/snapback]

Maybe not, but at the very least shouldn't they be writing them?

[Jack Kelledes]

I almost always put in a back door if the application is going to stay in house. I will only do it for an application that is going to a customer if I had to rush it through and didn't have enough time to try every possibility. It's helped me a few times in the past.

I put Easter Eggs in lots of my code and have forgotten about many of them. I got a call from a person in another lab who I supplied a test setup for asking why his screen colors were going crazy. I had forgotten that I put an April Fools egg in that software because I didn't think it was going to leave our place. He didn't mind it and asked me for the code for it so he could use it in the future.

[dhuff]

I don't think easter eggs are completely bad, but you should not waist valuable time coding it into your project, in fact, Labview.exe has easter eggs in it as well. (Before you ask, NO I will not reveal them here)

There are a few things to keep in mind before doing an easter egg:

1. It should not contain anything even remotely offensive or profane, many programs can now search for metadata on your computer, which means that even if the egg is virtually impossible to trigger, the ASCII text is still readable by a hex editor or search tool.

2. Remember that software, no matter how perfect, can still get into unstable conditions, so something considered "impossible" to access may actually happen later. I know personally of a company that suffered from an easter egg. The user got to a "virtually impossible" condition and then got a skull and crossbones on a display , and then forced the company to exchange the device. (That action brought out lots of angry managers and lawyers )

dhuff

[aledain]

in fact, Labview.exe has easter eggs in it as well. (Before you ask, NO I will not reveal them here) 

2617[/snapback]

Ohh, you tease

(fair enough though).

cheers, Alex

[Frank]

This is probably not an easter egg, it is more like a poorly worded error message. Once when working on a tricky vi, I inserted a dialog box with the words "Oh Sh*t" -without the * - in a case that was never supposed to execute. Several years later after making a minor change in the software, my customer called me and said "Your program said Oh Sh*t". It worked out OK, but I am more careful about things like that in my software.

[Michael Aivaliotis]

That's golden. I would have liked to be there to capture the look of that customers face.

[jerseydevil]

Morality is in the eye of the beholder (well,,, maybe in the eye).

Thanks for the post, because it reminded me of an egg I put in a few years back that I forgot. It was the development team photo. Just a little waisted time, but a decent motivator and reward. Unfortunately I forgot the key.... I probably can't find the source, so guaranteed I'll spend all night clicking that CD.

gnite,

jd

[DredPirate]

Ok. I know this is an old post but why not create a backdoor that you can use without comprimising security. I developed a password program that generated a text file with the password, date and time, and random key scrambled by a complex formula and labeled the file password.dat. In a seperate file I stored the date and time the file was created.

If the password.dat file were deleted it required the user to enter a new password and created a new password.dat file.

This way the admin could still get into the program if the password were forgotten but if someone entered the program without the admin's aprovel the admin would know.

The date time was used to as a safegaurd against someone copying and pasting the file to get around the security.

For even more security I could of labeled the file something other than password.dat but it was going to China and most of the people they were trying to lock out didn't understand english.

[Phillip Brooks]

Pick one, bone-head! :laugh:

This is the message I got once when trying to compile a Novell Shell driver using the Netware 2.x (Late 80s). I was specifically trying to create a dialup driver by following the instructions in the manual. There were two dialog options; OK and HELP. I Clicked HELP and saw a duplicate box with OK and HELP. Tried HELP one more time and got "Pick one, bone-head!" :laugh: I reported it to Novell and got an appology letter.

Don't know what happened to the programmer, but I imagine in today's environment, one might be let go for that.

[Phillip Brooks]

LabVIEW 8 Easter Egg

Seemed appropriate to pass along, this might also be worth cross-posting in the LV8 LAVA forum...

Posted today, 19 Oct 2005 on the Info-LabVIEW forum; by Stephen Mercer:

Easter Egg: A hidden feature of a piece of software, generally something that has no functional impact, just fun visual impact.

I happen to like these little hidden corners of a product, provided they take up little to no space on the end user's harddrive. Since I started working at NI, I've put one or two into LabVIEW. But the one I planned for LV8.0 turned out to be a sufficiently good idea that it got documented.

If you look at the documentation for the "icon editor dialog box", the last line of the documentation says, "Use the lv_icon VI template in the labview\resource\plugins directory to create a VI with which you can edit VI icons outside of the Icon Editor dialog box."

In LV8.0, take a look in the directory

labview 8.0\resource\plugins\

There you will find a file called lv_icon.vit. On the front panel of this VI Template are instructions for how to build your own icon editor that will replace the one used in LabVIEW when editing the icons of VIs. There is another file called SAMPLE_lv_icon.vi which is a trivial example of one such replacement icon editor. Just rename that file to be lv_icon.vi and then see what happens when you try to edit a VI's icon in LabVIEW.

Have you ever wanted to be able to load your icon in some other piece of graphics software, edit it, and then put it into your VI without cutting and pasting every time you want to edit it? Have you ever thought about just building an icon editor in LabVIEW with features that you like? I saw comments on this mailing list recently about maintaining an icon library.

You could write an icon editor that integrated such a library into itself.

In short what started out as a project to open a backdoor for creating silly icon editors for an easter egg idea turned into a real opportunity for LV users to improve/change their icon editing experience. This is one of the small features of LV8.0 that most users will never need or want, but I figured some of the gurus on this list might use this feature to great advantage.

Pojundery,

Stephen R. Mercer

-= LabVIEW R&D =-

[Aristos Queue]

And what about back doors. Has anyone placed one in software they have released?

I've been known to put easter eggs into software. There's one in LV (which I'm sure you can find if you search around on this site a while). When putting it in, I followed nearly all of the standard software design requirements that we have for code changes. About the only part I skipped was the full team opportunity for comment on the feature. The change was buddied by two other developers, and I documented the .ini token in our official lists (though I may have been a bit vague about what that token did *exactly*). I filed a test plan in the test plan database so it gets tested every release. Every release I get someone who walks up to me and in a very quiet voice whispers, "I got assigned your test. Nice egg. It works." And the conspiracy goes on. ;-)

For an Easter egg you have to consider all the aspects you consider for any feature: impact on memory, impact on performance, impact on user interface, impact on localization, impact on maintainability of the code base.

What I've learned as time goes on is something I should've known from college -- you don't have to keep it a secret from your team. Most developers will enjoy it and help out, and having those other people know about it will give them a chance to advise you against something that "seems like a good idea at the time." *ahem* If you've kept all the above impacts in mind, even managers generally think its cool -- provided you're done with all the assigned tasks, of course. Further, some of those Easter eggs can turn into features. For example, in LV8.0, I put in a way to replace the LV Icon Editor with a VI so that I could write a VI that would call a third-party icon editor. That was liked enough that we decided to document it.

When you get right down to it, a well-done Easter egg is just a well-done feature that doesn't get as much publicity.