[fizzbatter]

I mean, i am not agreeing with Yahoo here... but isn't that a reasonable thing to do?

Every act of securing or ensuring quality has a cost, and there is a line. I think most of us would agree that the line is very broken currently, but it appears you're citing a problem with the line in general, not the location of said line.

Everything has a cost, from a recall to better security to even a human life, the debate should be what we think should be paid, not whether or not we should worry about costs at all.

(If i misunderstood your intent, apologies)

[imagist]

The problem here is that the people who pay the costs of security are different from the people who are hurt when security is breached.

[vkou]

Loss of user trust hurts Yahoo.

[imagist]

Not enough that it isn't in Yahoo's favor to take that risk (you can't argue this--this is what happened).

[edanm]

And who are you to decide that that isn't a legitimate decision made by the users? If people cared more about security, they'd move away from Yahoo after something like this, and Yahoo would be more incentivized to keep this from happening.

Your problem is that you disagree with other users - but that's totally legitimate, not everyone has to care about the same things you care about.

[imagist]

> And who are you to decide that that isn't a legitimate decision made by the users? If people cared more about security, they'd move away from Yahoo after something like this, and Yahoo would be more incentivized to keep this from happening.

Who said this wasn't a legitimate decision by users? Certainly I didn't and wouldn't say that. There are a lot of reasons why a rational actor would choose to stick with Yahoo--that doesn't mean Yahoo exposing their private data is okay.

The other thing to realize here is that users aren't rational actors. My grandma is senile--is it okay for Yahoo to expose her private data because she doesn't know they aren't secure?

You've arbitrarily decided that users have to take all the responsibility here, and that the only way we can judge or punish Yahoo is by users leaving. But a) in many cases Yahoo is the only actor with agency to make a decision, and b) there are other ways Yahoo could be punished for using that agency to make decisions that harm users.

> Your problem is that you disagree with other users - but that's totally legitimate, not everyone has to care about the same things you care about.

No, I don't think that I disagree with other users--I think that many people care about their privacy, they simply a) don't know enough to make pragmatic decisions on how to protect their privacy, or b) have other priorities. And this is beside the point--none of this makes it okay for Yahoo to endanger their users' privacy.

[criddell]

> If people cared more about security, they'd move away from Yahoo after something like this

That's why Yahoo's failure to disclose this immediately bothers me so much.

[SilasX]

Maybe the long-run solution is to make the coupling explicit: publicly post the value the company places on an account not being breached. (Ideally, this would work in tandem with some insurance policy that pays out for that amount, to validate that they really do so value it.)

Then, you can choose the provider with a high enough value to make you feel comfortable, in the understanding that higher-valued accounts will cost more.

[coredog64]

This would work in many more contexts: The window sticker on my car can include the value they placed on passengers' lives when making cost-benefit trade offs.

[Jtsummers]

It is reasonable, when your estimates are good and you're honest with regulators and customers. Sometimes your estimates are off by a factor of 10.

https://en.wikipedia.org/wiki/General_Motors_ignition_switch...

And you kill over 100 people, lie to regulators, lie to consumers, and end up spending billions trying to rectify the situation (recalls, settling suits, fines).

[pc86]

Yes, using the outcome of a formula to determine your actions generally relies on the formula being accurate.

[DINKDINK]

It also relies on whomever is modeling the reductive, simplistic "cost model" to know the effect of all the other variables that factor into the companies success. Do these people really think that the legal/compensation costs are the only effect? How many sales did Ford miss out on because they were labeled as the "There is a known issue in this car that might kill you but until your life is worth more than a replacement part we wont repair it" car company? Did they factor in those costs into their revenue model projections? Did they factor in the sag in price point demand "Boss I wouldn't bid the same on that contract because they've shown themselves to sell a known defective product and we'll open ourselves to legal issues if one of their cars kill one of our customers we're transporting in their vehicles"

Despite what an MBA will tell you, the world is more complicated that X<Y*Z

[SilasX]

There will always be things you can do that increase safety at a cost, but some of them will necessarily not be worth the effort, or you're forced to spend without bound on ever-more safety to the point that it's not worth using (and which may push people into still-riskier alternatives).

>How many sales did Ford miss out on because they were labeled as the "There is a known issue in this car that might kill you but until your life is worth more than a replacement part we wont repair it"

