Right. I was skeptical in first few paragraphs, since students' teaching assessments do have their flaws. But if there was a statistically significant improvement in his students performance in later classes, then the man's doing his job.
Yes, there could still be confounding factors. He is seen as an enjoyable lecturer, and students who care about their classes enough to select the better lecturer might be better students. But still.
If you want to continue the analogy to software engineering, the modules he's producing are students, and they are meeting their specifications (later performance) quite well.
Not necessarily. They have 4000 employees, which probably has a number of non-revenue-generating positions that many SV companies are wont to have. Like Python API WebSockets Diversity Developer Envangelists with full travel budgets to go to 49 conferences a year. (I just made that up, but you get the idea)
Maybe judging a boom by twitter layoff is a bit too soon. However, the underneath mindset rings a bell: people starts to realize winter is coming, but not sure when...
For many businesses, that might be 2 or 3 too many.
Also, that was just an example I pulled out of the air. It could be middle management, or a documentation expert whose role is regulating font size. The point is that for a company with a simple product, an API and clients for that API, and monetization through advertising, that's a lot of employees. If the money's not there, cut the fat.
In that case they should just leave out the examples entirely. If the code runs, someone in the world WILL copy & paste it into their project and walk away, no matter if it's marked as insecure or not, which just perpetuates the problems that the post is trying to deal with.
Also I'm not sure "password hashing" is any more descriptive than "password encryption."
> In that case they should just leave out the examples entirely.
I'll consider it.
> Also I'm not sure "password hashing" is any more descriptive than "password encryption."
It absolutely is. Encryption is a two-way transformation of data. It is, by design, reversible.
Hashing is one-way.
Password hashing is a special case of hashing where you want it to be computationally expensive (even with special hardware at your disposal) to attack, but still perform well enough to interact with.
Password encryption implies that a two-way transformation has taken place, and given the key, you should be able to reverse it. This is not within the scope of the requirements for secure password storage.
Silicon Valley egos at their finest: "Use our product so we can make billions of dollars, but fuck you otherwise." I use venmo with friends because of their network effect and it's convenient, but it sounds like internally they're a pretty shitty company to deal with.
The missile argument is a bit of a stretch to me. The F-35 can carry way more than four missiles if they're attached to the wings (like the Su-35 the author compares it to), it will just destroy any semblance of stealth.
This is like saying "adding triple redundant GPS to a self driving car is a bad idea because the GPS is the component least likely to cause you to end up at the bottom of the ocean."
There's no a priori need for password-derived key material in a library like this. To require it unilaterally is to introduce a security risk, since people have proven to be poor sources of entropy.
I don't really understand the self-driving car analogy. A better analogy would probably be three cars hitched together.
If the user enters the bottom of the ocean as their destination, it would be bad for a self-driving car to take them there. "The user is an idiot and so we killed him" is not going to be such a great defense in court...
In all seriousness, if a man puts a GLOCK 21 in his mouth and pulls the trigger, is it GLOCK that "killed him"?
If I take my car and intentionally drive into the ocean, I expect it to continue until the engine dies, and then I do shortly after. Why should machines start prohibiting me from doing stupid things, if I want to do them? I think Isaac Asimov wrote a parable about such a future.
Except this also adds very little benefit. Sure, 3 ciphers might be better than one, but as the top comment said the cipher is already the strongest part of the entire process.
