- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Tue, 20 Dec 2011 15:43:48 -0800
- To: Matthias Schunter <mts@zurich.ibm.com>
- Cc: "public-tracking@w3.org" <public-tracking@w3.org>
On Dec 20, 2011, at 8:51 AM, Matthias Schunter wrote: > Hi Team, > > As indicated during our 2011-11-30 telco, I'd like to move this issue > from "Pending Review" to "Closed" during our 2011-12-21 telco. > > Regards, > matthias > > ISSUE > Do we need a response at all from server? > > PROPOSED Resolution FPWD: > - We currently discuss the format of the headers and under what > conditions they shall be sent. The fact that a header is needed in > some cases seems to be no longer disputed at this point. Umm, I just disputed it the last time we talked about the header. Is this issue specific to headers or any response at all? There has been no expressed *need* for a response from servers. By need, I mean some failure of the protocol to accomplish its objective, which is to convey the user's tracking preference to each server such that the server can comply with that preference. The server's obligations under our protocol do not change on the basis of how it responds to the user. There have been several *desires* associated with a response. IIRC, they include - user observing that their preference has been received; - user/regulator observing that server claims compliance; - user observing that the server claims it will either honor the preference or is tracking on the basis of a previously defined or acquired exception; - identifying which exception is being claimed by server; - potential UI decoration based on specific response to each embedded request element; - probing for claimed compliance before making a "real" request in order to reduce "real" tracking information sent to a site that might not comply; - regulator testing for compliance violations that is limited to sites that have claimed to comply. Have I missed any? Each of those are *desires* because the protocol will work without them, particularly when backed by effective regulations. That doesn't mean we shouldn't try to satisfy as many desires as possible. It does mean that the cost of satisfying them must be justified by the benefits obtained specifically from those responses (and not from implementation of DNT in general). To emphasize: Requiring a response header be added for every single DNT-enabled request on the Internet is an EXTREMELY high cost even if the servers are very careful to avoid breaking caching (e.g., by including the same response to all requests with or without DNT enabled). That cost will be entirely borne by the service providers, so they are the ones that will have to buy-into supporting it within this standard. If that cost is not sufficiently justified by this WG, then I will not implement it and I will request that Adobe formally object to it being part of the standard if the WG insists on specifying it. Reducing the scope of the header field to only those responses on resources that perform third-party tracking functionality would at least reduce the buy-in to those companies likely to be aware of this effort, but that would add the side-effect of highlighting which resources are trying to do tracking for the purpose of fraud-control, auditing, etc. I'd rather not go there. There are other ways to accomplish the above desires that reduce the cost on service providers in exchange for a small additional cost for users that are actively monitoring compliance. Since the proportion of users actively monitoring compliance is an extremely small number when compared to the total number of users on the Internet, let alone the number of potential responses for all users that ever choose to enable DNT, we should select a solution that places the costs closer to those who benefit. Cheers, Roy T. Fielding <http://roy.gbiv.com/> Principal Scientist, Adobe Systems <http://adobe.com/enterprise>
Received on Tuesday, 20 December 2011 23:44:17 UTC