Revisit TOFU strategy, taking user feedback into account #1693
Comments
|
Relates to #912. |
|
RFC2440, section 6.2, allows "Armor Headers" after the usual Armor Header Line. -----BEGIN PGP SIGNATURE----- mIsETUmNdwMEANil5/BqR2ovyqN9TjLI5VCuyFTTC9AHwTqxzofmCIuom9EGq90x When I get time I'll actually try this in a attachment with a .txt file extension. |
|
IMO a one-line comment is not nearly enough. Think big! I'd rather put a big block of something friendly BEFORE the ----BEGIN PGP SIGNATURE--- and hope that the parsing software is smart enough to ignore it. If that works we can actually format this as a .html file, and put some nice formatting in. Like this: |
|
Well, the advantage of using the Comment defined by the RFC is that any RFC compliant software will process it correctly. Adding an HTML comment before the signature is very cool, but introduces a testing problem - you have to try it with all the email clients that casual user recipients are likely to use. That is, unless more study of the standards shows that it is in fact standard compliant! |
|
The issue in this case is users that do NOT have compliant software. Most people who are experiencing confusion are using software with no support for PGP and they're just trying to open up the attachments using their standard operating system tools. But yes, you're right that some testing will be required! |
|
A quick test implies that GPG itself is perfectly happy to ignore HTML boilerplate, for detached signatures. I am pretty sure the same will apply to keys, after all that 's what the ----- markers are for. Since most mailers should rely on the MIME types to detect signatures, I suspect we'll have no problem changing the file names to signature.asc.html and key.asc.html ... |
|
... the remaining question becomes: how many e-mail clients and corporate firewalls and things block/mangle .html attachments for security reasons? Is there another container document that would be more likely to make it through intact and lets us embed visible and detectable plain text? Plain .txt is the baseline, maybe .rtf or even .docx would work? |
|
Actually the .html extension is a neat idea since it will certainly work in any webmail client by definition, and virtually all systems can open an html file. |
|
I think .html might be a good first attempt, and if feedback suggests it's not working we iterate. |
|
adding a bunch of related thoughts of mine about signed-only mails in general: https://k9mail.github.io/2016/11/24/OpenPGP-Considerations-Part-I.html |
|
HTML wrapping is coming up in a PR soon. Also: I think it would also be worth reworking the key attachment logic to not automatically attach keys if we have message history for the recipient AND the history shows no sign they are crypto-capable. Crypto capability is currently (should be) detected by looking for PGP signatures or the OpenPGP header in incoming mail. If we don't have any message history (we're cold-emailing someone for the first time), proposing the key be attached seems reasonable. But if we have history that tells us their mail client can't do crypto, we probably shouldn't bother them with keys. It's possible we shouldn't even bother them with signatures... |
|
I think the technical side of this issue is now solved, for now - we'll see how the code works in practice. The security roadmap needs updating though, can't close until that's done. |
|
Updated! |
For the past year or so, I have been "living the dream", signing all my outgoing mail and opportunistically sending keys to new interlocutors.
This has given a few insights, which should be folded back into our Security Roadmap and the code itself:
Inline signatures, although ugly, do not appear to confuse any recipients, ever. Their main drawback is that cruft accumulates as quoted content gets requoted again and again.
Attachments, whether signature.asc or attached keys, are VERY CONFUSING. I regularly get e-mails back from people telling me they couldn't open the attachments I've sent them, even after I've already explained to them what the files are and that ignoring them is safe.
Lessons, potential solutions:
This validates the current default preference for inline signatures over PGP/MIME. Although ugly, it's actually more usable. Some automatic clean-up of quoted content would probably be justified.
We need to send these attachments less often and/or make them actually useful to the recipient. The confusion is actually bad enough that I've started manually preventing Mailpile from attaching keys; and if a true believer like myself does this, we should expect less motivated users to simply disable the encryption features or abandon Mailpile entirely. This needs to be fixed.
One way to make detached signatures and attached keys "useful" to recipients that don't have PGP, is to modify their contents so they appear as normal text or HTML when opened by the user, and contain some description of what e-mail encryption is and why. IF this sort of thing can be done without breaking compatibility with PGP-enabled mailers, this would be big win and could also advertise the project in a positive way. It will cost some bytes but reduce friction.
The text was updated successfully, but these errors were encountered: