- From: Mike O'Neill <michael.oneill@baycloud.com>
- Date: Thu, 29 Nov 2012 16:28:18 -0000
- To: "'David Singer'" <singer@apple.com>
- Cc: <public-tracking@w3.org>, "Nicholas Doty" <npdoty@w3.org>
David, I agree that there needs to be something in the protocol so that service providers can declare themselves or be declared. Because they are acting as a data processor for the 1st party (i.e. have a contractual agreement with them), and so in some jurisdictions can be free to use UUIDs, I think they should be declared as such by the first party. The best place to do this is the tracking resource because it does not rely on retaining logs. I do not get the point about non-disclosure, because the third-party elements are plainly embedded. If the resource responds with a Tk1, when they are accessed in a third-party context, they are declaring themselves as either bona fide service providers or not complying properly with the TPE. If they are a service provider they should be declared as such in the tracking resource. Maybe we should change the name if the member used for this in the tracking resource to 'service-provider'. This would make the usage clear and also frees up the 'same-party' member which can then be simply used for UGE mechanism Nick summarised for action-334 making a UGE API call apply to multiple domains i.e. these domains are all controlled by the same party and the same privacy policy applies to all of them. Mike -----Original Message----- From: David Singer [mailto:singer@apple.com] Sent: 29 November 2012 00:07 To: public-tracking@w3.org WG Subject: action-317, discussion of the service-provider flag and the same-party resource This discussion started in <http://www.w3.org/mid/43B85F59-7BD8-43D7-80B3-20F8FF1DEB1A@apple.com>. This is the reference I was searching for on the call today. I want to remind people we're not talking about 'all' kinds of service provision here. We're specifically not talking about ISPs, hosting, content authoring, or anything EXCEPT services which are distinct end-points of HTTP transactions. The basic problem we're trying to avoid is having a sensitive user and/or user-agent flag a site as suspiciously claiming rights it doesn't seem to have -- either first-party status when it's not the first party, or consent when it doesn't appear to have 3rd-party-with-consent status. Let's take a simple hypothetical example. VisitCounter.com offers a 'basic' and a 'pro' service. They provide 3 levels of service; free, basic, and pro. Free service gives you an widget iFrame you can embed, that visibly counts visitors. Contract for basic, and they will provide you a report on your visitors -- silo'd, and so on -- but the domain is still theirs. Pro, and they'll register under visits.<yourdomain>, and also provide cookie analysis, and so on. For the basic service, they look like a different site, different party. And they appear under that name on multiple sites, say examplebank.com and examplenews.com. examplenews.com and examplebank.com could add them into their same-party array, but if they add both examplebank and examplenews into their same-party array, that appears to be a claim that those two are 'the same party', which is not true. If they don't add them, we have no indication or back-pointer. Even if they add dynamically, somehow detecting where they are embedded, the risk remains, I think, that someone will join these later. Adding the 'I am a service provider' flag to their response, however, can help make it clear that they stand in a *service provider* relationship with some or all of the sites in the same-party array. Big sites can afford to pay for 'pro', so the argument that the flag discriminates in favor of the large doesn't hold. What am I missing? David Singer Multimedia and Software Standards, Apple Inc.
Received on Thursday, 29 November 2012 16:29:28 UTC