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

RE: action-317, discussion of the service-provider flag and the same-party resource & issue-112

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>
Message-ID: <002001cdce4e$8b980860$a2c81920$@baycloud.com>
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

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:38 UTC