Fwd: [liberationtech] PrivateSky Takedown
---------- Forwarded message ---------- From: Yosem Companys <companys@stanford.edu> Date: Thu, Dec 12, 2013 at 9:07 AM Subject: [liberationtech] PrivateSky Takedown Certivox Asked That We Share Their Side of the Story on the PrivateSky Takedown. YC http://www.certivox.com/blog/bid/359788/The-real-story-on-the-PrivateSky-tak... The real story on the PrivateSky takedown. Posted by Brian Spector on Thu, Dec 12, 2013 With the story about our PrivateSky takedown now public, I want to take the opportunity to clarify a few points in various articles that have appeared since yesterday covering the story. Some headlines strongly infer our friends at GCHQ "forced" us to take PrivateSky down. That's not the case. Secondly, a very important point wasn't printed. GCHQ couldn't, by law, request a blanket back door on the system. There are a very rigid set of controls that mean only specific individuals can come under surveillance. The legal request for such surveillance has a due process that must be stridently followed. At no time did I or anyone at CertiVox talk about CertiVox in relation to any RIPA warrant, only the generic process by which these warrants are served. By saying "our friends at GCHQ", there is no facetiousness intended. The team at CertiVox have the upmost respect for the folks we interacted with at GCHQ. They took the due process I outlined in the previous point very seriously. We found that as an organisation, and every individual involved there, were as worried about a breach of public trust as much as we are. Finally, I believe very strongly the following should be a larger part of the public discourse of these subjects. What everyone needs to understand is that every developed democracy in the world, even where privacy rights are enshrined to the maximum efficacy by statute, has laws on the books that mandate that Internet Service Providers have facilities to work with law enforcement for the purposes of legal intercept, to enforce public safety and security. Being L.I. capable is a very important set features and functions that must be in place for any credible, commercial service on the Internet. In endeavouring to make PrivateSky as secure as possible, we overlooked this critical requirement when we built PrivateSky. When CertiVox positioned PrivateSky as the easiest to use and most secure encrypted messaging service, we really had two significant points of differentiation. First, even though we held the root encryption keys to the system, it was architected in such as way that it would have been all but impossible for our internal staff to snoop on our customer's communications, or for the service to leak any of our customerĀ¹s data. Secondly, our possession of the root keys, and our use of identity based encryption, made the system incredibly easy to use. For the user, there were no private or public keys to manage, every workflow was handled for the user in an easy to grasp pure HTML5 interface, no hardware or software required, just an HTML5 browser. We boxed ourselves into a feature set and market position that when called upon to comply with legal statues, we simply had no alternative but to shut the service down. We built it, but we couldn't host it. Why? Because as you can probably surmise, there is an inherent impedance mismatch between being able to host a commercial communications service that gives the upmost in privacy to its users, against any breach, whilst at the same time being able to operate safely within the confines of the law as it is on the books in most countries on the planet. In summary, it's the abuse of the communications interception in the Snowden revelations that has everyone up in arms, as so it should. But thatĀ¹s not what happened with PrivateSky. What is our next move? Watch this space. -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at companys@stanford.edu.
participants (1)
-
coderman