Re: [Tails-dev] [RFC] WhisperBack for frontdesk

このメッセージを削除

このメッセージに返信
著者: sajolida
日付:  
To: The Tails public development discussion list
題目: Re: [Tails-dev] [RFC] WhisperBack for frontdesk
intrigeri:
> 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?


Granted. "Watch Thread" could work. It adds an "eye" icon by the thread
(see attachment). I'll ask frontdesk whether if it's good enough for them.

>> 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.


I'll update this on the blueprint at some point. I'm glad we reach an
agreement on the engineering side of things. I still haven't received
feedback from frontdesk since November 30 so it seems like my "clients"
are not really in a hurry.