Re: A proposal

On Nov 18, 2013, at 4:15 PM, Stephen Farrell wrote:
> On 11/18/2013 11:39 PM, Roy T. Fielding wrote:
>> I don't think "improves privacy" is a useful description.
>> You either have privacy or you don't.
> 
> Security is less complicated than privacy and is definitely
> not a binary property. Privacy is at this point far less
> well defined, so I find the last statement above quite hard
> to accept. (In fact, I find it unbelievable.) However, privacy
> is so ill-defined that its possible you're using some
> definition that does support such a binary distinction. FWIW,
> I'd be hugely surprised if there were a useful definition in
> which privacy was a binary property of systems.

I think you misunderstood what I said.  It isn't the system
that has privacy (or not) -- it is the user of the system.

If you want a deeper survey of privacy, look at

  http://tools.ietf.org/html/rfc6973

and its references.  Or spend two years arguing about what DNT: 1
is supposed to do.

I don't think security is less complicated than privacy.  It is just
a little easier to talk about because security folks generally refer
to something specific being secured.  As in, the dead-bolt secures
the door.  We don't say the dead-bolt secures the house, since there
are probably many other entrances to the houses, nor do we make
judgement calls on whether being inside the house is secure
(e.g., it's not when the house is on fire).  Privacy literature
often does both.

When people talk about "levels of security" they are generally
referring to strength (resistance to brute force attacks) or
comprehensiveness (does it cover everything you want secured).
But when the thing being secured is information, the result is
mostly binary for the user: either the information is secure
or somebody can see something that they shouldn't be able to see.
Actually, I guess we could say that revealing only metadata about
secured data is a sort of middle ground, but I digress ...

People here talk about securing http because they assume that
hiding the information exchanged is a useful act.  There are
certainly cases where that is true, and for which we should
recommend, or even insist on, the use of https (or some other
secure transport).  For all of those cases, a user agent needs
to verify that only the intended recipient can read the information,
before the information is sent, which is why we have the https scheme.

However, there are far more cases where encapsulating the entire
message exchange in encryption will do nothing of value.  The
only "private" information being exposed in HTTP is the same
information that is exposed by requesting DNS, making the connection,
and reacting to the results.  Opportunistic encryption in those
cases is both unwanted by the server and useless for the user.

Furthermore, I have a hard time believing the privacy propaganda
being spread by the browser makers.  If they want to improve
privacy, all they have to do is remove the crappy features
that cause their HTTP use to be insecure.  Stop blaming the
protocols for exposing information that shouldn't be sent in
the first place.

Don't allow cookies from a secure site to be sent to a non-secured site.
Double-key cookies so that they don't share information across multiple
referring sites. Implement an obvious logout in the UI chrome.
Don't send cached credentials if the referring document isn't trusted
or same-origin.  Don't allow BASIC over an unsecured connection.
Implement authentication schemes that don't expose the user's secret.
Prevent extensions and scripts from mimicking authentication forms.

Those are just the easy fixes. Sure, some of those changes
will fail to interop with some sites. Deal with it. That is a
tiny price to pay when compared to insisting that all http
traffic be encrypted.

....Roy

Received on Tuesday, 19 November 2013 08:44:08 UTC