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
