DntResponseHeaderOrURI

From W3C Wiki
Revision as of 13:39, 5 March 2012 by Mschunte (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Scale used:

  • -- = Not supported
  • - = Barely supported
  • + = Supported with limitations
  • ++ = Unlimited summort

Comparison:

  • V01: At this point, the table summarizes mschunter's personal opinion (2012-02-24)
Criteria Response Header Well-known URI Notes
Transmits tracking status for retrieved object at URL ++ +(may need dynamic generation) MSchunter believes that sending individualised (per user) status is easier with headers since they can be locally generated and attached. This seems easier than dynamically generating a centralised resource at a well-known URI.
Enables enforcement by regulators ++ + Headers are slightly less ambiguous due to their narrow scope
Granularity ++ (per request; very fine-grained) + (per sub-site; coarser-grained) To support DNT for each URL, the site needs to be replicated under the well-known URL.
Simplicity of user agent ++ (info along with page) 0 (separate lookup)
Traffic generated ++ (info along with page) 0 (separate lookup) It seems as -worst case-, the URI proposal may generate 2x the number of requests?
Robustness wrt caching - ++ Some cache implementations do not properly handle headers while all caches can cache a well-known URL.
Tracking protection on info resource + - URI can be declared 'no tracking area' and retrieved before actual request. For headers, tracking may have happened while returning a header?
Maintainability of site + - URI requires all site stakeholders to agree and populate the well-known URI (difficult); header allows resource-owner to just attach a header
Ability to transmit complex data - + Status object can transmit larger data sets (partner-sites, options, ...) while this would overload header.
[More criteria needed...]


Comments / Questions for Response Headers:

Comments / Questions for Well-known URIs:

  • Is there a way to prevent that each URL needs to always be checked at the well-known location? E.g., retrieving foo.com/bar/one requires checking foo.com/.well-known/dnt/bar/one. If I now want to retrieve foo.com or foo.com/bar/one/sub, I need to re-check. Don't I? Wouldnt this double the web traffic (sort-of?)