Re: Bug#766395: emacs/gnus: Uses s_client to for SSL.

["Stephen J. Turnbull" <stephen@xemacs.org>]

Getting the attributions right, I wrote:

 > > > I consider contributions to security technology and policy[1]
 > > > defense of freedom.

And on Tue, 28 Oct 2014 09:31:58 -0400 Stefan Monnier
<monnier@iro.umontreal.ca> replied:

 > > Note that in the context of "secure"boot, digital restrictions
 > > management, and other tivo-ized systems, that same technology is
 > > clearly being used against freedom.

They're being used against *software* freedom.  Without that (or
similar) qualification, it's no longer so clear, as in many cases
other freedoms are being enabled.

Nevertheless, as Perry points out, it's reasonable to consider the
algorithms to be freedom-defending in many cases.  Free software
distributions would be hard put to prosper under current conditions of
criminal behavior on the Internet without signatures, for example.  I
suggest below that the problem is when these technologies are
*embedded* in a hardware product, and the user has no choice about how
they are applied by that product.

Perry E. Metzger rebuts:

 > There's nothing wrong with things like secure boot systems provided
 > they're fully under the control of the user.

Excuse me?  Your main argument in this thread amounts to "'secure
system under the control of the user' is an oxymoron".  That's not
quite true: you personally might be able to pull it off.  But I know
I'm at risk, because I don't have a high degree of expertise.  (I'm
willing to accept the risk because I've learned to be paranoid and
think that the chances that I'll be targeted by a social engineering
threat I don't recognize is low.  But I must acknowledge that risk.)

 > Yes, the same technology has multiple uses, both pro and anti
 > freedom, but that's true of all sorts of things, including
 > computers in general.

Which of course is the argument behind my "consideration" above.
Nevertheless, Stefan and Florian are correct about the technologies
mentioned in current practice.  Furthermore, it's hard to see how it
can be otherwise, since ordinary users do not have access to the
facilities for manufacturing the systems they use, and the convenience
of using systems manufactured by others is huge even if they did.

I'm sure there are ways, but I note that later in the conversation you
acknowledge that it would take a fair amount of thought for you to
design the system itself.  And then there is the politicking and
enforcement against three-letter agencies and wannabe monopolists
necessary to provide a tight legal framework to preserve the freedom
that such a technology would provide.  For the foreseeable future, the
only freedom these particular *embedded* technologies are likely to
defend is that of the manufacturers and their content-marketing
clients.

I note that you and Stefan say that this is getting off-topic, and of
course in one sense you're right.  However, the central tension in the
"rip out SSL3 by the roots" discussion is precisely about whether
users can be trusted not to shoot themselves in the foot enough to
justify the convenience of features that could result in blowing off
their toes.  I think this discussion of freedom-enhancing vs. freedom-
detracting "security" is useful in that context.