W3C home > Mailing lists > Public > www-p3p-policy@w3.org > June 2007

Re: [RFC] Information headers in HTTP

From: Rigo Wenning <rigo@w3.org>
Date: Tue, 19 Jun 2007 23:16:12 +0200
To: Stefanos Harhalakis <v13@it.teithe.gr>
Cc: www-p3p-policy@w3.org
Message-Id: <200706192316.13503.rigo@w3.org>
Hi Harhalakis, 

there was a similar request to the KHTML development list and I take the 
response from Bert Bos from there: 

====================Answer from Bert Bos=============================
I think this is not a good idea, for more or less the same reasons
cookies, Referer and User-Agent headers are not good ideas, viz.:

   - The information is privacy sensitive. The server has no right to
     this information, unless the user explicitly wants to give it.

   - The identifier of a page is the URL. That's what you store in a
     bookmark, what you copy and paste, print on a billboard or send to
     friends. But, if the page depends on other headers than the URL,
     such bookmarks fail.

   - I travel a lot, use computers in other countries than where I am
     physically, and I don't want to know what time zones all those
     machines are configured for. I'd hate to get different content just
     because I use one device rather than another.

   - If a page's content can differ based on the user's time zone, the
     user should be able to choose what time zone he wants the
     information for. He may want it for a different time zone than 
     where he currently is, and he may want to try out different ones.

   - The header is redundant. Everything on the client-side that might
     influence the content of a page can be (and should be) in the URL 
     or in the authentication headers (in case the content is 

   - I don't know (and I'm not online to check), but if time zone
     information is currently not a category in P3P, it would need to be
     added there first.

   - There are generic techniques for client profiles that don't need a
     new header for every new piece of client-side information: see 
     CC/PP and UAProf. (I think content should *not* depend on
     client-side information other than the URL, but these techniques 
     exist, mostly because of underpowered mobile phones, so better to 
     re-use existing techniques than add new ones.)

   - All headers that you add to HTTP cause overhead. The time zone is
     rarely needed, but it takes up bandwidth all the time. (The same
     goes for anything else you might want to know about the client 
     name of user, OS, amount of RAM, free disk space, whether 
     there is a printer, name of the user's mother...)

Timezone is in the P3P Base dataschema for a good reason as it can be 
relevant for privacy. It is in the variable category as it is most 
privacy relevant together with other data transmitted. I think there 
are better ways to transmit or use timezone data, so having them in the 
http header doesn't look like the best idea. CC/PP or UAProf would be 
the preferred methods. Those can also be complemented with P3P to know 
what the data is used for etc...


Rigo Wenning
Privacy Activity Lead

On Saturday 16 June 2007, Stefanos Harhalakis wrote:
> Hello there,
>   I'm currently considering a proposal that extends HTTP by adding a
> set of headers that can be used by server side applications to
> request additional information from visiting clients. I'd like to
> know if you believe that this conflicts with P3P.
>   In general, server side applications will be able to request
> additional data from clients like: Timezone, Location, etc, only when
> those are needed and clients may choose to provide them.
>   I'm sending you the I-D document that is not submitted or discussed
> yet for more information.
>   Please CC me since I'm not subscribed to the list. Discussion of
> the document in http-wg list has not started yet since I'll wait for
> your comments first. Of course, all comments related to P3P or not
> are welcome!
> Harhalakis Stefanos

Received on Tuesday, 19 June 2007 21:16:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:42:56 UTC