Hi, sajolida wrote (30 Nov 2015 17:56:42 GMT) : > On our roadmap for 2016 we put some minor improvements to WhisperBack > regarding languages (#9799) and OpenPGP keys (#9800). We started working > on this with Alan [...]
\o/ > [...] but I'm actually more interested in feedback from tails-dev regarding > the privacy issues we're raising in the blueprint. Meta: I've found it hard to understand what is the actual set of proposals, given vague phrasing such as "we could" and "we can decide". So I've initially assumed the blueprint was the result of a brainstorming session, rather than as a concrete proposal, and started commented on what inspired me. And then, after spending a while on it I realized that there actually was a concrete proposal... at the end of the page :-( So, I've added a table of contents to the page, in the hope it helps avoid anyone else facing the same problem I did. Regarding languages: I wonder if the email Subject header is the best way to convey the information you want to pass around. Let me elaborate on another idea. If custom headers were used (say, X-Tails-Report-Language and X-Tails-Languages-Understood-By-User), then: * any proper email client can filter incoming reports just as well; * the privacy concern you raised for the "When answering the report" case disappears (as long as Schleuder is not configured to let these X-Tails-* headers through). The advantage is that the "not to flag in the email headers, the language of reports that are sent along with an OpenPGP key" workaround is not needed ⇒ better filtering of incoming reports, simpler implementation in WhisperBack, and more consistent workflow for frontdesk. 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'm pretty sure that using more powerful email filtering techniques than send-to-folder would solve this problem. Anyway, I see that there are plans to move away from a pure email -based workflow, to a proper request tracking system that shall be chosen this year, so I'd like to avoid putting too much effort into implementation details that are bound to a particular technical solution, that may be obsolete in a year or so. So perhaps we should discuss the problem at hand in more abstract terms than email headers. Ideally such a request tracker will understand metadata encoded in the (encrypted) email body, and be able to expose said metadata in a way that's useful for frontdesk members. Regarding the "OpenPGP checks" section: I think that looking up a key on the keyserver network is not an easy problem. One issue is that it adds quite some implementation complexity, and the history of unaddressed privacy issues in WhisperBack does not make me wish to see it grow bigger than needed. But even ignoring that, as I see it: a) either the user is reporting a bug from a system wher they use OpenPGP => their key is in the local keyring, no need to look it up; 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? 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 :) Cheers, -- intrigeri _______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
