Re: Privacy concerns with entity tags

I think that in general HTTP offers very little in terms of "privacy",
in the sense that the IP-address of the requesting host is available
to the remote service, as is the signature of the user-agent and
request headers, or even traffic analysis ("when does the user usually
connect?"). The kind of user tracking that you're suggesting could
even be enhanced today in HTTP/1.0 by fiddling with the low order bits
of the Last-Modified date. 

Given that almost all browsers have separate IP connectivity, it is
actually the IP address of the requestor that is the most significant
"privacy vulnerability"; the only defense is the aggregation of
multiple users behind proxies where the proxy does not forward the
identity of the requestor. 

I agree that entity tags combined with "Cache-control: private" seems
like it might offer some additional traces of unique identity,
although I would imagine many browsers would systematically delete all
"cache-control: private" entries systematically (perhaps as a
configuration option) because of the difficulty of ensuring privacy
when there are shared workstations. As you say, "unless his local
cache has faded in the meantime".

I could imagine lengthening our already lengthy "Security
Considerations" section to point out this privacy concerns. However,
the alternative you offer (MD5-digest as entity tag) was considered
but not taken seriously because of the difficulty of constructing them
and validating them for entities that are constructed on the fly.

First, we imagined that most commonly servers that return results from
a file system would continue to use time stamps as the cache
validator, and that the entity tag would be (constructed from) the
last modified time. Second, services that composed a result from
multiple files in a file system might construct the entity tag from
the dates of the component parts. In both of those cases, it isn't
necessary for the server to maintain any additional state of the
constructed entity in order to validate a request and return
"Not-Modified".

I don't believe you have misunderstood the spec, or that these items
were changed between draft #3 and draft #5; I also think that the
concern over privacy is important. However, I don't think this aspect
of HTTP/1.1 creates sufficient additional privacy exposure over the
existing and widely deployed HTTP/1.0 to warrant any changes of the
specification.

Regards,

Larry

Received on Thursday, 13 June 1996 09:25:44 UTC