On 05/07/2015 03:44 PM, intrigeri wrote:
> sajolida wrote (07 May 2015 13:03:23 GMT) :
>> intrigeri:
>
>>> I would move the "Technical details" section to the end, or at least
>>> to after the "Workarounds" one. Most users won't care, and it's
>>> largely duplicating information that's in the introduction already.
>
>> Yes, when I first wrote it the introduction was not as good as it is
>> right now.
>
>> So I won't put a link on "workaround section" as it would jump to the
>> section that's right below and most likely already visible. I personally
>> don't like so much when I jump around a page for little reason.
>
> Absolutely.
>
>> What about "When sending an email from an IMAP account" then? It's a bit
>> less convoluted?
>
> Great.
>
>>>> Delete drafts
>>>
>>> I find it confusing to see this section (that is only about cleaning
>>> up *past* leaks, right?) mixed with other ones that are about
>>> preventing *future* leaks. So either clarify what's the expected
>>> result of this action (and what it is _not_), or expand it a little
>>> bit to cover future leaks, e.g. by pointing to the next sections.
>>>
>>> Also, this section is meant to be followed in all cases, regardless of
>>> the strategy chosen below, right? I think this should be made clearer,
>>> otherwise some users may erroneously believe that they have to pick
>>> among 4 options, one being "Delete drafts".
>
>> I tried to improve on this.
>
> Good.
>
>>>> or, better, through the web interface of your email provider.
>>>
>>> I don't know why it would be better. I think I'd simply remove this
>>> 2nd option.
>
>> I remove the "better". I'll keep this as an option because it's what I
>> would do myself: as Claws Mail is known to do fishy stuff with my draft
>> folder, I would go to the web mail to check what's actually in there.
>
> OK... I see your level of distrust wrt. Claws Mail has reached "I
> don't believe it properly shows me the content of a remote IMAP
> folder". I can emphatize with this feeling, especially after all the
> work you've put into it. Still, I'm not aware of actual facts that
> back up this feeling enough to justify making this doc longer than it
> needs. Anyway, I'll stop insisting now, no big deal, I can totally
> live with the current situation :)
>
>>>> Use the OpenPGP Applet
>> [...]
>> I also end up with *three* of each folder on my
>> screen when doing that on Riseup (see screenshot for both
>> tails@??? and tails-dev@???) but only two on pimienta.org.
>> Maybe there's something wrong on Riseup.
>
> I think that's the result of a email client misconfiguration wrt.
> remote IMAP folders prefixing, that lead to create duplicate folders
> remotely. Perhaps that's been done in the past by another of us,
> perhaps you did it yourself when trying out all possible kinds of
> Claws Mail configuration. Some clients guess what's the remote folder
> name prefix (e.g. 'INBOX.') and hide it, some other clients don't try
> to be that clever.
>
>> But now I removed it.
>
> Good.
>
>>> 2. I'm a little bit wary of recommending usage of PGP/inline.
>>> Were these instructions tested with messages whose cleartext body
>>> contains non-us-ascii chars? I suspect such messages won't be
>>> correctly displayed, once decrypted, by a number of email clients,
>>> due to the lack of encoding charset information.
>
>> I tested it, and here are the results:
>
>> - The received message opens well in Claws Mail.
>> - The received message opens well in the applet.
>> - The received message doesn't open well in Icedove.
>
> I can't say I'm surprised.
>
>> But how is this different from what we are already documenting on
>> https://tails.boum.org/doc/encryption_and_privacy/gpgapplet/public-key_cryptography.html?
>
> That's not intrisically different. However:
>
> * our current doc for OpenPGP applet is aimed at webmail users, who
> can't do PGP/MIME anyway
> * the fact we document suboptimal practices for contexts that don't
> support anything better is no good reason to extend such
> recommandations to contexts that do support PGP/MIME :)
>
>> Because we might have to mention something on this page...
>
> Yep.
>
>> I pushed my work into doc/9161-claws-advisory. Please have a second look
>> if you want.
>
> Done, looks good, great job!
>
> Before publishing, you'll want to check that the attached images don't
> show up in the Atom/RSS feeds.
>
> Cheers,
>
Agreed, great job. And covers almost all my thoughts.
At the risk of lengthening the advisory, is it worth explicitly pointing
out:
- the context of plain-text copies. (It's obvious but) Note that
destined-to-be encrypted email replies often reveal quoted previous
messages in the thread.
- the timing of plain-text copies existing on the server, usually
momentarily for Queue, and for Draft auto-saving, until the draft email
is explicitly sent or deleted.
Glad to see this go out. Will it be posted prominently (front page or?).
The reason I ask is I believe people must be informed about this to take
appropriate action if required.
And I think it will add a lot to the Tails rep to see it widely read and
understood (if not prompt the Claws team into action! :/ ).
Shine,
Adam.
--
Adam Burns
+49 1704552266 (DE)
XMPP: adam.burns@???
51D2 CACB 3604 00E3 05D7 9AE0 E4C7 6DBF E283 909C
GPG Server: keys.gnupg.net
