> Opal requires as little trust as possible, but you are correct that some server-trust is required at the moment. Unless there is some other mechanism at play

> Opal requires as little trust as possible, but you are correct that some server-trust is required at the moment. Unless there is some other mechanism at play here, it requires full server trust. > I hope that apps like Opal will encourage more progress on browser/javascript cryptography. The W3C crypto spec is coming along nicely, and things like Content Security Policy address some of the concerns about delivering secure javascript. I don't think you can just cross your fingers and hope for the best here. Whether or not it's coming along nicely is debatable, but one way or another the W3C crypto API has no bearing at all on this problem. You're talking about implementing a "secure" service using a mechanism that is known to be insecure. For a mechanism like this to function correctly, it would likely require substantial changes to the way the web browser works that aren't currently on anyone's roadmap. Again, this is not a theoretical problem. Two companies have done the exact same handwaving that you are doing now about users watching tcpdump to verify their traffic, and both of them were functionally destroyed when that handwaving didn't work. It doesn't seem prudent to knowingly put users (or yourselves!) into that position again.