If you're turning down a company for making such a tradeoff, that's like saying "I'll buy a Ford rather than a GM because people might die in GMs."

You're right that you can legitimately criticize a company for failing to include certain things as costs, but it's not fair to fault them for somehow making this inevitable tradeoff, especially in the belief that you have some alternative provider that isn't.

(And example of such a cost -- that they can legitimately be expected to but don't -- would be something like "impact on general perception of risk", "impact on reputation of the car industry".)

>Despite what an MBA will tell you, the world is more complicated that X<Y*Z

It sounds more like you're agreeing that it's that simple, but that Z (events worthy of consideration) is not as simple as in typical models.

[Ntrails]

Which is why actuarial reports have around 2 pages of conclusions and 20 pages explaining the assumptions underlying them.

[nkassis]

I also agree with this, security is always in a balancing act with convenience. Yahoo fell to far into the convenience side on this one but that debate on security vs convenience is happening in everywhere. The issue I've seen is that many companies are bad at doing risk analysis about these choices. That's the bigger issue in my view.

[Diederich]

> security is always in a balancing act with convenience

I don't think that's always the case. A whole lot of security can be had with little or no inconvenience, given an appropriate mindset, though one might argue that such a mindset is an inconvenience in itself. :)

> many companies are bad at doing risk analysis about these choices Amen to that!

I think that having a basic, security aware mindset goes a long way, even if there is very little 'budget' or 'ability' to do inconvenient things.

[dsacco]

Philosophically speaking, you cannot improve security without sacrificing usability. What I mean by usability is the capability for someone to do something, not simply convenience for the users themselves. No amount of security can be added without a concurrent decrease in usability, even if that usability is something you didn't expect or want to do.

For example, the user might not see a capability decrease if you use MD5 or bcrypt, but you certainly see a capability decrease because you can no longer see their passwords and you have to do extra work to maintain them securely. Sometimes security decisions are easy, like hashing passwords, because these days no one wants that capability. But sometimes they are not easy decisions.

You can pass a lot of convenience savings on to users by assuming the capability sacrifice yourself (for example, choosing the password hashing algorithm behind the scenes), but you can't do this for everything (for example, mandating two-factor authentication or password resets be masse).

This might come across as pedantic, but it's very important to maintain a mental model this way because it helps you understand risk analysis for more complicated security and usability tradeoffs. Starting from the premise that you can have any security without a decrease in usability is not helpful in that regard.

[jerf]

Your argument is assuming something that I don't believe is true, which is that we're already on the Pareto optimality frontier for security/convenience. It is certainly true that you can not forever increase security without eventually impacting usability, but I don't think many people are actually in that position.

I've improved a lot of real-world security by replacing functions that bash together strings to produce HTML with code that uses functions to correctly generate HTML, and the resulting code is often shorter, easier to understand, easier to maintain, and would actually have been easier to write that way in the first place given how much of the function was busy with tracking whether we've added an attribute to this tag yet and a melange of encoding styles haphazardly applied. What costs you can still come up with ("someone had to create the library, you have to learn to use it") are generally trivial enough to be ignored by comparison, because the costs can be recovered in a single-digit number of uses.

[nkassis]

"Your argument is assuming something that I don't believe is true, which is that we're already on the Pareto optimality frontier for security/convenience. It is certainly true that you can not forever increase security without eventually impacting usability, but I don't think many people are actually in that position"

That's true that we aren't at the sweet spot yet but that what I meant by companies being bad about doing the risk analysis judgement of security versus usability.

On you second point languages have gone through that cycle. Look at Java doing boundary checks. That helps avoid a whole class of security issues but at the cost of making things that C was able to do easily more difficult. These tradeoffs happen at every layer.

[schoen]

> No amount of security can be added without a concurrent decrease in usability, even if that usability is something you didn't expect or want to do.

It seems strange to describe this this way for something like fixing a memory corruption bug or switching from a vulnerable cryptographic algorithm to a less vulnerable one. The capability that you're giving up is ... potentially breaking your own security model in a way that you weren't even aware was possible?

[dsacco]

I think I might not be conveying my point very well. Let me clarify this as succinctly as I can.

