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
