The Ant Design Christmas Egg That Went Wrong(blog.shunliang.io) |
The Ant Design Christmas Egg That Went Wrong(blog.shunliang.io) |
I'm aware of the tendency to try to focus on what it seems like we can control rather than on actual justice. In this case, I'm so far only seeing outrage about the Easter Egg. I'm not seeing outrage about "They fired people over this???!!! People whose only crime was using Ant??!"
I'm not a fan of what Christmas has mostly turned into these days. I'm ambivalent about leaving a remark that could easily be wildly misinterpreted as supporting and encouraging cultural insensitivity by Americans/Westerners.
Anyway, I may seriously regret commenting at all. This seems like a can of worms for various reasons. I just dislike the idea of standing idly by while the developers get lambasted, as if they should have known ahead of time that people would be fired over this because of stuff happening in China. I'm also leery of the possibility that the other answer will be to ignore the seriousness of the situation for some people and act like "not my problem."
So there's my 2 cents.
He asks you why you put this code in. You tell him you didn’t write the code. He asks who did. You tell him it’s open source, many people contributed and someone put this in without telling anyone. At this point, you’ve lost all credibility to you non technical boss and all of his non technical execs. You put a strangers code on the state run website, without reviewing it and without knowing what’s in it.
The days where the state run website only runs code written by the guy in the department who knows how to spell HTML are long gone. Everyone is working on a very small subset of the huge stack of complexity that makes someone else's browser on someone else's device made by someone else on someone else's network linked by someone else's CDN to someone else's datacenter that hold someone else's server hardware which runs someone else's OS which hosts someone else's server stack and uses someone else's framework to show the data you actually wrote. If your non-technical boss can't explain that some parts of this chain aren't under their complete control they're just not being honest.
So, sure, it's possible that in some cases people were fired because this Easter Egg outed them for violating some rule. And it's entirely possible that some of the cases of "I got fired for this" are that kind of scenario.
But if this is not against the rules and the firing is actually because it is Christmas-themed, that's a different situation.
I'm also aware that it could be a cultural thing where someone has to be the fall guy and heads will roll to prove our innocence. I see that as deeply problematic. If you didn't forbid open source, firing someone for using it as the "first offense" penalty is not a good policy.
I realize we likely have very little information at this point in time about the details behind the firings and it is the norm for early reports to be wildly misconstrued, which is one of the reasons saying anything at all here is potentially something I will regret.
There is not a single person in the entire history of web development that this sentence does not apply to.
[1] https://www.supergrubdisk.org/2012/04/02/happy-2012-april-fo...
IIRC VLC's icon has a Christmas tree on Christmas. That's cool. Some library having a Christmas day Easter egg, not so cool.
That said the lesson here is probably that if you're doing any serious dev you really should be reading the source before putting the library in your app and, you should be forking the library into your repo or into your own package manager server and only taking updates you've reviewed.
Last, but not the least, I'll document it as follows:
This code contains easter eggs which are disabled by default. If you want to enable them, set easter_eggs_enabled=true. Please note that, the eggs have their own time, and it won't make them enabled all the time.Disabling it is easy enough but I have other things to do.
Which is what? "Untrustworthy, avoid"?
Sometimes things will work out for you, sometimes it means exactly what it says on the tin: "I don't promise this works"
For example, if a library can't access the clock, then it wouldn't be able to implement this sort of "time bomb" behavior. You could also of course limit cookies, XHRs, etc. Certainly a bit hard to know how it would work from a technical standpoint, but I think if done well it would make diligence a lot more manageable.
So the problem is that: 1. Chinese gov/military don't allow celebration of Christmas in their office.(CCP members not allowed to have religious belief) 2. It's a critical thing for some customers like The Middle east 3. If it's a hidden Easter Egg hard to trigger, it's ok; but it's not.
[1] I live in a country that is 97% Muslims. For most here, Christmas means at most the beginning of "white, European tourist season". My SO thought until 2 days ago that Europeans simply have a week long warmup to the new year celebrations...
My opinion about people who demand professional perfection from software they neither pay for nor can be bothered to review the source of are probably well-indicated by the tone of this sentence.
This "undocumented code change" could easily have grabbed any login details/session cookies/personal data from the page and sent them somewhere, instead of drawing snowflakes. I doubt anyone would have noticed for a while... clearly there were a large number of people who weren't auditing the latest version of the code to see what changed, and only noticed the change because of the visual effects.
Sorry, but if you deploy a random chunk of third-party code into your production environment without knowing exactly what it does, you deserve to be sacked.
I'd say this is the perfect time then. Governments cracking down Christmas celebrations should be fought back and ridiculed.
The world needs more random amusing-but-not-damaging surprises like this. To the Ant team: I'm impressed.
Some people got fired because they used this library in sites and this happened.
Given the current state of affairs in China, I’m inclined to believe this was political. If that’s true, many of the other comments here debating the need for professionalism in FOSS may be missing the point. It could be argued that this fits into the same category as the malicious hijacking of libraries on NPM, although I agree with the political statement being made here.
A more appropriate debate may be whether it’s acceptable for FOSS libraries to protest human and civil rights violations.
Chinese politics? alright fair enough... but what if some of these companies got punished because of it? or lost business?
I'm Arabic, can you imagine the shit a dev will get because of this if he/she used Ant for a political figure or party website? imagine a non-christian religious organization finds their site publically celebrating Christmas?
at the end of the day, politics or not the only person that will get all the shit dumped on their head is the poor developer who trusted your product and took you as a responsible person with all the 39k GitHub stars and 692 contributors... if I can't trust that to be mature then eh... good luck reshaping the world with FOSS.
Good luck explaining dependencies to the client/manager and how "someone from outside the company can modify our precious little website" and how can you prevent that in the future lol...
Can you illustrate this specifically? Had this happened, will the dev himself/herself get punished?
Christmas in China is just a shopping holiday for the most. And no reason to make things this complicated, the author has already stated that all this is intended to be an easter egg.
An easter egg that they put on other people's sites without their knowledge or consent.
The correct word for this is malware.
USA did not invent Christmas, even if you are right with your statement about 'Christmas eggs', I don't see the point of remarking that you are American as if that will make you some sort of Christmas authority.
“Christmas crackers are festive gifts that make a snapping sound when opened.” For example, a Christmas cracker could contain a paper with jokes on it, a paper crown, and a puzzle where you have to disconnect two linked ring-like metal pieces.
And I'm not being ironic or anything, really, literally the thing pushing a LOT of OSS is doing it for fun. If people keep complaining and blaming those OSS devs and it stops being fun then they will stop doing OSS, as many have done. Or it will be delegated to big companies like FB, Google, etc. where they get paid for the OSS they make, which is a whooole different can of worms.
(there is a thread saying something about a political stance, but I'm not qualified to have an opinion there and most easter eggs are for fun anyway)
This particular experience make me understand that working for free on open source is really a foolish idea. I was tempted by changing the license but since there are many others using it to build their business I thought it's better to just keep it as it is by respect to early adopters and users which any project is nothing without them.
For a healthy open source project the work needed it's not fun at least for me, it's not just about hacking/problem solving/design, you need actually to do issues triage, answer questions, documentation, extensive testing (with whole infrastructure for builds/releases/communication) those are not fun activities and in most cases done better than paid softwares (because people are passionate about their projects) and in addition to that I need to work fulltime on different (shitty) things to pay the bills and have time for familly ...
Sure there are some projects that are based on peoples' passions and have a few maintainers, but a lot of the bigger projects are big company middleware. It's a big difference from the FOSS movements of the late 90s. I wrote about it before here: https://penguindreams.org/blog/the-philosophy-of-open-source...
Have you reviewed all of Linux, glibc, nginx/Apache, bash, all several thousand node dependencies, and so on? Do you do such a review each time you have to update a package?
Don't get me wrong, I think there's a serious problem with the micro-dependency insanity, but every single person on the planet depends on others. "We stand on the shoulders of giants" is more of a truism today than it has ever been. It's not a sacking offense to trust people (because you wouldn't be able to do your job if you spent all of it reviewing other people's work).
Most people have a reasonable expectation that maintainers of a project are reasonable people -- which is why the micro-package insanity is particularly problematic. I trust most kernel maintainers and so I don't check each Linux release to see whether a backdoor was added (I only check if I've noticed a problem). The blame should be on the maintainers here -- it isn't acceptable to add Easter eggs like this to a library used by many people (especially if it's being used for Serious Business™).
Would you blame every glibc user (which is all Linux users) if they decided to make all math functions return 25 on Christmas? Of course you wouldn't -- you'd blame the maintainers for having lost their minds.
I don't really understand why we have "reasonable expectations that maintainers of a project are reasonable people". We absolutely know for a fact that a not-insignificant percentage of our users are malicious. Why do we assume that zero percent of package maintainers are malicious?
The only qualification someone has to be a maintainer is to have written something that someone else wants to use, and to publish that thing on a package repository. Or that they volunteered to take over maintenance of a thing that other people want to use. There's nothing in there about not being malicious.
And yes, I would absolutely blame every glibc user for trusting the glibc maintainers. Glibc is a gift. I don't have any contract with the maintainers of glibc that says they have to act in my interests. I choose to use their work because it saves me time. If that stops being the case, I'll find an alternative (together with everyone else), or roll back to the last known good version of their work that they let me use. If the glibc maintainers really want to make it Christmas Day every day, then that is entirely their right. I do not have the right to demand anything from them or their code. I don't have to use their code, and they don't have to take my needs into consideration when writing it.
It's been a problem in the past:
https://web.archive.org/web/20060427011138/http://www.centos...
> Thu, 23 Mar 2006 00:52:58 +0000 (Wed, 18:52 CST)
> Jerry A. Taylor submitted the following Information:
> Email xxxxxxx
> Company City of Tuttle
> Location Oklahoma
> Comments
> Who gave you permission to invade my website and block me and anyone else from accessing it???
> Please remove your software immediately before I report it to government officials!!
> I am the City Manager of Tuttle, Oklahoma.
And the response:
> From: Johnny Hughes
> To: Jerry A. Taylor
> Subject: Re: www.centos.org - Contact Us Form
> Date: Wed, 22 Mar 2006 18:59:18 -0600
> I feel sorry for your city.
> CentOS is an operating system. It is probably installed on the computer
> that runs your website.
> We hope you are happy with it, since we produced it for free and you are
> able to use it without paying us ... and are even threatening to have us
> arrested for providing to you free of charge.
> Please contact someone who does IT for you and show them the page so
> that they can configure your apache webserver correctly.
> Thanks,
> Johnny Hughes,
> CentOS 4 Lead Developer
Figured out what happened yet, Encyclopedia Brown?
Yep: The city of Tuttle, OK, had a misconfigured/unconfigured site which was showing the CentOS default page. The City Manager of that August Berg thought "We've been hacked! We've been hacked by hackers with a bland corporate logo who left contact information! I MUST THREATEN THEM USING EMAIL!"
Click the link. It gets stupider.
My point is, you have to take the... uh... "violently ignorant" into account whenever you design things which can be public-facing.
“Don’t blame my personnel. They didn’t write that; they just chose to run random code downloaded from the internet” isn’t an optimal reply to “why is our web site broken?”.
In China, I can see this go towards a “only use packaged approved by the government”, where such packages are signed, and the government knows who to put in prison when a package contains such a surprise.
Granted, your Chinese state-run website is probably more control-oriented than a hypothetical SV startup which consists entirely of connecting VC money to external microservices with a little copy added in by machine-parsing a slide deck...
The world is full of bosses who aren't good at their job. And bosses who are flat-out ignorant, capricious or lazy. None of these factors will protect the technical person mentioned in the grandparent post.
And you'd be shocked at how many state/federal resources have a single point of failure. Add to that small-to-medium sized companies, and suddenly there could be a lot of people taking (possibly irrational levels of) heat from their bosses.
But it's not -their- job to do that. Their job is to manage resources etc. for the devs.
While I understand this sentiment, it's not practically possible -- and if every business did audits of all code on their production machines (do we include firmware?) they would never get any work done or update anything. Which would lead to objectively worse outcomes (outdated/insecure software or no software developed at all) -- so there needs to be a middle-ground somewhere. In fact, you've already picked one (which is reasonable -- I think limiting dependencies is a good thing):
> I do deliberately try to limit what goes into my production machines, yes. I choose to trust some things, carefully, and choose not to trust others.
I would expect NASA/JPL to audit everything they run in production on a space telescope or shuttle. I wouldn't expect the same from the next "Uber for Dogs", nor would I think it a reasonable standard.
> I don't really understand why we have "reasonable expectations that maintainers of a project are reasonable people".
For a variety of reasons. Maintainers are public entities, so they know if anything they do is malicious they will feel immense backlash (such as is happening here over a somewhat minor issue compared to exfiltrating user data). People have pride in their work -- this is a known psychological effect -- and this is especially true in the free software world, so it's much less likely they'd sabotage something they'd put their time into. Developers that contribute to a project (likely for work or something like that) can become maintainers and thus the most motivated users usually become maintainers (and given that it takes time to become a maintainer of most large projects, doing it to sabotage the project is a long-haul gig).
> And yes, I would absolutely blame every glibc user for trusting the glibc maintainers.
I think this is far from reasonable -- you are talking about literally every single user of any program built on any Linux distribution for the past 30 years. Would you level more blame on the glibc maintainers for betraying their users in this manner? Do you blame websites for CVEs like Heartbleed -- even if they fix them as soon as they can?
> I don't have any contract with the maintainers of glibc that says they have to act in my interests.
Not a legal contract, but a social one. People who are in positions of power have an ethical duty to our society. Those who don't, don't deserve to be in such positions.
(Note that I don't necessarily agree with this but it's an obvious path.)
This is coming from my 20+ years of experience with computers and applications. I've seen that programs with easter eggs may have some stupid bugs, but won't have something sinister inside them. OTOH, applications with some very serious and no-nonsense attitude has the most advanced "phone home" mechanisms.
This is my experience though. I'd happily stand corrected if I'm wrong.
https://blog.mozilla.org/firefox/easter-eggs-come-from-foxes...
We've been putting up with live fixes and direct "developer"-"production system" style methodologies for a long time; only ethically. It just happens to be 'accepted practice' to fold some gargantuan code-base into ones own environment, without a line-for-line proper review. "Its impossible", say the bean counters. "Who would pay for that?"
Technically there is no good reason for the easter egg to have occurred, had someone done a proper code-review, observed full test reports, respected code-coverage rules and principles, and so on.
The easter egg proved that someone wasn't doing their job.
That's not even getting to a project. Have you looked at a projects node_modules, or the maven/jar dependences pulled in? Even for small projects, it grows to a very non-trivial amount very quickly. Inspect ever single jar and dependency?
Should people write their own web servers instead? Their own frameworks? Their own operating systems?
At some point you have to trust someone enough to actually get your work done. If an OSS project breaks that trust (like we've seen with some node modules) you stop using them, but inspecting every last dependency is often impractical.
I've never made proprietary software. I've written hundreds of thousands of lines of open source code in dozens of projects. I make releases of those projects, answer bug reports and issues, review PRs, all for free. Often I get annoying demanding emails for support for something I give away for free, which is quite annoying, but I usually answer anyway unless the sender is really annoying.
In a couple of them, there are features which are the because they amused me when I wrote them. Nothing that would lead to a wrong answer. Maybe if someone wants to base their business on my free labor, they have to put up with that.
I think it was the “should” bit. Just as nobody should be able to tell you whether you can add light hearted features to your software that make you happy, you shouldn’t be telling others authors that it’s not ok for us to write open-source software that aims to be professional, transparent and trustworthy. I’m sure the things you write are these things too, and I agree sometimes it’s good to be light hearted and have fun, but I reject that we “should” inject reminders like this in our open source with the intention of reminding others it’s free. That would take us back to the days of nagware, IMO.
At any rate, if you were just venting, I hear you. Thank you for your contributions to open-source!
Because that doesn't sound like having fun to me, that sounds like you're trying to create controversy.
Just because you give away pizzas for free doesn't give you the right to poison some slices because people have to be reminded that nothing in live is free.
Well, you see ... I happen to think that you can use a lot of tools to cover your ass, and .. the fact that this one slipped in is as much a comment on the crud that is promulgating the wild and woolly Node/JS ecosystem as it is anything else. In point of fact, this kind of bollocks is why I eschew Node/JS and use other things [1], instead.
I do believe there are tools and ecosystems which make this sort of thing less likely. I can't recall a Linux easter egg .. nor a Golang one ..
>Should people write their own web servers instead? Their own frameworks? Their own operating systems?
One should at least, audit. As much as possible. It doesn't take much for a competent dev to 'grep -ir "easter egg $CODEBLASE' or, whatever .. not that its an expectation.
But yeah, if you have to have government-level 5-nines on all services, then I would say - fair play. The responsibility for an audit of such things should definitely have been in the requirements. I've seen such expectations for lesser projects, personally, where .. indeed .. code audit and ownership were tightly .. and properly .. managed.
[1] - I don't know for sure, but I think its harder to slip in such an easter egg on a production golang system. I guess I'll tune into that if/when it happens/has happened..
the poster didn't say that. i think you are reading a bit to much into those words. there is no mention of what other authors should do. poster is talking about their own motivations for adding features like that, but in no way suggesting that everyone should do that.
your response suggests that you can't have fun with software that aims to be professional, transparent and trustworthy. i'd disagree with that. pranking others is not the only way to have fun. but if that is what you believe, maybe you shouldn't be telling others that they can't have fun with their software.
a more measured response might be to point out that having fun is ok, but doing so at the expense of others comes across as unprofessional, intransparent and untrustworthy. but if an author doesn't mind coming across like that, it's still their choice. but then, that's my opinion. yours might be different.
A better phrasing might be, fun Easter eggs, like wishing users Merry Christmas, might be a good way to denote software which is free, but is not designed to be slotted straight into a for-profit business critical situation -- certainly don't come crying if something breaks on IE 11 or whatever.
I don't think anyone can call your own experience "wrong" per se. I'd point to the Google logograms as a "smart and fun [easter egg]" per your definition but they are definitely one of the more sinister corporations.
That's a fair angle :)
you don't need to vet every line of code, but if you don't read release notes then you only have yourself to blame if it breaks.
the problem here is not the feature itself, but the fact that it was hidden and undiscoverable by testing.
had the authors make a "christmas release" with the feature being active unconditionally, then even without it being documented, any user should have noticed the feature in testing.
things like this haven't been a problem until now, and they won't be a problem in the future because generally people are aware that playing pranks is not always nice for the recipients.
They shouldn't have been doing this in the first place.
If so, what does that mean for the future of open source, and how come it hasn't been a problem until now?
It means that if you want to pretend you're making safe, reliable software, you (or your company) need to be prepared to accept liability for failures of performance. Actual engineers are actually responsible when their products fail. There's a reason we don't build bridges out of a thousand random packages we downloaded from a not-particularly-secure repository in the name of moving as quickly as possible to try and get the next VC dollar.
There is perhaps equivalence to arbitrary and unusual pizza toppings on pizza given away for free, and people proceeding to base their livelihood on passing on those slices on without checking what’s on them (knowing that there is no process to determine the bounds of the realm from within which the pizza toppings may come).
My point is, you should never create bugs intentionally. And you never put easter eggs in libraries. WTF?! Changing random button captions can render an application useless. Thats just a bug, not an easter egg.
Put your easter eggs in an about dialog or something that doesn't break everything.
I wouldn’t have put that easter egg in. But for me the main point is that the story brings the sense that I ought to steel my resolve to somehow build better and more formal processes and tools to bring clarity and oversight and guarantees to our currently ad-hoc collaborative code sharing and reuse.