ACTION-357: Add service provider option text (with jmayer) as an issue in the draft with an option box

Hi

I am reading the current draft, and I think the combination of some recent features achieve the same, or maybe even better, result than the once-proposed 's' (service provider) flag.

* first-party member of the well-known-resource:  can identify the 'first party' (actually data controller)

* request-specific tracking status resource: for providers who provide to different parties, the response header with this field (which is cacheable) can direct the client to the right WKR and hence correct first-party (actually data controller) for this resource.

I think this makes it possible for service providers to provide transparency if they wish.


The previous proposal was to have an 's' status or qualifier, and then to require that the WKR have a pointer to the controller.  Perhaps we don't need the 's', as long as the WKR makes the relationship clear?



When we discussed 6.6, which talks about delegating a consented 3rd-party tracking (e.g. a service provider to an ad server who had received consent), Roy indicated a willingness to change the WKR 'first-party' to 'data-controller' (or similar term, perhaps avoiding this one which is a defined term in the EU) which would make it applicable to this case (if we define what we mean by 'data-controller' or the term we use).


So, working through some cases, and assuming that in all cases the parties concerned are able to, and desire to, provide maximum transparency.  (If they don't, there may be [unstated] assumed consequences.)

1.  exampleanalytics.com provides two levels of analytics service.  Level (a) uses their regular host-name, (and hence cookies of the party to whom they provide service are not seen).  They say "load http://exampleanalytics.com/1x1.gif on your site, and sign the contract, and we'll provide basic analytics".  Example.com signs up.  When someone visits example.com, they load that gif, and using the referer header, exampleanalytics accumulates statistics solely for example.com.  Exampleanalytics sets
* a response header Tk: 1;example_dot_com
* in the request-specific tracking status at /.well-known/dnt/example_dot_com, they set the status "1" (first party), and first-party is set to http://example.com/policies/privacy.html.

2. In their higher level of service, they register the name analytics.example.com, and provide service at that address.  Now there is a presumption that the fetches are under example.com, but to give more transparency, they don't need the response header at all, and can simple set the WKR at analytics.example.com to have a 'policy' link that refers to the policy above.

3. largeexample.com is a major provider of content and they contract with examplecdn.com.  examplecdn.com captures a lot (maybe all) of the data that would have been captured by example.com had the requests come back to it.  Obviously something in the URL of each request tells the CDN what the original resource is, and who supplies it, and it's them that they report back to.  The URL used by the CDN is often obfuscated to make it hard to guess the origin URL (for various reasons, some people try to work around CDNs).  Since the CDN *is* tracking, they need to say "1" as their tracking status, and they would use the same techniques as [1] above if they want the transparency.

4.  <what other case(s) need exploration?>



So, proposed changes, including two minor changes:

A] 5.2, definition of '1' tracking status value, says


1	First party: The designated resource is designed for use within a first-party context and conforms to the requirements on a first party. If the designated resource is operated by an outsourced service provider, the service provider claims that it conforms to the requirements on a third party acting as a first party.

perhaps it would be better if the last few words said "acting FOR a first party"?




B] In 5.5.3 we find

An origin server may send a member named first-party that has an array value containing a list of URI references that indirectly identify the first party (or set of parties) that claims to be the responsible data controller for personal data collected via the designated resource. An origin server that does not send first-party is implying that its domain owner is the sole first party and that information about its policies ought to be found on this site's root page, or by way of a clearly indicated link from that page (i.e., no first-party member is equivalent to:"first-party":["/"]).



I suspect we need a (s) after data controller, here "that indirectly identify the first party (or set of parties) that claims to be the responsible data controller(s) for personal data"



C] And the change from above, changing the WKR first-party member to data-controller, or a similar term which allow its use for providing service to a 3rd party (who in turn may have consent).



David Singer
Multimedia and Software Standards, Apple Inc.

Received on Friday, 15 March 2013 23:29:31 UTC