Re: Privacy and HTTP intermediaries

Right. 

I don't see an issue here, unless someone wants to argue that we need to explicitly add logging to this text:

      This directive is NOT a reliable or sufficient mechanism for
      ensuring privacy.  In particular, malicious or compromised caches
      might not recognize or obey this directive, and communications
      networks might be vulnerable to eavesdropping.

Cheers,


On 04/05/2011, at 8:44 AM, Ben Niven-Jenkins wrote:

> 
> On 3 May 2011, at 03:16, 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.
> 
> If what could be added? A clarification that no-store suddenly has an associated semantic that no implementation associates with it currently?
> 
>> 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.
>> 
> 
> If you do not expect "the guidance to have any teeth, nor for it to have any impact on implementations", what exactly are you hoping to achieve?
> 
>> 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.
>> 
> 
> Apart from the fact that I'm not aware of an implementation that associates such a semantic with no-store, given the reasons that logging is often enabled (e.g. debugging, reporting, billing, etc.) I simply don't see that it is likely that implementations will adhere to the stated requirement to not log requests/responses containing no-store and therefore having a specification mandate something that few if any implementations will adhere to seems entirely pointless to me. It has nothing to do with inter-operation and at best will give some subset of folks the impression that using no-store will provide some additional level of privacy that in practice will be non-existent.
> 
> Ben
> 

--
Mark Nottingham   http://www.mnot.net/

Received on Tuesday, 3 May 2011 23:58:41 UTC