On Tuesday, July 23, 2013 8:54:30 PM UTC+2, Brian Smith wrote: > Couldn't WebMail providers like GMail already use such > an pure-JS PGP implementation without any native browser support?
Perhaps. I wonder where key storage would happen. Once that is determined, they still could in a selective and targeted way cripple such an implementation at their will. > If we provided websites with the ability to use "securely stored" keypairs > to encrypt/decrypt PGP email, then a malicious/compromised webmail provider > could just use those APIs to decrypt your private email. And/or they could > send themselves the plaintext of your email while you are writing it in the > email composer part of the web app. Giving control to the website has benefits and but also major flaws, as you point out. The simplistic options is the website/webmail provider has Zero input to the process. Notice encrypted text, give user option to decrypt entirely outside of the DOM available to the websites own code. Implementations that diverge between the two are also possible. An in either case the user can be given the option to hide the process, or be asked before every decrypt. > If you have a concrete proposal for how to solve the problem where your > email provider could steal the plaintext of your messages even if we > provided native crypto support, then we may be able to make some progress. Apply similar security measures for protecting the in-browser wallet/password-caching systems. Decrypt things outside of the DOM. But this is the vanilla option. I believe trying to rethink the issue like it's 2013 rather than from the mindset of 1992 will be more interesting on the interaction design side of things. > I suggest you start this discussion on dev-tech-network. I suggest trying > to include more specific/concrete suggestions for an alternative to DNS. I > don't think that replacing DNS is completely out of the question, but it > would be a difficult sell. Noted. .p2p (opennic) and .bit (namecoin) come to mind. I will investigate a bit further. For some time I investigated how to build support as an extension. This is not possible due to security pitfalls when making open socket calls from extensions. So this is an area for in-browser support. The distributed DNS systems mentioned are upstarts not ready for default use. But starting support for them with an optional "on" is good step. Next time a state decides to censor at the DNS level users would already have the technology to route around it. > I think it is good to at least file a bug about making it easier for users > to switch their browser to DuckDuckGo. (AFAICT, it is already pretty easy > to switch to DuckDuckGo because they advertise their Firefox extension on > their website. Perhaps we could make the installation of that extension > easier in some way.) for one both duckduckgo and startpage should at least be one of the already available options next to bing and yahoo. > There are many like-minded people within the Mozilla project and even > within Mozilla Corporation. It is relatively easy to create a crypto API > for web pages. The harder part is creating a mechanism that allow websites > to use it in a way that they cannot abuse it. It is relatively easy to > implement a new domain name protocol; the hard part is convincing people > that it is practical to implement it. i would rather suggest mozilla take the issue of crypto as something they should push forward and implement all internally trusting the web pages at a minimum. for DNS, it's a feature few will use until users run into increasing censorship regimes. when a wikileaks.org or wikipedia.org of the future has their domain blocked or taken from them a browser that provides an alternative, even as an optional feature, will shine. it's in those moments that you would also find an influx of developers devoted to improving such features. > AFAICT, the problem with DuckDuckGo is simply that it isn't clear that most > Firefox users prefer DuckDuckGo over Google. So, DuckDuckGo might simply > not be a reasonable choice as a default for a mass-market product like > Firefox. But, we should make it easy to switch to DuckDuckGo if the user > > really wants to try it. > > > > Cheers, > > Brian _______________________________________________ dev-privacy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-privacy
