On 06/21/2012 05:50 PM, intrigeri wrote:
> 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.
>
I wonder...
> 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.
But why would that matter? Enigmail can specify the keys to be used in
the config, no?
>
> 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.
I'm not sure that I buy that argument - that said - I have a different
use case, I even use hardware with keys (the gpg g10 card) and anonymous
messages aren't a problem in my experience.
>
>>> 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 don't think we really disagree at all. :)
>> - 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.
Perhaps this is an example where the MixGUI can add --throw-key-ids
specifically? That seems really easy to do, no?
A major concern is that someone can learn the sender's key id by
messages being encrypted to the sender's key... A death blow to
anonymity in the mixmaster/mixminion world.
>
> There's a non-negligible range of plausible deniability, on the
> recipient's side, that is gained by not disclosing the encryption
> pubkey ID.
>
Right.
>>> 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 :)
>
What do we need to fix or do for you to ship TorBirdy?
All the best,
Jake
