- From: Bryan Sullivan <blsaws@gmail.com>
- Date: Wed, 25 Jan 2012 23:43:24 -0800
- To: "public-tracking@w3.org" <public-tracking@w3.org>
- Message-ID: <CB46441C.103B5%blsaws@gmail.com>
I believe we need to consider other alternatives to the HTTP header-based approach to TPE, for the reasons noted in the F2F yesterday, and more. - Adding new HTTP layer elements (especially complex ones as currently proposed for the DNT header) with their own request/response semantics, will substantially impact both browsers and servers, and delay introduction of DNT across the spectrum of HTTP-based applications (including but not limited to browser-based Web applications). - Request/response headers that flow with every request may seem a minor overhead, but every bit that unnecessarily flows over the wire or air costs, and over time the cumulative effect is significant. For example, for Chrome in a recently launched device this would, even in it's minimal form (DNT:1), add 1% to the size of every HTTP request. The relative size for responses would be less, but given that mobile Web sites are smaller and gzipped typically (which btw is another header sent with every request, mostly unnecessarily today), the increase is still significant. - Implementation of DNT in mainline browsers (whether open source or not) will not help the broad spectrum of HTTP-based applications and Web user agents, which will also have to implement the same semantics and UI/UX aspects. We need to care for this much "wider Web", and ensure that these users are not left behind. This will especially be a problem for users of existing embedded browser devices (e.g. mobile, TV, CE) which are not upgradable (or typically not upgraded once shipped, except for key bug fixes). The same goes for any other HTTP/Web-based application, e.g. implemented through WebView APIs or embedding layout engine code. When these myriad UA/app vendors have to implement complex new features in their products, the impact is multiplied, e.g. affecting development of other new features (development resources are limited and have to be allocated), and increasing compliance testing / device certification costs. To address these concerns I believe we need to consider taking TPE up a layer in the stack, and if possible enabling this without impacting browsers at all. I believe this is possible using a RESTful DNT API approach in which each user's DNT status on domains is set by request, and the status of site compliance can be delivered in response as a document that is processed directly by the application. This response document can also serve to disclose many other things of interest to the app and user, e.g. a list of the 1st party domains and 3rd party domains related to the site. The document can then be cacheable on the device, or locally stored by the application. This can dramatically reduce the amount of network traffic necessary for DNT preferences management. If anyone is interested in working with me on this idea, please let me know. I will start with data flows and work toward developing a prototype demonstration of the idea. At the least this may be a way to supplement header/browser based approaches to DNT, with application-layer approaches. Bryan Sullivan | AT&T
Received on Thursday, 26 January 2012 07:44:05 UTC