On Fri, 9 Sep 2011, Aristotle Pagaltzis wrote:

Protecting your communication with another party from third
parties needs no justification whatever. It should be the assumed
default that exceptions are made from, not the exception from the
rule requiring proof.

If I?m having a massive argument with my personal foe #1, the
fact that I distrust this person on all conceivable levels does
not make you welcome to eavesdrop on the conversation.

It does not matter the very least bit how trustworthy the other
party is: uninvited third parties have no business knowing what
you do or do not say to the other party.

This is about assessment of risk, and in the example of Google that's
exactly what you're missing.  I would agree with you if your traffic was
going to a trusted party, i.e., a server under the control of entities you
know and trust.  But it's not.  So who's the greater danger to you?  The
megalith cataloging and profiling all of your communications across multiple
networks and devices, or the script kiddie at the next table?  It should be
obvious who has the greater ability to harm you.

And that's what makes so much of this thread ridiculous.  Some here are
excessively paranoid about the most peripheral and fleeting contacts, yet
don't care about the data mining operation that you're "securely" funneling
all your information to.  If that's what makes you paranoid, then I'd have
to say you're not paranoid enough, not by a long shot.

That?s the ?I have nothing to hide? argument.

No, read above.  It's the "assessment of risk" argument.  And one that's
pertinent on many, many levels.  As has been pointed out by several parties
on this list, SSL-everywhere is not a zero-cost proposition, so if you're
going to go to that length there should be tangible benefit.

It does not matter how embarrassing it is or isn?t. Irrelevant.
It?s much simpler: unless they want you to know (or it affects
you directly in some undue manner etc. ? insert reasonable
qualifiers here), you have no business knowing. How yawn-worthy
that information is makes no criterion.

The one criterion that does apply is whether making the channel
secure against you trying to find out is too expensive relative
to its sensitivity. So far, MetaCPAN seems to be less than
straining under the load, so I don?t see a justification to
reconsider.

We used to avoid SSL unless necessary because it was expensive.
I agree with the engineers who are saying that it?s time to
re-examine that as a default assumption ? whether they are
employed by Google or not makes no difference to me as far as
that statement is concerned.

Someone else pointed out that SSL is not trivial or low cost to many
embedded devices.  That's true.  I pointed out that it makes traffic shaping
and caching strategies to relieve backbone congestion extremely more
complicated.  It may be cheap for servers to terminate those connections
with the power inherent in the average modern server, but that's just
technical narcissism.  It gives no thought to the rest of us at all.

You won?t see me disagreeing that the concentration of power in
Google?s hands is dangerous. But that?s a different matter, even
though very important in its own right. Abolishing Google would
not reduce the justification to secure communications. The two
issues are independent ? so the question you pose is entirely
beside the point to the matter at hand.

I have no wish to abolish Google, and this isn't just a Google problem, it's
a social media problem, a search engine problem, it's a problem of trust
with any third party that you lack contractual safeguards or control over.

That said, I still think we should have an actual *benefit* before we slab a
dollop of SSL on everything.  I'm not opposed to metacpan having an SSL
interface, but why on earth would you place barriers to use on a public
resource, containing public information?!  That's the operators of metacpan
forcing their peculiar dogmatism and fanaticism on the rest of us.  Which I
don't actually have a problem with as long as they're not the *default* or
*only* repositories of that information.  But if they aim to become such
they need to be bent on maximum accessibility.  That's just common sense.
Explain to me why giving people a choice of interfaces is a bad thing.

SSL gives them a hard-on.  Great.  I share their preferences, but I don't
share the inclination to force it on the rest of the world.  Taken to that
extreme would have us SSL'ify content distribution networks.  And is that
friendly to the network operators carrying that traffic?  Is that what we
really want to do?  Might as well, I guess, since even that traffic has
*some* intel value.  But I would argue that the cost incurred for very
little real benefit should be considered.

        --Arthur Corliss
          Live Free or Die

Reply via email to