[jarrett]

> It still might protect you if you won't access server while it's compromised.

The end user can't know when that's the case.

> Also you might serve files that do the encryption from different server that's smaller, better protected, more stable, that less people have access to.

That doesn't provide any assurance to the end user that the JS isn't malicious.

Remember, "compromise" doesn't just refer to a drive-by hack. The site operators themselves may become compromised (or start that way), and deliberately serve malicious JS. Users can't know when that's the case. When it is the case, the strategy you suggested offers no protection, because the "more secure" JS server is still under the control of the bad actor.

[scotty79]

>> It still might protect you if you won't access server while it's compromised. > The end user can't know when that's the case.

Yes. I didn't say that user can know if he is protected. Just that he is when this condition is met.

> Remember, "compromise" doesn't just refer to a drive-by hack. The site operators themselves may become compromised (or start that way), and deliberately serve malicious JS. Users can't know when that's the case. When it is the case, the strategy you suggested offers no protection, because the "more secure" JS server is still under the control of the bad actor.

Didn't you just do what OP criticizes? I said it has value in some scenarios assuming some threat model and you countered by showing that it doesn't protect you in some other threat model. When you don't trust the third party the only way to protect yourself is never rely on what they control. Especially never run their software on your machine in a way that has access to your secret data. In that scenario any type of encryption other than built in the browser binary (not supported? risky?) or better yet outside of browser (cumbersome) is pointless.

[tinco]

> > It still might protect you if you won't access server while it's compromised. > The end user can't know when that's the case.

This is the entire point of the article. You can't know if it's the case, you can't either with any software distribution. When you type 'apt-get install opensshd', how do you know if you're getting the package from an uncompromised server?

You just have to trust that the public keys you got are the right ones, and their private keys have not been stolen.

So what the author is saying is that regarding that aspect web crypto is at roughly the same level.

The big problem of course is that there is evidence that the whole CA system is much less reliable than the old GPG signing party system.

[jarrett]

> When you type 'apt-get install opensshd', how do you know if you're getting the package from an uncompromised server?

If you don't take any steps to verify the integrity, then you don't know.

The big difference, as I see it, is that the JS code gets served over and over again to the same clients. Every time you visit the website, it can load a new version of the JS.

[eric_bullington]

Even if you do verify the integrity of the package, then you still can't know for absolute certain that the package maintainer hasn't somehow exposed their private key or been otherwise compromised. You have to trust them.

[jarrett]

If the package maintainer has exposed their private key, and yet the package itself in intact, what harm is there (at the moment)? With the key compromised, you could have been MITMed, but you weren't. You could be MITMed in the future, but that's a problem for another day.

[eric_bullington]

I just saw this reply, and I have to clarify: the moment the maintainer's key is compromised, it becomes possible for someone to MITM. It's not clear if that's what you were saying, but that's how it is, and that's absolutely a problem as soon as the key is compromised (particularly if he/she was targeted).