- From: Mike O'Neill <michael.oneill@baycloud.com>
- Date: Sat, 16 Mar 2013 10:25:23 -0000
- To: "'David Singer'" <singer@apple.com>, <public-tracking@w3.org>
David, Yes, this is a neater way to do it albeit with potentially an extra transaction, but as you say it is cacheable. I would just add that the status-id could be appended to the TK: 3 qualifier in the case of a joint controller. For the your quoted example it is common that a UID, usually recorded in a persistent first-party cookie, is encoded as a query parameter to the image src Url. If exampleanalytics.com is acting as a true data processor (service provider), does not use the data for its own purposes and has a contract with the data controller in place, it would reply with TK 1; example_dot_com. Otherwise it would respond with TK 3; example_dot_com identifying itself and example.com as joint-controllers for the data collected. For cases where the third-party is acting as the sole data controller for the collected data (perhaps using a UID encoded in a cookie in its own domain), it would just reply with Tk: 3 as before. It could also reply in this way (no status-id) if it has contracts in place whereby the first-party is prohibited from using the UID stored in the first-party domain cookie. I might be a good idea to allow the status-id to be directly parsed so, as you show in your example, example_dot_com would refer to example.com without needing a separate resource at /.well-known/dnt/example_dot_com. We could trigger this by limiting the _dot_ string in the ABNF to status-ids encoding domain names (of data controllers). It is maybe not as elegant but it could be simpler for third-parties to implement. Also, I support the idea that the WKR member should actually be named "data-controller", there is no point in re-inventing the wheel, and the EU definition has the advantage of being already intensively honed. Mike -----Original Message----- From: David Singer [mailto:singer@apple.com] Sent: 15 March 2013 23:29 To: public-tracking@w3.org WG Subject: 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 Saturday, 16 March 2013 10:26:02 UTC