Re: Service Provider Status (ISSUE-137)

Lauren,

We do not yet have agreement on the sort of siloing that a service provider would have to do.  We achieved some preliminary agreement on outsourcing in Santa Clara: http://lists.w3.org/Archives/Public/public-tracking/2011Nov/0015.html.  I believe we've since also agreed that service providers act at the direction of another party.  See ISSUE-49 and ISSUE-73 for discussion.

Jonathan


On Thursday, August 30, 2012 at 4:56 PM, Lauren Gelman wrote:

> 
> 
> If a ServiceProviderA provides service to www.A.com (http://www.A.com), www.B.com (http://www.B.com), www.C.com (http://www.C.com), can someone explain what restrictions would be placed on them by the proposal?   Can they use the same cookie to identify visitors to all three websites as long as ServiceProviderA contractually promises to not share info collected from www.B.com (http://www.B.com) with CompanyC?  And then the burden of the disclosure of the relationship is placed on CompanyB and CompanyC?  Or does the spec require a technical siloing of the data or particular cookie structure?
> 
> (I assume here that First PartyA will include ServiceProviderA and CompanyA and www.A.com (http://www.A.com) as long as they are all owned by VeryLargeCorporationA so they can all share data without any restriction imposed by this spec-- which seems to be creating the problem Roy describes with competition among large and small corporations if I am understanding this)
> Lauren Gelman
> BlurryEdge Strategies
> 415-627-8512
> 
> On Aug 30, 2012, at 4:19 PM, Roy T. Fielding wrote:
> > On Aug 30, 2012, at 1:39 PM, Rob van Eijk wrote:
> > 
> > > We are dealing with entities processing data on behalf of multiple first parties for a myriad of purposes.
> > 
> > No, we are dealing with one or more entities processing data for
> > one first party, for the purpose given by that first party,
> > with only a single data controller being responsible.  Otherwise,
> > the service provider case would not be applicable.
> > 
> > > Since Issue 137 is a TPE issue, why not use the technical argument of machine-readable identification of service providers at the moment they are processing data on behalf of the first party? If the argument is that a legal policy is close by, you avoid a technical solution. Isn't the task at hand in the TPE to contribute to transparancy on a HTTP transaction level?
> > 
> > We already have contributed to transparency by identifying the
> > first party (data controller) and agreeing to adhere to the
> > constraints that prevent a service provider from being a joint
> > controller.  Those are real privacy concerns, so we addressed
> > them in the spec.
> > 
> > What is requested in ISSUE-137 is that we wear a scarlet letter S
> > while performing services on behalf of our customers, while
> > collecting the same data, processing it for the same purpose,
> > and with the same level of confidentiality as the large
> > conglomerates that do not rely on service providers.
> > 
> > If UAs use that information to discriminate against service
> > providers, then it would provide a market advantage to large
> > companies that own their own analytics services (including for
> > Adobe's own web properties).  We simply refuse to allow that
> > opportunity to occur, and will not tolerate it as a requirement.
> > 
> > There is no privacy concern that justifies such a requirement.
> > Without that justification, Adobe will not implement it regardless
> > of the opinions of the rest of the WG.  If the WG insists that it
> > be part of the Recommendation, then Adobe will file a formal
> > objection, I will exit the group, and not a single implementation
> > that I am responsible for will ever implement that Rec.
> > 
> > If the WG can make a formal decision that overrides my objection,
> > then so be it.  Otherwise, the chairs should close the issue and
> > move on.
> > 
> > ....Roy
>