W3C home > Mailing lists > Public > public-tracking@w3.org > August 2012

Re: Service Provider Status (ISSUE-137)

From: Roy T. Fielding <fielding@gbiv.com>
Date: Thu, 30 Aug 2012 22:39:34 -0700
Cc: W3C DNT Working Group Mailing List <public-tracking@w3.org>
Message-Id: <1DDF893D-AFC8-4BA1-BB7B-5D3DFF9A2DE5@gbiv.com>
To: Jonathan Mayer <jmayer@stanford.edu>
On Aug 30, 2012, at 6:00 PM, Jonathan Mayer wrote:

> Roy,
> 
> A number of participants have articulated use cases for a service provider flag.  There was extensive discussion of the topic on the final day in Bellevue.  Proposed use cases have largely focused on transparency for users, researchers, and policymakers, much like the use cases for a third-party flag.  I'm not aware of any mainstream user agent that intends to "discriminate against service providers" that honor Do Not Track.

Then none of those cases require a machine-readable indication of
service providers as part of the tracking status.

Ed's case, of distinguishing between a service provider collecting
on one of its own sites and a service provider collecting on behalf
of some other first party, is primarily a concern about being
able to identify which first party is being served (and hence the
scope of data sharing allowed by the user).  I solved that case
in TPE already, using a mechanism without any known objections,
because it did seem to be a reasonable transparency issue.
Another way to solve that would be to require a first-party
link in every tracking status representation, though most of the
time that link would be redundant to either the policy or the
domain being used.

> I very much appreciate your candor about Adobe's interests.  I understand why a prolific service provider might not want to identify itself, and I'm aware that Adobe often uses domain aliases (e.g. metrics.apple.com) in part for those reasons.

Generally speaking, we use aliases because the customer requires it,
which could be for any number of reasons: pride, same-origin policy,
UA-side siloing concerns, vendor substitutability, cookie scope, etc.
The choice often depends on what software was used to design the
first party site.

> I think the next step should be text proposals and a straw poll.  If we have consensus either way, great.  If not, on to the written objection process.
> 
> Best,
> Jonathan

Cheers,

....Roy


Received on Friday, 31 August 2012 05:39:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:38:54 UTC