Re: [Tails-dev] [review][website] #9356 warn about char enco…

intrigeri:
> tl;dr: I don't think we need an actual reproducer to document this
> widely known and understood problem.

Yes, but it's better to understand how bad of a problem this is to
document it reasonably and be most useful for people to decide what to
do with that information.

> sajolida wrote (08 Jun 2015 13:42:43 GMT) :
>> [...] I failed to reproduce the problem. I encrypted "á ô ü" in
>> Tails OpenPGP Applet (both symmetrically and asymmetrically) and the
>> result opened well in Tails OpenPGP Applet, on the `gpg` command
>> line, and in Icedove.
>
> The first two results are fully expected if both the sending side and
> the receiving one are configured to use the same text encoding (and
> Tails uses UTF-8 both for desktop apps and on the command line).

Ok, so your hypothesis is that there shouldn't be problems if exchanging
emails between two operating system or applications that default to
UTF-8. Did I understand correctly?

> Regarding the third result, just curious (feel free to disregard, as
> IMO it doesn't really matter, as explained below): how did you send
> the email that you later opened with Icedove? With Icedove too, or
> with another email client?

Yes, I sent and received the armored ciphertext from Icedove in Tails.

> Anyway: the root cause of the problem is PGP/inline, and it's a real
> one (as explained in the thread that lead to this bug being filed
> IIRC, the sending MUA has no way to express what's the encoding of the
> cleartext, because it only sees the ciphertext that's encoded in
> US-ASCII). In some cases, and even possibly in the majority of cases,
> it works because the receiving MUA's assumptions are correct, but it
> cannot possibly *always* work because there's no robust way to
> correctly guess the encoding of a bytestring in all cases.

If we think this issue is "dangerous" or that PGP/inline should
disappear from the cyberspace, then we might be better off stopping
recommending Tails OpenPGP APllet as an option in the first place.
But I'm volunteer to investigate this further or take that decision.

In the meantime, I'll propose the following changes to emmapeel:

- I understand that this problem is true for both symmetric and
asymetric encryption so it should rather go in
doc/encryption_and_privacy/gpgapplet.warning.
- Maybe mark this as a "bug" instead of a "note".
- Rephrase "This method to send email (with OpenPGP encryption inline)"
to avoid the parenthesis and the word "inline". What about "Encrypting
emails with Tails OpenPGP Applet" instead?
- Downsize the importance of the issue in term of frequency by replace
"might" instead of "can".
- Use "email" instead of "mail", and "emails" in plural.
- Explain what are non-ASCII characters, maybe adding in parenthesis
(for example non-Latin characters or characters with accents).
- Make it more clear that this happening on the receivers side,
somewhere around "issues in mail clients".
- Replace "a [[mail client]]" by an explicit reference to our mail
client, "Claws Mail" (for the time being).
- I would try to replace "encoding" with "display" and "issues" with
"problems", maybe "problems in the display of characters" or "display
problems" or something like this...
- Maybe turn around the sentence, use passive voice (yeah!) and try
something like "non-ASCII characters () might not display correctly to
the recipients of the email".

And sorry for the messy comments, but that took me longer than I wished...

--
sajolida