Tails

#1 Updated by intrigeri 2018-11-16 09:48:25

• Assignee changed from intrigeri to sajolida
• Type of work changed from Research to User interface design
• Affected tool set to OpenPGP Applet

> when using the Applet to encrypt with a public key, the result is encrypted only for the selected public key(s).

I did not test this myself but I’ll trust you on that one :)

> when right clicking on a file to encrypt it with a public key, the result is encrypted for the selected public key(s) AND with my personnal public key.

Confirmed. Same using seahorse-tool on the command line (which is what seahorse-nautilus uses behind the hood IIRC, or at least they use the same underlying library).

I think next steps are:

1. Decide which “encrypt to self” behavior is best for each use case.
2. Check upstream bug trackers (OpenPGP Applet, seahorse-nautilus for related discussions and if there’s no strong indication they won’t change their mind, request upstream to implement the behavior we think is best. I’m happy to do that.

Regarding encrypting files in GNOME Files, I see two main use cases:

• Sharing the encrypted file with someone: then encrypting to self does not matter much because the user still have access to the original cleartext file (when encrypting a file in GNOME Files — with seahorse-nautilus — the cleartext file is preserved and a new .pgp encrypted file is created).
• Storing the file more safely (be it locally or in some online storage): they can select their own key in the encryption dialog and again, encrypting to self does not matter much because they’ll be able to decrypt the resulting file either way.

Therefore, seahorse-nautilus encrypting to self is useless in the best case, and an info leak in the worst case. I don’t understand what’s the benefit of the current behavior.

OTOH OpenPGP Applet is primarily meant to encrypt plain text and copy’n’paste it into a webmail composition text area. In that case, encrypting to self would be useful: it allows the user to read the messages they’ve sent later.

So my current position is that:

• OpenPGP Applet should encrypt to self
• Whether seahorse-nautilus should encrypt to self is not clear cut:
  • Keeping the current behavior (encrypt to self enabled) will fix the inconsistency problem raised by goupille, once OpenPGP Applet itself encrypts to self.
  • Disabling “encrypt to self” would avoid an infoleak, at the cost of reintroducing the inconsistency problem raised by goupille, once OpenPGP Applet itself encrypts to self.
  • We should not expect seahorse-nautilus to change behavior without providing patches ourselves. I doubt that’s important to a big enough fraction of our users to invest FT time into it. So it’s safer to assume seahorse-nautilus will keep encrypting to self.

Proposal: ask OpenPGP Applet to encrypt to self.

#2 Updated by sajolida 2019-08-29 06:41:55

• blocks Feature #16688: Core work 2019Q3 → 2019Q4: User experience added

#3 Updated by sajolida 2019-11-21 17:54:34

• Assignee deleted (sajolida)
• Priority changed from Normal to Low

> Proposal: ask OpenPGP Applet to encrypt to self.

Sorry for the huge delay but this works for me. Though → Low.

#4 Updated by sajolida 2019-11-21 18:36:54

• blocked by deleted (Feature #16688: Core work 2019Q3 → 2019Q4: User experience)