Re: Request to close ISSUE-81

On Dec 20, 2011, at 15:43 , Roy T. Fielding wrote:

> 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?

- detecting when an intermediary node has taken advantage of the 'may' alter outbound requests (but 'must not' alter responses)

> Each of those are *desires* because the protocol will work without
> them, particularly when backed by effective regulations.  

I don't know what you mean by 'work'.  As a user, I send off a request to unknown 3rd parties and I get an unknown effect.  Is that 'work'?  The user doesn't choose the 3rd parties involved, doesn't know if they have even got around to implementing DNT, doesn't know whether they can or do claim an exception.  Did I miss any other points?

> 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

In terms of bandwidth, it's no higher than the cost of the request, in bandwidth, and proportionately to the size of the transaction, responses tend to be larger than requests anyway.  In terms of computation, if a site does no tracking, or always observes DNT with no exceptions, the responses are trivial (can be configured into the web server's config file, typically), and otherwise, the complexity of responding is reasonably proportional to the complexity of the tracking, I think.

> 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.

Ah, so the cost you are concerned about is the per-transaction nature of the response, and hence the impact on caching?

> 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.

One that comes to mind is an explicit indication in the request header that a response is desired; and the UA should only set that once for a 'single interaction' with the 3rd party site.  Tricky to define 'single interaction', but...

Another is to say that it's the server's job to make sure it sends a response 'sufficiently frequently' to be sure that the user is aware of their DNT status accurately at all times (i.e. that the user can correctly infer their status either by copying from a previous response, or from an explicit response).

Other ideas?

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Wednesday, 21 December 2011 00:21:27 UTC