whisperback_for_frontdesk.mdwn 5.93 KB
Newer Older
1 2
[[!meta title="WhisperBack for frontdesk"]]

intrigeri's avatar
intrigeri committed
3 4
[[!toc levels=2]]

5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170
At the 2015 summit, we identified a few improvements to WhisperBack that
would make the life of our support team easier. Namely:

  - Have user language information in Whisperback ([[!tails_ticket 9799 desc="#9799"]])
  - Add some OpenPGP key checks to WhisperBack ([[!tails_ticket 9800 desc="#9800"]])

Here are some notes and design ideas on how to solve these.

Language information
====================

Our support team can understand and write several languages. But not everybody
in the team has the same linguistic abilities and they also work on shifts.
The process of answering requests would be faster if our team could:

  - Filter incoming requests based on the language they are written in.

  - Know whether the person sending the request understands other languages.

Language of the report
----------------------

We could determine the language in which the report is written by:

  - Using a language detection library.
  - Referring to the LOCALE of the session.
  - Asking the user.

Relevant design question:

  - None of these techniques would be perfect but that's ok.
  - The set possible languages should be limited by the set of languages
    understood by the support team. 
  - The user should be aware this information so as to correct it manually or
    to adjust her writing to the languages understood by the support team.

Languages understood by the user
--------------------------------

This is based on the assumption that many people are more comfortable
understanding than writing another language than their native language.  This
being true both for people writing us and people working in the support team.
For example, it might be all-right for someone writing us in French to receive
an answer in English or for someone writing us in Portuguese to receive an
answer in Spanish.

we could determine the languages understood by the user by:

  - Referring to the LOCALE of the session.
  - Asking the user.

Privacy concerns
----------------

As we received the reports encrypted, it would be most efficient for the
support team to know the language of the report from the email headers. For
example as a flag in the subject of the email as this would allow using email
filters. But this might have privacy concerns.

  - When the user sends the report, we would be telling our WhisperBack relays
  (hidden services), boum.org, and the email providers of the user support team
  that someone sent an report in a given language amongst the one understood by
  the team. This seems acceptable.

  - When answering the report:
    - If the answer is sent in plain text, the language of the report
    would already be known by all the machines relaying the email.
    - If the answer is sent encrypted, we would revealed this language to the
    email provider of the user. This is more serious and should be avoided.

As a workaround, we can decide not to flag in the email headers, the language
of reports that are sent along with an OpenPGP key.

OpenPGP checks
==============

We want to:

  1. Verify that the key matches the email address of the user.
  2. Verify that the key exists.
  3. Be nice to people sending many reports and avoid asking them to paste the
     armored version every time.

In order to ensure 1 and 2, we need access to the public key itself (not only
it's ID).

To solve 3 we could:

  1. Look for a key in the keyring of the user. But we need to ask permission
     before adding it to the report.
  2. Search for a key on the public key servers. But we need to ask permission
     before doing the search.

Proposed design
===============

Mockup
------

<pre>
Summary:  [                                   ]

Email:    [                     ] [ OpenPGP key (optional) ]

Language: [ English       |v] [ ] I understand English.
            French
	    Spanish
	    Italian

Description of the problem:

[                               ]
[                               ]
</pre>

Description of the widgets
--------------------------

  a. `[ OpenPGP key (optional)]` is a button which opens a dialog:

    1. If an OpenPGP key matching the email is found in the keyring
       of the user, then we ask for permission before adding it to the
       report.

    2. Otherwise we ask permission to search for a key in the public key
       servers and then attach it to the report.

    3. If the search fails we ask for an armored OpenPGP key and
       validate it against the email of the user.
    
    4. If several valid keys are found in step 1 or 2 we ask the user to select one.

    5. Once an OpenPGP key is selected the button changes caption to
       `[OpenPGP key: $KEYID]` and can be clicked to run the key
       selection process again.

  b. `[ English       |v]` is a drop-down list with the languages
     understood by the support team. This is a minimal piece of
     information to tell more about the languages understood by the user
     (in addition to the locale of the session) but we believe it's a
     simple and effective first step, useful in most cases.

  c. `[ ] I understand English.` is a checkbox the notify that the
     sender is fine with receiving and answer in English.

Metadata for the user support team
----------------------------------

  - **Language of the report**:

    - If the report has no OpenPGP key associated, then we would add a
      `[xx]` flag in the subject of the email corresponding to the
      language of the down-down list (b).

    - If the report has an OpenPGP key associated, then we would add a
      `Language: ` field in the body of the report.
 
  - **English understood**: we would add an `English: [yes|no]` field in
    the body of the report according to checkbox (c).

  - **Locale**: if the locale of the session is not English and is different from the
    language of the report we would add a `Locale: ` field in the body
    of the report.

  - **OpenPGP key**: we would attach an armored version of the OpenPGP
    key associated with the report.