Re: Deprecate TLS1.0 support in emacs

[Lars Ingebrigtsen <larsi@gnus.org>]

Robert Pluim <rpluim@gmail.com> writes:

> There is no refusal of access, just refusal of a specific protocol. If
> we implement your suggestion from below there won't even be refusal.

It is a refusal to access a resource because somebody has determined
that a specific protocol (HTTP + TLS1.0) is something that our users
shouldn't be able to use.

lists.gnu.org is, of course, just one example.

> I appreciate that's a strong opinion, but I definitely think we should
> strongly encourage people to move away from both of these protocols.

Encouragement is fine, but making our users switch to Firefox because of
this obsession with protocols isn't.

As more and more resources are being made available over encrypted
channels only, and as more and more of these (as a result of bad
maintenance and the like) get tagged as "invalid encryption", something
has to give.

It seems like the current movement is to just to start ignoring whether
protocols are outdated, use invalid certificates and the like, and just
tell the user "you tried to access this via a secure channel.  It's not,
but here's the content anyway".

I may be misremembering, but I think the new Chrome beta is going in
this direction: No explicit refusals to access anything, but just a big
red X in the menu bar saying "UNSAFE".  It is, you know, not less safe
than accessing via an unencrypted channel.

I think this is probably the way Emacs should consider moving, too, for
eww and package-list.  For other use, we may consider having the NSM
prompt the user for what to do with TLS1.0.  But probably not just yet.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no