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 >> [email protected] and [email protected]) 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: [email protected]
51D2 CACB 3604 00E3 05D7 9AE0 E4C7 6DBF E283 909C
GPG Server: keys.gnupg.net
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
