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 _______________________________________________ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.