We have GOT TO make things simpler

[halfdog]

Phillip Susi writes:
> 
> Jeff Allen via Gnupg-users writes:
> > The original poster, perhaps unintentionally, stated the real reason the
> > masses have not adopted PGP, "Please do appreciate that the persons who
> > we are convincing and instructing are not particularly interested in
> > privacy."  That's it in a nutshell.  The masses are not particularly
> > interested in privacy.  If they were, they'd abandon Gmail and Yahoo and
> > all the other providers who make no excuse for the fact their economic
> > model depends on users being not particularly interested in privacy.
>
> Bingo!  And as long as the user is not interested in it, and won't learn
> how to properly use it, all they will get is the veneer of privacy and
> learn the hard way that they really aren't secure.  You just can't make
> security idiot proof...

In my opinion this argument has some similarity to arguments brought
up years ago when safety belt use for car driving was made mandatory
by law. Before that the individual driver deemed the safety belt
just an unneccessary obstacle when getting in and out of the car.
Also using it has no benefits for him as he believed to be a low-risk,
careful driver not crashing anyway.

On the other side on whole-society level a noticable loss of workforce,
tragedies was statistically measured, that could be prevented by
belt use.  As with encryption software, even "fool-proof" and easy-to-use
safety belts did not change behaviour, there had to be incentives
in place to trigger adoption ... The main "incentive" introduced
in the end was to be able to use the whole road network without
being annoyed by police asking you for money when you use it.
Therefore the belt-use rate increased quickly ...


So to put that to mail encryption, maybe use this tech-fiction
mind experiment: let's assume, there would be an SMTP response
code to "RCPT: <address at domain>" saying something like
"550 Address rejected, unencrypted message storage not safe, use key [id]".
The only thing the sending SMTP would then need to do is to check,
if the message was already encrypted, if not encrypt it with
the given key, then continue with the secure recipient
call "SRCPT: <address at domain>". The receiving SMTP would
not even need to check if the transmitted message is then really
encrypted, just a well-behaved sender would not maliciously
declare unencrypted data as encrypted.

Why would that be an incentive to get own keys? Because e.g.
your bank, your tax administration, your doctor, your lawer would
refuse to accept unencrypted messages (or to respond to them)
when they deem associated risks of data leakage too high, e.g.
by violating GDPR. So if you as client want to use mail transport
also for these purposes instead of showing up in the office or
installing tons of specialized apps for specifically communicating
with one partner, users would start registering keys, because
they get a benefit from it. As the average dude does not operate
his own SMTP servers, the major mail providers are somehow forced
to provide this functionality with server-stored keys. Still anyone
having motivation to take things further can do local decryption,
even use hardware security modules to avoid key theft.

So in the end safety belt for every one, super-high-quality safety
belts for those, who deem their risks for crashes above average.


I hope I managed to make my point clear. Please do not be picky
if the hypothetical SMTP extension would be the best lever to
provide that incentive for encryption adoption, maybe there are
better ones (or none).

Still I would be interested if my argument seems correct or if
someone can point out serious flaws in it.

hd