[PLUG] ProtonMail was: Surveillance Capitalism

[John Sechrest]

I have the feeling that the PGP process is not more widely adopted because
of the user experience. You have to go out of your way to get things up and
going. And then you have to be attentive.

It would be interesting to take this "idea toolchain" and come at it from a
perspective of the user experience in the process.

I would submit that if I need to be intentional about keys, privacy and
trust in each transaction that the adoption rate will be very low (As I
think we see with pgp)

Are there ways to fold the "User Actions" into a process, so that the task
of engaging in messaging is secure and yet does not take substantial
intention to keep things going.

I think to make that happen, there has to be more foundational models of
trust and network modeling.

I think that this is what JanRain was trying to accomplish -
https://en.wikipedia.org/wiki/Janrain

However, I don't think that the user experience ever got to the point where
things would widely adoptable.

I also think that the Estonian E-Residency program is actually an
experiment in this same issue of identity and trust modeling from an
entirely different angle. -
https://en.wikipedia.org/wiki/E-Residency_of_Estonia

However, none of these are easily adopted and require you to be remembering
things and caring for things that most people won't really do.



On Fri, Jan 10, 2020 at 11:18 AM Mike C. <mconnors1 at gmail.com> wrote:

> >
> > The ideal toolchain would I think be something like this.
> >
> > 1. End users generate a keypair (ala PGP) and publish public keys.
> > 2. Bob uses MUA-level hooks to encrypt body of message using
> > Carol's public key, signing the message with his private key.
> > 3. MUA submits message to MTA using TLS-negotiated encryption, protecting
> > SMTP header info in transit along with already encrypted message body.
> > 4. Sender MTA delivers messaage to recipient MTA using similar TLS
> > wire-level crypto to protect SMTP header info.
> > 5. Recipient MTA delivers message; body remains encrypted.
> > 6. Carol verifies her trust in Bob's public key.
> > 7. Carol uses MUA-level hooks to decrypt Bob's message using her private
> > key and verifying Bob's key as the sender. Only the in-memory version of
> > the message is decrypted; the on-disk message remains encrypted.
> >
>
> Excellent technical breakdown. It showed me some things I know &
> understand, a few things I don't and one thing I hadn't thought much about.
> Thank you!
> _______________________________________________
> PLUG mailing list
> PLUG at pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
>


-- 
John Sechrest      .  Need to schedule a meeting :
http://sechrest.youcanbookme.com
                                   .
                                        .
                                                .

                                                          .
     sechrest at gmail.com
                                                                       .
                           @sechrest  <http://www.twitter.com/sechrest>

         .
        http://www.oomaat.com
               .