intrigeri:
> 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/
Thanks for answering my RFC :)
>> [...] 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.
Sorry for that. I used non-affirmative phrasing as we were of course not
sure whether what we were writing was the proper solution.
> 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:
Good idea!
> * any proper email client can filter incoming reports just as well;
It's possible in Thunderbird but a bit more complicated than the headers
that are available by default. It will require a bit of documentation
not nothing complicated.
> * 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).
That's a good idea!
> 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 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'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?
> 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.
Sure. Then the limitations expressed above regarding Thunderbird for
example could be obsolete in such a system.
> 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.
Thanks for sharing your concerns. I didn't had them in mind.
> 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;
Sure. That's case "1) Look for a key in the keyring of the user".
> 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.
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.
> 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.
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.
