[emily37]

All these acronyms for a browser-based service? Even if you trust this company to have good intentions, it seems that the weakest link by far is the possibility of an XSS, a malicious extension, or a CA compromise. And of course the whole thing depends in multiple ways (verifying your identity, logging in if you clear localStorage, etc.) on the security of your inbox. Their crypto and protocol might be fine, but they should be more forthcoming about the many pieces of software that you are trusting when you use their service. I skimmed their whitepaper but didn't see any mention of the ways that they or someone else could in fact see your data.

[bribriinlondon]

You obviously haven't worked in a real business. You would NEVER disclose your internal processes or architecture, that's nuts, it's like drawing out your whole attack surface for your adversary.

Nevertheless, someone asked a follow on question with these exact same points back on the thread; we have posted answers.

It also seems you are being a bit disingenuous. You've studied under Dan Boneh, the founder of our competitor. You know very well what these acronyms mean.

Also, who said this is only going to be "browser based"? Browser's are a good start though....

[emily37]

You obviously haven't worked in a real business.

Yes, I have.

You would NEVER disclose your internal processes or architecture, that's nuts, it's like drawing out your whole attack surface for your adversary.

Though it might not be a bad idea, I wasn't actually intentionally suggesting that you open-source all your code and make your internal processes completely transparent. I was suggesting that you maybe add a section in your whitepaper detailing the possible attacks, and that you reconsider phrases in your marketing copy like: "Who can see your data with PrivateSky™? No one, not even us." I find it misleading.

Nevertheless, someone asked a follow on question with these exact same points back on the thread; we have posted answers.

In the stack exchange thread, you talk about what would be needed to compromise the SkyPin authentication process. But I don't see how this is sufficient. Suppose there is an XSS vulnerability on the browser-based inbox on your site. What stops an attacker from inserting a single line of Javascript that opens up a message of his choice in my inbox, decrypts the contents, and sends the contents to the attacker? Suppose that your SSL private key is compromised. What stops the attacker from eavesdropping on my connection to PrivateSky, stealing my session cookie, and using that session cookie to open up my inbox in his browser? Maybe you have some defenses against these attacks, but you don't seem to address them anywhere (at least that I can find).

It also seems you are being a bit disingenuous. You've studied under Dan Boneh, the founder of our competitor. You know very well what these acronyms mean.

The point was that there is a lot of heavy-handed crypto thrown around and not enough discussion of the actual weakest links in your system.

Also, who said this is only going to be "browser based"?

Definitely not me. The current offering is browser-based, and the currently advertised guarantee is that no one can read your data, not even your company.