If you make cost X so high that X is an existential risk, people/companies will chance it because security isn't binary and "Either way we're fucked if we get a breach".
Or it makes the cost so high that the underlying product becomes impractical. I'm pretty happy to live in a world where I can buy a car for less than $100k, even if that car ends up being much less safe than an S-class.
That's true, but a company can only play that game so many times before it catches up to them. "Never disclose" isn't a workable policy because eventually someone will leak the data.
It's also worth noting that you're talking about a hypothetical, but there are real life examples of this sort of security working despite your claim that it won't work. I've worked for HIPAA-regulated companies. It's certainly difficult to meet their requirements, but it's not impossible, and the regulations do have a real impact on the security of the data.
I'm also not convinced that security isn't a binary. You're either secure or your not, and you're only as secure as the weakest link in your system: that seems pretty binary to me.
A more accurate statement might be that perfect security is prohibitively expensive in many cases. But in many of those cases, data is actually not needed, and is collected because business wants visibility into users, even if that means compromising user security. This divides companies into three camps:
1. Companies where security is cost-effective.
2. Companies where security is cost-prohibitive, but which don't need to collect data.
3. Companies where security is cost-prohibitive, but which need to collect data.
I'd posit that the vast majority of companies are in categories 1 and 2, and that it would be a net benefit to people if all companies in category 3 stopped existing.
> I'm also not convinced that security isn't a binary. You're either secure or your not, and you're only as secure as the weakest link in your system: that seems pretty binary to me.
You cannot use the phrase "as secure as your weakest link" and then assert that security is binary. You're using terms that indicate varying levels of security.
More to the point, security is clearly not binary. You can support login over HTTP, which is quite insecure. You can support login over TLS which is much more secure. You can support only more recent algorithms over TLS which is more secure still. You can enforce two factor authentication, which adds more security. You can make your clients use certificate pinning which makes you more secure yet. You can allow easy access only from known clients and otherwise make the clients go through some extra authentication steps (secret questions, email verification, etc.). You can do the same for known locations.
Each of these options provides different levels of security. None of them are "secure" in any binary sense.
I think the missing piece in what you are saying is that there's an unspoken question here: "Secure against what?"
Let's use your examples to explain:
> You can support login over HTTP, which is quite insecure. You can support login over TLS which is much more secure. You can support only more recent algorithms over TLS which is more secure still.
Secure against what? If it's password exposure you're worried about, then HTTP is definitely not secure unless some other security is used. But given the attacks I know of against older versions of TLS, I don't think it makes sense to say that older versions of TLS are less secure against password exposure than newer versions of TLS, because the vulnerabilities I know of in old versions don't leak passwords[1]. So HTTP: not secure, TLS: secure, for password exposure. It's a binary whether it's secure for password exposure.
If, however, it's unauthorized access we're worried about, the CRIME and BREACH attacks are usable against all versions of TLS for session hijacking, so we could say that neither HTTP nor TLS is secure against unauthorized access. Again, it's a binary whether you're secure for unauthorized access.
So yes, actually each of these options is secure in a binary sense, when you ask what it's secure against.
Security, as a whole, as I see it, is a big `&&` of all the smaller binary pieces of security that matter for a given product. In reality, for most products, you have to be secure against password exposure and unauthorized access. It doesn't matter if you're secure against one if you're insecure against the other--that's what I mean when I say you're only as secure as your weakest link. So when talking about your security as a whole, it really is a binary: either you're secure or you aren't.
[1] This is for the sake of argument--don't take my word that older versions of TLS are secure against password exposure, as I haven't investigated that claim fully.
You're trying really hard to fit this into your binary model. Security is all about managing risk. It's not absolute. TLS didn't change when the CRIME attack was revealed, but it suddenly became less secure because the risk profile changed. But before CRIME, TLS wasn't perfectly secure. There was always the risk that the protocol could have undiscovered flaws, that an attacker could guess the private keys, that a cert authority could issue a valid cert to an attacker, etc.
In a world of imperfect security, talk of binary security is meaningless.
So then companies just never disclose.