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

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