Feature #16223

Document Autocrypt

Added by hefee 2018-12-13 18:19:22 . Updated 2019-02-09 15:50:19 .

Status:
Confirmed
Priority:
Low
Assignee:
Category:
Target version:
Start date:
2018-12-13
Due date:
% Done:

0%

Feature Branch:
Type of work:
End-user documentation
Blueprint:

Starter:
Affected tool:
Email Client
Deliverable for:

Description

We are not very happy about Autocrypt. As we have a different audience in mind, than the creator of Autocrypt. We should communicate this to users. Maybe we can use the personas for whom Autocrypt is a great thing, and for whom not.

Arguments:

  • it sometimes leads to send unencrypted mails (if you are not very watchfull)
  • it can be broken by MitM attacks (not working for thunderbird atm, as it does not use any new key advertized by Autocrypt)
  • but very easy to use (no need to send keys, keep them updated etc.( in theory see point above) )
  • better than send unencrypted messages
  • implement a proper secure way to exchange private key between your devices, can be used without using the rest of Autocrypt

Subtasks

Related issues

Related to Tails - Feature #16299: Disable Autocrypt even for existing persistent Thunderbird profiles Rejected 2019-01-14

History

#1 Updated by intrigeri 2018-12-17 15:56:35

  • Assignee set to hefee
  • QA Check set to Info Needed

Regarding “wiki”: do you mean, somewhere in our doc?

Regarding “release notes”: for 3.11?

#2 Updated by hefee 2018-12-17 19:55:12

Hey,

> Regarding “wiki”: do you mean, somewhere in our doc?
> Regarding “release notes”: for 3.11?

I currently don’t know what is the best place for communication this. I think “release notes” should mention the current situation. I thought there is documentation about encryption mail traffic. Maybe support/known_issues is a good place to mention it.

#3 Updated by hefee 2018-12-17 19:55:30

  • Assignee changed from hefee to intrigeri

#4 Updated by intrigeri 2018-12-18 08:05:29

  • Assignee changed from intrigeri to sajolida
  • Type of work changed from Communicate to End-user documentation

OK, seems like doc to me. sajolida, what do you think?

#5 Updated by mercedes508 2018-12-18 12:20:58

  • Status changed from New to Confirmed

#6 Updated by sajolida 2018-12-18 18:22:10

  • Subject changed from Add Autocrypt to wiki/release notes to Document Autocrypt
  • Assignee deleted (sajolida)
  • Priority changed from Normal to Low
  • QA Check deleted (Info Needed)

For the time being, I think that we made the right decision of disabling Autocrypt by default for the reasons that you stated. So our users who are used to OpenPGP are fine, unless they decide to enable Autocrypt themselves.

What would be worth documenting could be:

  • That Autocrypt is disabled in Tails by default and why it might be dangerous to enable it.
  • When and why it might be useful to enable Autocrypt in Tails.

I think that this should be all written in /doc/anonymous_internet/thunderbird.

Now that Autocrypt is disabled by default, this is probably relevant to a very small portion of our user base so I don’t think it qualifies are core work and I’m marking this as “Low” prio.

#7 Updated by hefee 2018-12-19 12:54:08

sajolida wrote:
> For the time being, I think that we made the right decision of disabling Autocrypt by default for the reasons that you stated. So our users who are used to OpenPGP are fine, unless they decide to enable Autocrypt themselves.
>
> What would be worth documenting could be:
>
> * That Autocrypt is disabled in Tails by default and why it might be dangerous to enable it.
> * When and why it might be useful to enable Autocrypt in Tails.
>
> I think that this should be all written in /doc/anonymous_internet/thunderbird.
>
> Now that Autocrypt is disabled by default, this is probably relevant to a very small portion of our user base so I don’t think it qualifies are core work and I’m marking this as “Low” prio.

So far I know with 3.10 it was enabled, so every user, that have started Thunderbird within 3.10 got Autocrypt enabled. And hunderbird wrote this setting to the prefs.js for this specific mail account. The fix for 3.11 is only, that Autocrypt is not enabled by default. That’s why, I think that there are more users affected.

#8 Updated by sajolida 2019-01-05 17:15:17

  • Assignee set to hefee
  • QA Check set to Info Needed

Ok, I didn’t think about that! Then I don’t think we can rely on documentation to fix all these installations and prevent further damage…

It would also imply that all users have to either analyze their upgrade paths or check their settings manually or otherwise risk sending unencrypted emails.

Should we have a migration script that disables Autocrypt wherever it finds it enabled in Tails with the previous settings: AutoCrypt enabled + no acPreferEncrypt?

We could leave the script around until for some development cycles to clean stuff up and document that, if people really want AutoCrypt, they can enable it and also enable acPreferEncrypt (so it’s not disabled automatically).

If you think that’s an idea that is worth discussing, we should move it to its own ticket.

#9 Updated by hefee 2019-01-05 17:47:01

sajolida wrote:
> Ok, I didn’t think about that! Then I don’t think we can rely on documentation to fix all these installations and prevent further damage…
>
> It would also imply that all users have to either analyze their upgrade paths or check their settings manually or otherwise risk sending unencrypted emails.
>
> Should we have a migration script that disables Autocrypt wherever it finds it enabled in Tails with the previous settings: AutoCrypt enabled + no acPreferEncrypt?
>
> We could leave the script around until for some development cycles to clean stuff up and document that, if people really want AutoCrypt, they can enable it and also enable acPreferEncrypt (so it’s not disabled automatically).
>
> If you think that’s an idea that is worth discussing, we should move it to its own ticket.

Sounds like a good idea. As I just learnt from KeePass, we are also able to show dialogs. If we detect AutoCrypt enabled + no acPreferEncrypt we can either ask the user if they want to switch something safe or just display a warning.

#10 Updated by hefee 2019-01-05 17:47:24

  • Assignee changed from hefee to sajolida

#11 Updated by sajolida 2019-01-05 18:16:54

  • Assignee deleted (sajolida)
  • QA Check deleted (Info Needed)

I created Feature #16299.

I’m setting back the metadata of this ticket to their state after Feature #16223#note-6.

#12 Updated by sajolida 2019-01-05 18:17:04

  • related to Feature #16299: Disable Autocrypt even for existing persistent Thunderbird profiles added

#13 Updated by sajolida 2019-01-05 18:17:21

  • related to Feature #16299: Disable Autocrypt even for existing persistent Thunderbird profiles added

#14 Updated by sajolida 2019-01-05 18:17:51

  • related to deleted (Feature #16299: Disable Autocrypt even for existing persistent Thunderbird profiles)

#15 Updated by intrigeri 2019-02-09 15:50:10

Not needed to solve Feature #15923.

#16 Updated by intrigeri 2019-02-09 15:50:19

  • Affected tool set to Email Client