Re: [Tails-dev] [RFC] WhisperBack for frontdesk

Üzenet törlése

Válasz az üzenetre
Szerző: intrigeri
Dátum:  
Címzett: The Tails public development discussion list
Tárgy: Re: [Tails-dev] [RFC] WhisperBack for frontdesk
hi,

sajolida wrote (11 Mar 2016 16:13:18 GMT) :
> intrigeri:
>> The disadvantage is, of course, that any email in the thread after the
>> initial reply will lack these headers. So, depending on how email
>> filtering is done exactly, these threads may be broken (for example,
>> the initial report might be sent into some language-specific folder,
>> while the follow-ups won't be).


> I tried and couldn't find how to do this in Thunderbird. If a filter
> moves the first mail of a thread to a folder based on some headers, then
> I don't know how to get the next emails in the same thread moved to the
> same folder if they don't match the filter themselves.


I can't say I'm surprised.

>> I'm pretty sure that using more
>> powerful email filtering techniques than send-to-folder would solve
>> this problem.


> Are you referring to any specific technique that could be used in Tails
> by our current user support crew?


No. I meant that if one forgets about folders as The™ way of creating
the desired view, I'm pretty sure this problem has a solution. E.g.
I see "Watch Thread" as part of the possible actions for filter rules
in Thunderbird — that could be one acceptable solution, maybe?

>> b) or, the user is reporting a bug from a system where they don't use
>>    OpenPGP, but they have an OpenPGP key on another system => how do
>>    we make sure they properly validate the key found on the
>>    keyservers?


> The problem you are raising here is valid but note that it's already the
> case currently as we ask them for "a key ID, a link to your key, or the
> key as a public key block" with no guarantee that they are in possession
> of the corresponding private key material.


OK.

> And this was not stated as a goal in our RFC nor in the request from
> frontdesk (maybe it should). The objective here is to make the work of
> frontdesk easier, without lowering the security level.


Got it, and it makes sense to me.

>>    Even assuming they have a second computer running, that
>>    hosts their OpenPGP key, they would need to compare fingerprints
>>    digit-by-digit. Unless you had some QRcode -based solution in mind,
>>    or something similar, I don't believe most users will actually
>>    verify the key that's available on the keyservers, so the problem
>>    boils down to: is picking a key that "looks like mine" from the
>>    keyservers better than cleartext email? This last question is
>>    a real one, not a rhetorical one: I don't know the answer. It's the
>>    good old "let's maybe add some security" problem, mislead feelings
>>    of security, etc., you know the drill.

>>
>> I personally would just avoid supporting case (b), to avoid the work
>> needed to get it right. If you're looking for low-hanging fruits,
>> I suggest you do the same. If you're excited at the idea of diving
>> into a potentially hard problem, well, then: enjoy :)


> Let's think about user scenarios for a minute. Case b) could apply to
> people who are using Tails for some activity (anonymous browsing,
> testing, etc.) but don't have their OpenPGP key in it.


> The first persona that comes to my might is some free software geek,
> let's say a Debian developer, who uses Tails to test it and is a regular
> OpenPGP user without having her key in Tails because she has no use for
> it. Another one could be a security trainer who uses Tails to try out
> the latest features or to debug some issue she's heard of from a trainee
> but she keeps her private key in Qubes OS only.


> Supporting only case a) would prevent them from getting an OpenPGP
> encrypted answer. Maybe they doesn't care as they are only experimenting
> and not facing privacy-critical issues themselves. Maybe they care
> because they're sooo much into OpenPGP :) But still, not supporting
> these kind of scenarios and taking for granted that people who want
> OpenPGP encrypted answers from us MUST have their private key in Tails,
> not only raises the bar from the current situation but might also lead
> to less reports from knowledgeable bug reporters.


OK.

> Then, what about forcing them to paste the full public key (and not only
> the key ID or a link)? This would prevent us from fiddling with key
> servers while still allowing us to solve "1) Verify that the key matches
> the email address of the user." and "2) Verify that the key exists.".
> It doesn't solve "3) Be nice to people sending many reports" for these
> persona and actually make the situation a little worse for them; but way
> nicer for the ones who have their private key in Tails, so maybe that's
> fine.


Sounds good wrt. scoping and end results. Plus, it addresses my
concerns about who will maintain that code once it's been written.

Cheers,
--
intrigeri