Re: [Tails-dev] TorBirdy: first impressions

Delete this message

Reply to this message
Autore: intrigeri
Data:  
To: Jacob Appelbaum
CC: tails-dev, Sukhbir Singh
Oggetto: Re: [Tails-dev] TorBirdy: first impressions
Hi,

Jacob Appelbaum wrote (22 Jun 2012 00:00:36 GMT) :

>> Well... I think I now can see what you're trying to achieve by
>> enabling --throw-keyids, but doing this has a huge cost.


> I agree there is a cost - I think the cost is minimal, any user with
> multiple keys and profiles likely can make a second Thunderbird profile
> as well, no?


In practice: no, not that minimal.

On the only OS family I happen to know a bit, the tools that provide
nice integration of GnuPG in the desktop (read: agent functionality
provided by Seahorse and friends) are user-based and don't support
per-profile --homedir.

Therefore, the cost is "create, maintain and use a OS-level user per
contextual identity", rather than "create, maintain and use
a Thunderbird profile per contextual identity". The difference looks
significant to me.

>> Strategically speaking,
>> I'm not convinced we practically do all of this at the same time:
>>
>> 1. encourage widespread use of OpenPGP for email encryption
>> 2. encourage widespread use of contextual identities
>> 3. a) hide the "an unpublished OpenPGP public key X exists and presumably
>>       belongs to the email address A" information
>>    b) hide the other recipients to a recipient of a Bcc's email

>>


>[...]


> Basically, I want #1, #2 and #3b


We agree at least on this, then :)

> - I'm not too worried about #3a but it
> would be nice to have anyway. For example - I'd like to be able to use
> an anonymous remailer to send a message to you and no one would know
> *which* key is the one they need to beat out of you.


Sure, this would be a nice bonus.

There's a non-negligible range of plausible deniability, on the
recipient's side, that is gained by not disclosing the encryption
pubkey ID.

>> A compromise could be to *not* use --throw-keyids by default, but
>> opportunistically enable it *only* when sending encrypted email to
>> a bunch of Bcc'd recipients. This way, #3.b is covered, and at the
>> same time #2 is not too much harmed. What do you think?


> That might be reasonable. Patches welcome and all that... :)


Well tried :) ...but I don't think I want to ever learn how to hook
into the internals of XUL software with extensions. Life's simply too
short for me to learn every such beast.

With my Tails developer hat on, given Tails currently does not provide
#3.b, the worse that could happen is that we ship icedove + TorBirdy
without #3.b either. Anything *better* that TorBirdy would give us
would be welcome bonus, though :)

Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc