- From: Matthias Schunter (Intel Corporation) <mts-std@schunter.org>
- Date: Mon, 23 Jan 2017 19:15:41 +0100
- To: "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
Hi TPWG, today, we discussed how to resolve ISSUE10 and 15. I discussed our pros and cons below. My proposed resolution is: (A) We only allow TSR at the well-known resources to ensure discovery in one location and also before visiting a URL. It also ensures that a page owner cannot "pretend" to do DNT without support of the server admins. The server admins can allow users to post their TSR under given IDs. (B) We allow http-equiv to be used to deliver the header. This simplifies deployment and allows a page owner to add an ID that identifies the policy that it used. Below is my detailed arguments. Any feedback/opinion/pojnts I missed? Regards, matthias ------------------- SCENARIO The scenario is that you use a subdomain / some pages / .. on a server that you do not fully control. E.g. a hosting provider, wordpress, tumblr, ... You want to support DNT on your pageswithout requiring the server admins to actively help. MIKE PROPOSAL - Header: Page owner is allowed to deliver DNT header via http-equiv - Tracking Status: Instead of using a well-known resource, http-equiv could also point to a URL that points to the tracking status resource. DISCUSSION - PRO + Allows page/subdomain owners to support DNT without explicit support of server admins - CONTRA - Without any server support, a page owner cannot know whether the server tech stack indeed implements the desired policies (e.g. logging/cookies/retention could still continue) - Discoverability is limited since each page could publish its own policy - If a Tracking Status Resourfce is published at the well-known URL, this may be superseded /conflicted with a page-policy DISCUSSION 1: TSR / we-known URI * Without any server support, pretending to support DNT is not soundly possible => Consequence: We have to assume that the server helps * If the server helps, the server admins could allow posting TSRs under different IDs under the well-known URI * Then the header can point to one of those IDs. DISCUSSION 2: Support for headers * If a user has only HTML access, then it is hard to send headers. * In this scenario, a http-equiv would simplify delivery of the DNT signals PROPOSED RESOLUTION - We continue to require TSR to be posted under an ID at the well-known resource - Better discovery - Ensures that the server admins cooperate - We allow http-equiv delivery of the header for a particular page - Simplifies deployment - Allows pages to set their ID - Proposed conflict resolution: Header overrides http-equiv since the header is more likely to come from the server owners.
Received on Monday, 23 January 2017 18:17:00 UTC