[zAy0LfpBZLC8mAC]

While you might be formally correct, your criticism still seems about as sensible as criticising someone who said "a tank made of paper sheets is not secure" because they failed to specify a threat model. After all, such a tank would be secure against a paralyzed attacker without weapons.

Yes, it is important to be aware that security is always relative to a threat model, and at times it can lead to confusion when threat models are not made explicit. That does not mean, though, that it's necessarily wrong to imply a sensible threat model in a given context, and to just call something "insecure" without any further explicit qualifications if it does not protect against a reasonable minimal threat model that essentially everyone essentially always has to face.

Also, it's questionable whether you can call the NSA's mass surveillance a passive attack, given that QUANTUM INSERT exists and was used, in order to attack foreign communications infrastructure.

[bren2013]

This is also precisely the problem I was trying to avoid by introducing formality.

Is it like saying that a tank made of paper sheets is insecure, or is it like saying that a heavily-armored tank is insecure (against a nuclear weapon)?

It is never okay to omit important information like the threat model in cryptography. That information is essential to the system's analysis.

[jarrett]

> Is it like saying that a tank made of paper sheets is insecure

Yes, I'd say it's more like that one. The technology is insecure against threat models it is almost certain to face.

> or is it like saying that a heavily-armored tank is insecure (against a nuclear weapon)?

No, I don't think it's like that one. A tank could realistically participate in a nuclear conflict, but that's not necessarily what a tank is intended for. Whereas, JS crypto is presumably intended to protect users when the remote server can't be trusted. (What else would it be for?) It can't offer such protection.

[rmrfrmrf]

What about a secret message web widget on a shared computer that uses localstorage as a database and requires the recipient to enter a password to reveal the message, or an offline diary app made with node-webkit that encrypts diary entries? There are lots of uses for JS crypto in cases where information will never leave a local computer. I know that's not what you were saying, but I think it's important to realize that JS has gone beyond remote delivery at this point.

[jdbernard]

The problem is that with the in-browser use case, which is what this whole discussion is about, the code being executed locally came from a remote source. For all of the reasons that Monsanto and the others name it is impossible to ensure that the code does what it claims to. So even if all of your data is stored locally, you have no strong way to ensure that the code that is performing the cryptographic functions is not secretly compromised by an attacker so that, for example, it sends your data in clear to some remote server.

[zAy0LfpBZLC8mAC]

Even though it often isn't spelled out, this is mostly about content-controlled JS loaded from the web, though the language itself also has its problems. And security-wise that app would not be better than one that stored the messages on a server, which only allows you to read them back when you provide the password.