Re: Request to close ISSUE-81

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