<link href="bower_components/bootstrap/dist/css/bootstrap.min.css" rel="stylesheet">
<link href="bower_components/bootstrap-social/bootstrap-social.css" rel="stylesheet">
<link href="bower_components/font-awesome/css/font-awesome.min.css" rel="stylesheet">
<link href="assets/css/ie10-viewport-bug-workaround.css" rel="stylesheet">
<link href="cover.css" rel="stylesheet">
<script src="bower_components/jquery/dist/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="../../assets/js/vendor/jquery.min.js"><\/script>')</script>
<script src="bower_components/bootstrap/dist/js/bootstrap.min.js"></script>
<script src="assets/js/ie10-viewport-bug-workaround.js"></script>I start reading the code, and pretty soon it starts messing with the clipboard, and it even pulls in Flash [1]:
> // Config ZeroClipboard
> ZeroClipboard.config({
> moviePath: '/assets/flash/ZeroClipboard.swf',
> hoverClass: 'btn-clipboard-hover'
> })
In all honesty, this website serves more as an indication of why the TSA spending this much money on such code may actually be justified, rather than effectively mocking the cost, which I think was its intent. How many security holes do you think this website is subject to? Can we know for certain that none of these dependencies are malicious or contain backdoors?
Security can't be taken lightly. And yes - for an app like this, it's much more important that it be secure than that it look good. I doubt a browser application is really the right approach anyway, given those concerns.
[1] https://github.com/arik-so/tsa/blob/master/assets/js/src/app...
I know not all engineers do this, but this crap is what caused me to buy a new laptop. I was fine with my existing tools and workflow, but websites have gotten so slow and ridiculous. It's largely Javascript's fault.
I used to get angry about walled garden app stores, but lately I find myself hating the web. I don't dislike it, but I think we went on a really lame detour.
As an aside, Javascript ads are worse than Flash ads ever were.
I admit to thinking the dependency overkill for random arrows was part the joke. A la https://github.com/jezen/is-thirteen
That said, I don't think it's necessary to criticize a satirical project like this on technical grounds. The idea is great; the developer probably just used his boilerplate frameworks that are usually used for much more complex projects in order to save time.
Make a thing vanilla, people bitch about how it doesn't work on their phone.
I have a repo I clone for my one-off projects with all the boilerplate I could possibly need for a weekend project. None of the projects actually end up using all of that stuff, but I'm not bothered by the lack of professional optimization in my "for fun only" projects.
But it will hurt your career. How will people know if you keep up with modern development techniques?
15. Rule of Optimization: Prototype before polishing. Get it working before you optimize it.[1]
[1] https://www.slingcode.com/ref/ProgrammingPhilosophies.pdf
Let's say you have a mobile app used by 1 billion people every day. It sounds crazy, but I bet a fair number of people in this forum contribute to such an application.
Imagine you want to make an optimization that increases battery life by 1%. Assume a 30Wh battery and that it's charged once per day. Over the two year lifetime of the phone, at $0.10 per KWh, that change would save your users 21.9 million dollars in aggregate. Even with a team of 40 people making $500,000 per year working for a year, you still increase the efficiency of society with that change!
(I know, this ignores the opportunity cost of adding a new feature before your competitor, or focusing on something that will bring more user happiness, or the externality that users don't notice the $0.00003 they're paying to supply your app with electricity. But the point is, we have a lot of power, and our time is much cheaper when multiplied proportionally to that impact.)
Web app engineers display complexity like peacocks displaying their plumage.
Try "taxpayer rage".
http://www.cnn.com/2016/03/29/europe/hijacked-egypt-air-jet/
There are roughly 100k commercial flights per day, 36m flights per year.
Therefore, the probability of your flight being hijacked is 1 in 30 million, which is an absurdly low number. Note that only one of the 6 hijackings resulted in casualties, so the mortality rate even lower.
"According to Mashable, the Transportation Security Administration apparently spent $47,000 on an app that is essentially a random number generator—it was briefly used to assign travelers to left or right lanes at airports.
As the website reported: “The app was used by TSA agents to randomly assign passengers to different pre-check lines as part of a now-discontinued program called ‘managed inclusion.’”
Such an app is widely viewed to be an extremely simple program to write. Many are questioning why a government agency overpaid for the app.
The revelation was published Sunday evening by Kevin Burke, a San Francisco-based developer, who received TSA documents in response to a Freedom of Information Act Request. The documents showed a $1.4 million price tag. However, the TSA has clarified that figure, stating that the app actually cost $47,000."
Writing the app, as anyone who has done any consulting work would know, is often the easiest, least time-intensive part of a project. Anyone saying to themselves, "$47K? I could do it in ten lines of code!" should stick to coding and let the contract procurement folks do their job.
(I'm merely the messenger; hate-game disclaimers apply.)
That said, 47k still seems crazy high. I've never done Gov't consulting though. One hopes hardware was included in the contract?
300K sounds about right
This should be implemented using a cryptographically secure random number generator. Presumably, the TSA requirements would specify some defense against an attacker being able to predict program outputs.
I submitted https://github.com/arik-so/tsa/issues/4 about this issue.
Not really. If you were flipping the penny to get heads or tails and lost it, you could easily replace that penny with a coin, a washer, a stick from outside, a book...hundreds of things already around your home or office, many with no use or value. You can't look around you and find a replacement for the penny as a currency.
Very big change in cost, considering the actual price of the TSA app.
It was a fun experiment and felt very old school.
From 2014: http://www.bloomberg.com/news/articles/2014-09-24/obamacare-...
And if so, are of those who would say that you didn't expect something so seemingly stupid to happen when they read that IBM was involved?
And do any of those people have any reason to believe that IBM managed this project well from prior experience?
I bet not, but lets see...
if (random > 0.5) { direction = 'right'; }
1 is not included in Math.Random, so it should be < 0.5 == left, >= 0.5 == right.
Someone took the time to explain FOSS to a Director at the telco I worked at, and he went on a month-long campaign to eliminate it from the entire company, ranting about security, etc. He didn't want me using Firefox on my desktop, because security.
Most of us tried as hard as we could not to laugh in his face, given the entire data center with 500+ VM's is sitting on Linux, and almost all the hundreds of millions of dollars of network elements run some flavor of linux.
Kerckhoffs's principle is also a relevant read.
As professor Bellovin notes :
"It helps, I think, to go back to Kerckhoffs' second principle, translated as "The system must not require secrecy and can be stolen by the enemy without causing trouble," per http://petitcolas.net/fabien/kerckhoffs/). Kerckhoffs said neither "publish everything" nor "keep everything secret"; rather, he said that the system should still be secure even if the enemy has a copy."
[1] http://csrc.nist.gov/publications/nistpubs/800-123/SP800-123...
Specifically, if you're talking about ciphers (as Kerckhoffs does), or system software (as NIST does), or anything else, you know in advance who's authorized and who's not. You've solved the hard problem; the rest is simply math, and we're fortunate to live in a time where the math is well-studied. You can give the secret key to the people who are authorized, and not to those who aren't, and your security rests on that key -- and your competence at figuring out who should have been given the key.
The TSA has no such luxury. They have no good way to distinguish me, a random person walking through the airport with a valid boarding pass and too many electronics, from a terrorist, also with a valid boarding pass and many electronics. If they could give me a key in advance, and not the terrorist, they would. (In fact, this is basically what Pre-Check is, and that works okay, although it only reduces the screening because they know Pre-Check can't be perfect.) But there's nothing that reliably distinguishes me and you and hundreds of millions of other non-terrorists from the small number of terrorists, and there's certainly no practical way to publish a key to us hundreds of millions, while keeping it away from terrorists.
So they rely on heuristics, because there is no better option. You cannot build a system that satisfies Kerckhoff's principle, because there is no key separate from the system itself. And any public, keyless system can be gamed trivially. (Think of, say, unkeyed SHA-256 checksums attesting to software integrity. Without a signature, i.e., without a key, anyone can tamper with both the software and the checksum, regardless of how good SHA-256 is.) So the system must be kept private in order for it to work at all... or we give up, and decide that the only people who can fly are those that we can conduct foolproof background checks on. That seems like a worse world.
It is rather like anti-spam and anti-virus. If you could just give a key to all legitimate email or legitimate software, you would. And in fact there are things that attempt to do that. But they can't be complete, and the remainder of the screening works on security-by-obscurity because there is no better option. Either we give up entirely on the ability to receive unsigned mail or run unsigned software (and even that won't be 100% reliable), or we go with the secret heuristics. It's not great, but it's the best we can do.
That eliminates a surprising number of tempting gold-plating situations that occur in rarely-executed code.
On the other hand, cutting 1 second of wait from a million daily active users adds up to whole human lifetimes saved rather quickly.
Then, when you have 100 million users, you can afford a team of optimisation specialists to strip out that 1% battery life
But yes, it seems on average npm pulls in 1,000 upstream packages when you just try making a vanilla project of any complexity
Not to interrupt some good-old lazy cynicism, but something tells me there is a substantial difference between domestic Egyptian airport security and the TSA.
Not that it makes the problem of being a developer who may need to convince other developers they're a good developer go away. Just that it puts the problem in context and shows a way one might be able to make it go away.
The head is part of the nail. The flat part at the other end from the point. ;)
The history of airport security is somewhat interesting. There wasn't a TSA for long time, and the hijackings/flying to Cuba got annoying, so metal detectors were added.
Everything else since then hasn't made much sense.
The low rate of hijacking is due to the scarcity of people interested in doing it, not the difficulty. Same reason your house doesn't get burgled every day.