Usability doesn't just mean things users want to do. Usability means things anyone (users, developers) can do. By definition, "securing" things means limiting the capability of certain users or developers to do (hopefully) specific things. How efficient you are at this determines whether or not you'll also reduce the capability users or developers want to have when you reduce the capabilities they don't want to have.

To give a concrete example: using a cryptographic algorithm immediately impacts usability along performance and capability axes. Previously, you could arbitrarily read and manipulate that data because it was plaintext. Afterwards, you could not. Now you need to be careful about handling that data and spend developer time and resources implementing and maintaining the overhead that protects that data and reduces its direct usability.

It doesn't matter if you wanted that capability - it's gone either way. That was a trade-off, and it is an easy decision to make, but not all decisions are easy to make. Every security decision can be modeled as a trade-off.

[mst]

I fondly remember the convenience advantages of plaintext password storage, both as a user and somebody supporting users.

Occasionally I wonder if there are user accounts in my life that are irrelevant enough I'd be happy to buy that convenience advantage with the necessary security risks ... but of course people's tendency towards password re-use makes that trade-off basically unofferable in any sort of ethical way.

At least bcrypt makes it moderately easy to not completely screw up the hashing part.

[schoen]

Although I'm tempted to argue against your view, it ended up reminding me of

http://www.oreilly.com/openbook/freedom/ch07.html

and somewhat relatedly https://web.archive.org/web/20131210155635/http://www.gnu.or...

which tend to support your point.

[nickpsecurity]

That's a good example but a bit cherry picked. I could just as easily point out the opposite with accessing an account. If insecure, it still requires a certain amount of information and time upfront then some login just to identify the user. The server will compare that to its local data. The time due to network latency or server load means it usually happens in seconds.

Adding a password that gets quickly hashed by the application to be sent instead costs some extra time. Almost nothing given libraries are available and CPU cycles cheap. If remembering the password, the user has to just type it in once or rarely. The hashing happens so fast that the user can't tell it happened on top of already slow network. Most of the time the user of this properly-designed system will simply type the URL, the stuff will auto-fill, and exchange will take same time. No loss in usability except one time whose overall effect is forgotten by many interactions with identical, high usability.

Likewise, a user coding on a CPU like SAFE or CHERI tagged for memory safety in a language that's memory-safe will not be burdened more than someone coding in C on x86. They will be burdened less by less mental effort required in both prevention and debugging of problems. They could theoretically get performance benefits without the tagging but that's only if incorrect software + much extra work is acceptable. If premise is it's correct, which requires safety much of the time, then the more secure CPU and language are better plus improve productivity. Easier to read, too.

A final example is in web development. The initial languages are whatever crap survived and got extended to do things it wasn't meant to. So, people have to write multiple kinds of code with associated frameworks for incompatible browsers, server OS's, and databases. Many efforts to improve this failed to generate productivity/usability and security. Opa shows you can get both by designing a full-stack, ML-like language with strong types that makes many problems impossible by defaults. Easier to write and read plus more secure. Ur/Web does something similar but it's a prototype and functional programming rather than production.

Conclusion: usability and security aren't always at odds. They are also sometimes at odds in some technical, philosophical way that doesn't apply in real-world implementations. Sometimes getting one requires a small sacrifice of the other. Sometimes it requires a major sacrifice or several.

It's not consistently a trade-off in the real world.

Note: I cheat with one final example. An air-gapped Oberon System on Wirth's RISC CPU uses far less transistors, cycles, energy, and time than a full-featured, Internet-enabled desktop for editing documents + many terminal-style apps. Plus you can't get hacked or distracted by Hacker News! :P

[nickpsecurity]

Ok, let's not talk philosophy and talk capability-based security with CapDesk instead:

http://www.combex.com/tech/edesk.html

They already demonstrated that integrating POLA at language and security level with simple, user authorizations could knock out most problems automagically. Did a web browser that way, too. KeyKOS previously used that model for whole systems that ran in production on IBM's mainframes with checkpoints of apps and system state every 30 seconds on top of that.

Still think you have to screw usability to improve security? And does it matter that it might be true in an absolute sense of some sort if in practice it might be no different (eg File Dialog on Windows vs on E/CapDesk)?

[draw_down]

The point is that not ensuring security also has a cost, one which is harder to see.