W3C home > Mailing lists > Public > public-tracking@w3.org > January 2012

RESTful DNT API approach to TPE

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:38:30 UTC