ACTION-218, ISSUE-112 -- exceptions based on Origin

In Bellevue, I volunteered to write up a proposal for user-granted exceptions based on Origin. I believe this rather closely models the user-agent-managed site-specific exceptions proposal as of February (where we referred to "fully-qualified domains"), but I've tried to elaborate further here.

Per RFC 6454 (http://tools.ietf.org/html/rfc6454), the concept of an "origin" is commonly used for the scope of privilege by user agents. In keeping with that concept, exceptions to a Do Not Track preference are requested based on a particular origin (that is, a tuple of fully-qualified host, scheme and port). Requests from one sub-domain do not imply requesting permission for all other sub-domains because, for example, a sub-domain might have an entirely different owner (x.wordpress.com and y.wordpress.com) or provide a very different context (health.example.com and news.example.com); see also RFC 6454, Section 3.2. Relying on a stable, well-known concept makes the specification and implementation here straightforward.

The implications: For a Web-wide exception, the caller is requesting that DNT:0 be sent for future requests on all top-level origins to the calling script's origin. For a site-wide exception, the caller is requesting that DNT:0 be sent for future requests to all "target" (or "tracker") origins where the calling script's origin is the top-level origin. For site-specific exceptions, the caller is requesting that DNT:0 be sent for future requests where the calling script's origin is the top-level origin and the target origin is in the specified list of origins. User agents might reasonably extend permissions (or provide a different, perhaps similar UI) for permission requests that are just sibling or sub domains of an origin for which the user has granted permissions, but that would be left up to the UA.

Optionally, we could allow calling scripts to explicitly specify a glob-style syntax; for example, requesting an exception for "*.tracker.com". (To do this for sibling domains of the calling origin would be more difficult, we would need to specify an additional parameter to allow a site to ask for "*.example.com".) We might also say that requesting for "tracker.com" implies all schemes and ports (rather than requesting "http://tracker.com" and "https://tracker.com" separately) to make it more convenient for calling JavaScript.

Notes for the editor:
To implement this change, we would want to clarify all instances of "top-level domain" and "target domain" in the User-Granted Exceptions chapter to instead refer to "top-level origin" and "target origin" (or "tracker origin"), add a citation to RFC 6454 and explain that exceptions are requested on this basis in keeping with the concept of an "origin" given that a different origin may provide a different context.

Thanks,
Nick

Received on Wednesday, 18 July 2012 05:58:35 UTC