[Differential] [Commented On] D3140: Add formatters for application/pgp-keys and application/vnd.gnupg.wks body parts

[aheinecke (Andre Heinecke)]

aheinecke added a comment.


  In https://phabricator.kde.org/D3140#59900, @dvratil wrote:
  
  > In https://phabricator.kde.org/D3140#59009, @bjoernbalazs wrote:
  >
  > > [1] Uploading your public key
  > >  =====================
  > >  [....]
  > >
  > > - When KMail opens this mail and can decrypt it, it answers automatically to the mail, deletes both, this mail and the answer.
  >
  
  
  Oops sorry, when I read that message I have overlooked this.
  
  I agree with Dan that we need to show that mail. Thats why we want the formatters in this differential.
  
  What we want the user to see is something like the same as registering an account on a website. (Thats why I think Register your Key with your Provider is a good description).
  
  User gets one confirmation mail that needs to be responded.
  
  >> When the server gets the mail it publishes the new public key and sends a mail to the user saying:
  
  
  
  >> - Thank you for publishing your public key. It is now much easier for other people to confidentially share information with you. Learn more about how to protect your privacy at www....
  >> - Overview of key and email address This is an automatically generated mail. Please do not answer to it.
  
  This I also overlooked, I'm really sorry It appears I read that mail with my brain disabled :-/ (I read your message again now). After sending the response we are leaving the specified Protocol. It is not specified that a WKS Provider should send you such a mail. We also would have no control over the contents as it comes from the Provider.
  
  > So I thought about this, and although I understand why you want to remove as much user interaction as possible, I think you are pushing this a bit too far.
  > 
  > Consider the following case:
  > 
  > 1. You receive an email
  > 2. You open it, it says"This email is encrypted, click here do decrypt"
  
  Also at this point a pinentry might pop up asking the user to enter his password.
  
  > 3. You click the "click here" link
  > 4. The email disappears
  > 5. "E-mail sent successfully" notification appears
  > 
  >   What I want to point out here is the "awesome" user experience when user clicks the "Click here to decrypt" link, then the view flickers a little and then the email immediately disappears forever, leading to an absolute "WTF moment" on user side and immediate PR shitstorm that KMail deletes your emails. And in two seconds you get "Email was sent successfully" notification, which is a second WTF moment for the user. If this would happen to me, I'd be scared shitless of whom did I accidentally sent something inappropriate, etc., having absolutely NO way of finding out what happened, since KMail permanently deleted both emails (the request and our response).
  
  Yes. I also think this is wouldn't be the best solution.
  
  > This is IMO why we need to show the email with a "Yup, do it!" button, transforming the flow to:
  
  
  
  >    You receive an email
  >   You open it, it says "This email is encrypted, click here to decrypt"
  >   You click the "click here" link
  >    An explanation that this is a key publishing request appears, explains you what this is good for, has a big button "Accept" (or whatever) and a small text saying that the email will be 
  > 
  > deleted afterwards.
  > 
  >    You click the "Accept" button
  >   Email disappears
  >    "E-mail sent successfully" notification appears
  
  Yes this is also the workflow I image and what I want, too.
  
  Thanks.

REPOSITORY
  rKDEPIMADDONS KDE PIM Addons

REVISION DETAIL
  https://phabricator.kde.org/D3140

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: dvratil, aheinecke, mlaurent, bjoernbalazs
Cc: knauss, emanuel, mlaurent, kde-pim, #kde_pim, spencerb, dvasin, winterz, vkrause, dvratil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20161103/da58b23e/attachment.html>