- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Wed, 27 Mar 2013 00:22:52 -0700
- To: Chris Pedigo <CPedigo@online-publishers.org>
- Cc: Tracking Protection Working Group <public-tracking@w3.org>, Peter Swire <peter@peterswire.net>
- Message-Id: <C028CA08-9F9B-446F-893A-5E4B7318C477@gbiv.com>
I have been trying to get back to this discussion since I was unavailable the week it came up ... but to no avail so far. We should stop using the term service provider because it is so obviously confusing and use either "data controller" or "contractor" instead. The addition of business associate here doesn't help -- it just makes it worse because the way this is defined is opposite to how it is defined within HIPAA (IIRC, the business associate is the service provider in HIPAA, not the customer of the service provider). The last normative paragraph ("may merge and use data") is backwards. A service provider almost always collects data on behalf of all of its customers via a single stream. Once received, the incoming data stream is processed per HTTP request: first to conform to applicable regional requirements and then to the specific requirements of the request target (which identifies the party). Finally, any results or retained data from that processing is siloed per party (customer of the SP). Prior to that separation process, there might be raw logfiles, short-term debugging traces, and aggregate statistical counters based on the combined incoming stream, as is true of any Internet service run at this scale, for the sole purpose of keeping the service alive and estimating capacity. Aside from active debugging or keeping a confidential record of actual security/systemic failure incidents, I would expect SPs to delete or de-identify such data before it could be retained long-term (more than a few days) or shared with anyone outside the operations team, and only when that is permitted by the respective data controllers. I don't see DNT:1 changing the above, since it is not subject to the user's preferences. Moreover, I think it should be assumed that an SP can do anything permitted of the party for which it is contracting so long as the resulting data is controlled by that party. Naturally, the incoming data stream is never seen by the SP's customers -- each party only has restricted access to its own data after the separation process, and usually has some sort of dashboard-level visibility into the aggregate statistical counts. With regards to text changes, I think the existing text in the compliance section 3.4: Outsourced service providers are considered to be the same party as their clients if the outsourced service providers only act as data processors on behalf of that party in relation to that party, silo the data so that it cannot be accessed by other parties, and have no control over the use or sharing of that data except as directed by that party. is better than the proposed changes but still needs some tweaks once we agree on what terms to use for both the SP and the customer of SP. The current use of "clients" here to mean customers is ambiguous with HTTP's clients, I am not sure what "on behalf of that party in relation to that party" means (perhaps a paste-o?), and "silo the data so that it cannot be accessed by other parties" is overly restrictive. For example, the data is siloed per customer (data controller), but access is controlled by the data controller; thus, a customer might provide that access to some other parties, such as other contractors that have been paid to analyze the collected data. Unfortunately, I will have to take an action on that (due next week) if I need to propose exact text for the draft. ....Roy On Mar 6, 2013, at 8:13 AM, Chris Pedigo wrote: > Based on comments from last week’s call, I’ve edited the proposed definition for Service Provider/Data Processor and added the beginnings of some non-normative text. Edits and additions are in italics. > > Action 368 – Definition of Service Provider/Data Processor > > Normative > > A Data Processor is any party, in a specific network interaction, that both operates on behalf of the entity for which it is working (business associate) and meets the following conditions: > - Data that is collected and/or retained is separated by both technical means and organizational process, AND > - Uses and shares data only as directed by the business associate, AND > - Enters into a contract with a business associate that outlines and mandates these requirements. > > A Data Processor is subject to the same restrictions as the business associate. If a Data Processor were to violate any of these conditions, it will then be a third party. Data processors may merge and use data for the purposes of security or fraud prevention. > > Non-Normative > > Data processors may use data collected for the proper management and administration of the business associate. Similar allowances are made for data processors under European Union law, the U.S Health Insurance Portability and Accountability Act (HIPAA) and the U.S. Gramm-Leach-Bliley Act. > > > From: Chris Pedigo [mailto:CPedigo@online-publishers.org] > Sent: Wednesday, February 27, 2013 10:36 AM > To: Tracking Protection Working Group > Cc: Peter Swire > Subject: Action 368 - Definition of Service Provider/Data Processor > > Hello all, I worked with Vinay Goel to come up with a definition of Service Provider/Data Processor. We also solicited feedback from Justin Brookman and Rigo Wenning. Below is the normative text that we ultimately decided upon. One of the discussions centered around whether service providers or data processors should be allowed to utilize the Permitted Uses. We decided not to include that language, because it would not fly in the EU and because it does not appear to be common practice among service providers in the US. Finally, I am still gathering feedback from my member companies. So, while expect this language will work for publishers, I am reserving the right to come back with tweaks. Looking forward to today’s call and the ensuing discussion. > > Action 368 – Definition of Service Provider/Data Processor > > A Data Processor is any party, in a specific network interaction, that both operates on behalf of another party and meets the following conditions: > - Data that is collected and/or retained is separated by both technical means and organizational process, AND > - Uses and shares data only as directed by that other party, AND > - Enters into a contract with the other party that outlines and mandates these requirements. > > A Data Processor is subject to the same restrictions as the other party. If a Data Processor were to violate any of these conditions, it will then be a third party. > > > Chris Pedigo > VP, Government Affairs > Online Publishers Association > (202) 744-2967
Received on Wednesday, 27 March 2013 07:23:48 UTC