Hi Trankred, everyone! As a counterpoint, I wanted to briefly discuss Mailpile's take on this. We considered something very similar to what Whiteout are doing, and decided against it for a few reasons. The main ones being:
1. Just because a user has a key in a key server, does not mean they currently can (or want to) read encrypted mail. In particular, many users depend on being able to read incoming mail on mobile devices. Sending them encrypted mail by default would just piss them off. Our gut feeling was that automatically encrypting mail would prove to be so annoying and inconvenient, that people would angrily switch mail clients after just one or two critically important messages were transparently rendered unreadable by the auto-encryptor. People respond very strongly to social cues, so if your mail client makes you look bad to your peers, you'll switch in a hurry. At best people will turn the auto-encryption off, thus rendering the whole exercise futile. 2. As has been mentioned, we feel protecting the user's social graph is just as important as protecting the contents of their messages. Constantly querying key servers (centralized or otherwise) leaks a lot of information, as does the traditional PGP model of signing keys and publishing the result for the world to see. Those are the constraints we're working with, and they are admittedly to a large degree based on our gut feelings and anecdotal evidence, not hard data. I find it very interesting that Whiteout have taken a different approach - if it works well, that probably means we've been overthinking things here at Mailpile. Also, hats off to Whiteout for shipping things. We're still struggling to release something usable, in part because we made choices like this one. :-) Mailpile also want to make it easy for users to encrypt and when possible we would like to do so opportunistically as well. The approach we are working on for achieving this, is roughly as follows: Key discovery: Our preferred method for key discovery is to look in the users own received mail (using Mailpile's built-in search engine). So when the app needs to encrypt to someone for the first time, we first check whether we've got a public key for that recipient in our mail store already. To seed this (and to signal that we can accept encrypted mail), Mailpile puts OpenPGP headers in all outgoing mail and opportunistically attaches our public key. This would be the only key discovery method used for opportunistic encryption. Manual key discovery: When a user wants to encrypt to someone they haven't encrypted to before, the key searching tool checks local mail first, and then goes to HKP servers etc. To protect the user's privacy, we plan to route such queries over Tor as much as possible/safe. Keys are ranked by a few metrics (key size, creation date, etc.) and presented to the user to make a choice. The user can also copy-paste keys or URLs to keys, or upload files from disk. Trust: Like Whiteout, we assume a TOFU trust model. Users can verify keys by hand and we provide tools with which to do so, but we ignore the web of trust. Once a key has been chosen for a recipient using one of the above strategies, that choice is recorded in the address book and isn't automatically reevaluated unless a key is close to expiring or we receive as an attachment a new key signed by the old one. Opportunistic encryption: We plan to again leverage the search engine, to perform a historic analysis of the mail we have received from the recipient of outgoing mail. If the recipient always (within a certain window of time) sends a signal implying their mail client supports PGP (key signals: signing mail, OpenPGP headers) and we have a key for that user, Mailpile will consider encrypting by default to that recipient. User preferences: Each contact in the address book has a crypto preference. The default setting is to use the above heuristics, but the user can at any time force encryption on or off for a given recipient or change keys, and those settings have priority. User interface: In the event that someone sends us mail we can't decrypt, the app detects that and suggests solutions - including making it easy to send back a reply including the correct public key. Note that this is the design we're aiming for - not all of this stuff works yet. Also, this is written from memory, so I am probably forgetting something. Hope this is useful to someone! Comments and feedback welcome. Cheers, - Bjarni -- Sent using Mailpile, Free Software from www.mailpile.is
signature.asc
Description: OpenPGP Digital Signature
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
