On Sun, 27 Oct 2013 20:47:14 +0000 Tobias Gondrom <[email protected]> wrote:
The draft I am working on does not really cover this. It is very specifically about making encrypted email practical in a general sense concerning solving the 'encrypted email cannot be spam filtered' and similar problems, regardless of the underlying methods. The webmail problem may not be such a big problem, I am not sure about this but my impression, despite the high webmail use for these large services, is that very large numbers of emails, perhaps the majority, are still not from webmail. That many or most people may have a webmail account, but it is not their _only_ account, they still typically have mail service through their isp using a more traditional MUA - and that is likely what would be used for emails where privacy is desired. I'd like to see the real numbers on this ratio. Even when webmail is used, however, the browser is running on your own computer. So it seems likely to me that something like a browser plugin could encode/decode the body of your emails in the browser input area or viewing area before it is sent or after it is received. The keys could then still be on the local machine. And the remote service (and associated spy agency) would see only an encrypted email body. -Mike > First, I like Mike's idea in principle. > > I still see one interesting problem with this (and have no idea how to > solve it): > The widespread use case of zero-footprint clients, aka webmail: > if you have no client / your client is a browser window for webmail, you > have to upload your private key to the server (and must store it there). > I.e. you would upload your private key to Google and other mail > providers. And a part of PRISM was/is to deploy direct access points on > these servers in the first place. With the access to all webmail servers > and through this to all private keys there, PRISM would at the same time > also retain full access to emails received on full-clients. So while > this might help us against spam, we might in the end not be much better > off against pervasive state-driven surveillance. Or am I missing something? > > Best regards, Tobias _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
