- From: Nicholas Doty <npdoty@w3.org>
- Date: Wed, 26 Jun 2013 16:19:59 -0700
- To: Dan Auerbach <dan@eff.org>
- Cc: "public-tracking@w3.org" <public-tracking@w3.org>
Hi Dan, I've added this proposal to the relevant wiki page, next to Roy's change proposal on the same topic: http://www.w3.org/wiki/Privacy/TPWG/Change_Proposal_Service_Provider For the ease of the reader, I've included just the normative sections of the proposal on the wiki page, with a link to your email for more detail. Thanks, Nick On Jun 25, 2013, at 11:49 PM, Dan Auerbach <dan@eff.org> wrote: > I unfortunately haven't had time to digest the history and current state > of the service provider debate as reflected by the June document. I'm > posting old relevant text so that I don't give up my right to object > about service providers, since I think the text below is more detailed > and requires some important technical controls on the part of service > providers: > > > A first party may outsource website functionality to a third party, in > which case the third party may act as the first party under this > standard with the following additional restrictions. > > 1 Technical Precautions > > 1.1 Operative Text > > Throughout all data reception, retention, and use, outsourced service > providers must use all feasible technical precautions to both mitigate > the linkability of and prevent the linking of data from different first > parties. > > Structural separation ("siloing") of data per first party, including > both separate data structures and avoidance of shared unique identifiers > are necessary, but not necessarily sufficient, technical precautions. > > 1.2 Non-Normative Discussion > > 1.2.1 Siloing in the Browser > > Outsourcing services should use browser access control features so that > stored data specific to one first party is never accessed or received > when the user visits another first party. > > 1.2.1.1 Same-Origin Policy > > The same-origin policy silos stored data by domain name. An outsourcing > service can use a different domain name for each first party. > > Example: Example Analytics provides an outsourced analytics service to > Example News and Example Sports, two unrelated websites. Example > Analytics stores its cookies for Example News at > examplenews.exampleanalytics.com, and it stores its cookies for Example > Sports at examplesports.exampleanalytics.com. > > 1.2.1.2 Cookie Path Attribute > > The HTTP cookie path can be used to silo data to a first party. > > Example: Example Analytics stores its cookies for Example News with > "Path=/examplenews", and it stores its cookies for Example Sports with > "Path=/examplesports". > > 1.2.1.3 Storage Key > > For key/value storage APIs, such as Web Storage and Indexed Database, an > outsourcing service can use a different key or key prefix for each first > party. > > Example: Example Analytics stores data for Example News at > window.localStorage["examplenews"] and data for Example Sports at > window.localStorage["examplesports"]. > > 1.2.2 Siloing in the Backend > > 1.2.2.1 Encryption Keys > > An outsourcing service should encrypt each first party's data with a > different set of keys. > > 1.2.2.2 Access Controls > > An outsourcing service should deploy access controls so that only > authorized personnel are able to access siloed data, and only for > authorized purposes. > > 1.2.2.3 Access Monitoring > > An outsourcing service should deploy access monitoring mechanisms to > detect improper use of siloed data. > > 1.2.3 Retention in the Backend > > An outsourcing service should retain information only so long as > necessary to provide necessary functionality to a first party. If a > service creates periodic reports, for example, it should delete the data > used for a report once it is generated. An outsourcing service should be > particularly sensitive to retaining protocol logs, since they may allow > correlating user activity across multiple first parties. > > 2 Internal Practices > > 2.1 Operative Text > > Throughout all data reception, retention, and use, outsourced service > providers must use sufficient internal practices to prevent the linking > of data from different first parties. > > 2.2 Non-Normative Discussion > > 2.2.1 Policy > > An outsourcing service should establish a clear internal policy that > gives guidance on how to receive, retain, and use outsourced data in > compliance with this standard. > > 2.2.2 Training > > Personnel that interact with outsourced data should be familiarized with > internal policy on compliance with this standard. > > 2.2.3 Supervision and Reporting > > An outsourcing service should establish a supervision and reporting > structure for detecting improper access. > > 2.2.4 Auditing > > External auditors should periodically examine an outsourcing service to > assess whether it is in compliance with this standard and has adopted > best practices. Auditor reports should be made available to the public. > > 3 Use Direction > > An outsourced service must use data retained on behalf of a first party > ONLY on behalf of that first party, and must not use data retained on > behalf of a first party for their own business purposes, or for any > other reasons. > > 4 First-Party Requirements > > 4.1 Representation > > A first party's representation that it is in compliance with this > standard includes a representation that its outsourcing service > providers comply with this standard. > > 4.2 Contract > > A first party must enter into a contract with an outsourcing service > provider that requires that outsourcing service provider to comply with > these requirements. > > > > -- > Dan Auerbach > Staff Technologist > Electronic Frontier Foundation > dan@eff.org > 415 436 9333 x134 > >
Received on Wednesday, 26 June 2013 23:20:02 UTC