Re: Privacy and HTTP intermediaries

Hi Martin,

On Tue, May 03, 2011 at 10:16:15AM +0800, Thomson, Martin wrote:
> On 2011-05-03 at 11:47:45, Mark Nottingham wrote:
> > On 03/05/2011, at 11:10 AM, Thomson, Martin wrote:
> > 
> > > Does the value of the Cache-Control header have any bearing on whether 
> > > something is logged?
> > 
> > Nope.
> > 
> > I suppose you could read Cache-Control: no-store has having those 
> > semantics, but it doesn't in any implementation I'm aware of. Perhaps 
> > we need to clarify that.
> 
> With my privacy nut hat on, it would be nice if that could be added.  It's certainly consistent with the definition of no-store.
> 
> I'm not expecting the guidance to have any teeth, nor for it to have any impact on implementations, but there's a definite advantage to having text to that effect.
> 
> There is the question about non-caching intermediaries that might otherwise perform logging.  They aren't always going to look at Cache-Control unless they need to (for no-transform), so a caveat along the lines of "this is NOT a reliable or sufficient mechanism" might need to be added for this.
> 
> That leaves me with (for p6, S3.2.1 & S3.2.2):
> 
>   An intermediary that performs logging (whether or not it implements a cache) MUST NOT perform logging for requests or responses with a no-store directive.

Many intermediaries will still log regardless of whatever new directive
you add, and there are a lot of places where logging will be mandatory
regardless of the cache-control header (which should control caching and
not logging).

Also, concerning the privacy, I see no reason for not logging something
that is exchanged in clear text. This has always been the case for decades
with the query string in GET requests etc... ; if you want some privacy,
you know you need SSL.

There are some places where logging is performed by capturing all network
traffic, and other places where network traffic is captured in order to
make post-mortem analysis of network incidents. The presence of whatever
header, or the use of a CONNECT will not change anything there, the captures
will still contain all the exchanges. Once again the only solution there is
to encrypt the traffic.

I think it'd be more efficient to remind the reader about that in the spec,
so that implementers leave the choice to their users (accessibility vs
privacy). Right now when I connect to Yahoo mail in clear text from some
customer's, I know I'm taking a risk on my privacy but I have my access.
With WS it should be the same. When you connect to some services in clear
text, you accept a risk.

What we should discourage is a transparent and automatic fallback from
SSL to clear text, because the user might think his privacy is respected
while it's not.

Regards,
Willy

Received on Tuesday, 3 May 2011 05:19:12 UTC