I get that it's trying to be funny, but is it really no longer possible to create a website with a single arrow that doesn't have to pull down all this cruft ?
Agreed. I was curious as to how the random numbers were being generated (math.random()? Something else?), so I went to look at the source code. I expected `assets/js/src/application.js` to be the main file (I mean, look at that name. What else would it be?)
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.
Javascript is getting freakishly absurd. What is wrong with the JS ecosystem? This feels like XML all over again.
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.
In this case a few lines of CSS and a few lines of JavaScript would have delivered the exact same result, including all necessary responsiveness. We have gotten so far away from bare bones, non-jquery based development that this kind of heft has become the standard starting point for all projects. It certainly isn't my style, but then I didn't go to Stanford and don't work for a unicorn, so perhaps I am the unenlightened one.
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 300k off a website and people make a competitor to mock the value you delivered. People are stupid and you can't win. They will always try to force everyone to race to the bottom, because if they can't have it why should you?
No it needs to work in any hn readers browser. Different business requirements entirely! The business case here is to get hn traffic to that site and start a discussion.
I'd love to see a ridiculously over-engineered version. Something like a website running in a browser in Windows 95 running in a javascript DOSBOX emulator.
They are probably just using a quickstart file that has all of those things included as defaults.
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.
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.
Yeah, I hear you I get funny looks every time I make fun of 'whatever driven development', 'microservices', etc. It works well as I generally dislike working on teams that are just following fads.
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.)
Similarly, my general rule for optimization is: Add up all the time that will ever be spent waiting on this code by all users ever. If that's less than the time required to implement the optimization, don't bother.
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.
The usual (and frankly convincing) argument is that you won't get to a billion users without using the cruft as a means of scaffolding to help change and iterate and try new features, whatever the behind the scenes architecture looks like
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
I think what your actual objection is that it's so easy to make a simple website with all that cruft. Much or all of that stuff comes in one of the easiest to find and download "starter packs" from Bootstrap. You can take the time to figure out what everything does and slim it down or just ship it.
Exactly! My first attempt was just 10 lines of HTML code, but it was a real pain to do the vertical centering on iOS. So I tried a Bootstrap template, saw that even they didn't do the centering on iOS, but was too lazy to change it back.
I feel like HN's nerd rage at stuff like this (the TSA expenditure) is the same reason many (if not most) engineers make less than they could. It's a very willful denial of a fact of how the world works (large organizations routinely pay large sums for seemingly very simple work).
I have a cheaper alternative. Get rid of TSA altogether. Travelling was a whole heck of a lot more fun in 1975. Since then it's been overreaction upon overreaction. Nobody is going to hijack a plane in this day and age because of the simple fact that the passengers will immediately revolt.
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.
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.
Interestingly, another approach that was seriously considered was to build a fake "Havana airport" in southern Florida and have the planes land there instead.
Yes. Six, possibly even six and a half, flights every five years.
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.
> [The] EgyptAir flight was taking too long to get from Alexandria to Cairo
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.
It's all security theatre. The TSA has stopped a dangerous person NEVER. I've lived around the world and airport security is bad everywhere. Australia's is terrible, German's is pretty bad, but the worst; the absolutely fucking worst is America's. I knew people who would pay more to fly through Canada to avoid American airports.
The pre-2001 airport security apparatus did a good job of keeping guns off planes, eliminating the most common hijacking scenario. Almost everything since then has been increased hassle for diminishing returns, with the most effective improvement being one of the least visible - hardening the cockpit doors.
"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."
Such an app is widely viewed to be an extremely simple program to write.
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.)
Lets be practical, I am sure the actual app
- Works without network connection
- Metrics (offline syncronization)
- User logins
- Includes price of iPads themselves?
- Involved government and IBM personal
The UI looks nice, but there is more to this than a UI.
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.
If you're alluding to a penny, I think you'll find that they cost more that $0.01. Probably a far better example wasteful government procurement than this app.
" Probably a far better example wasteful government procurement than this app."
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.
This left me thinking what could be the simplest implementation I could do, while keeping a good UX. I came up with this in 10mins: https://jsbin.com/xidefopuqe
Nice - you saved me the effort. But after I wouldn't have been able to resist the idea of tweaking the randomness and ended up spending the rest of the evening trying to perfect something that felt more random than random - including forays into Wikipedia and other searches to find prior examples... So really you've saved me hours of work!
The argument that will be made against something like this is "We can't use a product that would let the bad guys see how it works!" I know it sounds ridiculous, but in my limited experience, "Security through Obscurity" is a key feature required by everything related to the (ineffective) methods used to secure the airports in the US. I believe this fact was even alluded to in the original article related to the justification for why a PRNG hooked up to a boolean cost USD$1.4M or USD$47,000 or whatever price over an hour's wage of a government intern it actually cost.
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.
Security through Obscurity is just not a great way of going about it. NIST notes "System security should not depend on the secrecy of the implementation or its components."[1]
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."
Kerckhoffs' principle applies to ciphers with keys. For the threat model the TSA is up against, security by obscurity is actually very close to reasonable.
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.
For all we know, it's using the camera to gauge the "brown-ness" of the current passenger's skin, and using that as an input to the calculation. It would be about as racially and culturally unbiased as anything else the TSA has ever done.
