[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).