- From: Shane Wiley <wileys@yahoo-inc.com>
- Date: Sun, 18 Mar 2012 11:47:35 -0700
- To: Jonathan Mayer <jmayer@stanford.edu>
- CC: "Roy T. Fielding" <fielding@gbiv.com>, Vinay Goel <vigoel@adobe.com>, Tracking Protection Working Group WG <public-tracking@w3.org>
Jonathan, I believe it's on this cornerstone point that we can respectively agree to strongly disagree. I believe a majority of the working group would like the scope to expressly focused on solving the "cross-site profiling" issue. While I understand you and Jeff Chester a few others would like to greatly expand the scope to include as many additional topics as possible, I don't believe this is in the best interests of the working group. While you call it "kicking the can", I believe many of the non-cross site profiling issues you raise can be more appropriately addressed in separate efforts where a deeper dive can be taken into each issue, appropriate experts invited to the working group for those topics, and thoughtful outcomes developed. This group, in the minds of many of the working group, is trying to solve too many issues at one time and we're not meaningfully able to provide each issue the just review it deserves. I believe addressing "cross-site profiling" will be a big win for everyone, including regulators in the US and in the EU. What is the best way to find resolution on this key topic? Do we need to raise a new issue? I can provide new text to be discussed that appropriately narrows the scope of the working group if that is the appropriate next step. Thank you, Shane -----Original Message----- From: Jonathan Mayer [mailto:jmayer@stanford.edu] Sent: Sunday, March 18, 2012 11:17 AM To: Shane Wiley Cc: Roy T. Fielding; Vinay Goel; Tracking Protection Working Group WG Subject: Re: Best Practices for Outsourcing (ACTION-47, ISSUE-49) Shane, This group is not "attempt[ing] to solve all online privacy issues." But at the some time, it is not so narrow as a "core purpose" of "multi-site profiling." Many stakeholders believe Do Not Track should curtail collection and retention of data - not just profiling or personalization use. That necessarily requires some limits to outsourcing practices. I share your concern about reaching the June deadline. The way to finish our work it to constructively address the substantive issues that stakeholders have raised. There is nothing helpful in protesting the group's scope and suggesting we kick the can down the road. Jonathan On Mar 18, 2012, at 10:50 AM, Shane Wiley wrote: > Jonathan, > > The "reasonable" element of law has a rich history in global law statues so I'm not sure we should outright dismiss this approach. I don't personally remember that we agreed to abandon this concept in Santa Clara. We've discussed "data minimization" standards that align with this concept as its difficult to develop a one-size fits all policies (such as data retention) for all business types and data types across the world. > > I would suggest "best practices for outsourcing" be a non-working group (non-W3C) document that is developed and released once the WG has completed the standard. > > In my opinion, continuing to attempt to solve all online privacy issues within this working group continues to bog us down from the core purpose: multi-site profiling. The sooner we can come to consensus on a tighter agreement of our intended purpose, the sooner we can start closing on the larger issues and have any hope of meeting the June timeframe. > > - Shane > > -----Original Message----- > From: Jonathan Mayer [mailto:jmayer@stanford.edu] > Sent: Friday, March 16, 2012 7:31 PM > To: Roy T. Fielding > Cc: Vinay Goel; Tracking Protection Working Group WG > Subject: Re: Best Practices for Outsourcing (ACTION-47, ISSUE-49) > > I'm no expert in W3C lingo, so let me explain what I want the language to do. > > As written, the outsourcing operative text requires "reasonable" technical precautions. In many legal contexts, especially related to electronic privacy and security, "reasonable" has been read as a near-nullity. (For example, "as long as reasonably necessary" retention limits.) I don't want that to happen here, and I think we had consensus in Santa Clara that that's not the intent. > > This text gives some contours to what we have in mind by "reasonable." It is non-normative in that it does not require any particular technical implementation. But it is also not merely a collection of best practices - the standard would require use of technologies that have similar privacy properties to these examples. > > Jonathan > > On Mar 16, 2012, at 5:50 PM, Roy T. Fielding wrote: > >> On Mar 16, 2012, at 10:30 AM, Jonathan Mayer wrote: >> >>> At the Santa Clara meeting we debated whether to mandate specific technical requirements for the outsourcing exception. The compromise consensus was to call for "reasonable" measures and give implementers guidance in a non-normative section. >> >> Hi Jonathan, >> >> Saying "you should do" is a normative statement, regardless of >> where it appears or whether or not the word should is in uppercase. >> As such, standards editors are instructed not to use it within >> non-normative sections except when the subject is clearly not a party >> to the standard. The compliance spec has a few other bugs like that >> which the editors will need to fix once we have fewer options. >> >> Normally, this kind of text would appear in a Best Practices document, >> separate from the compliance or protocol spec, and be phrased in neutral >> terms like "Here are a set of practices that are believed to preserve >> privacy (or at least limit loss of privacy) ...". If it was developed >> within the WG, it would be written by subject matter experts -- like >> by the sysops within some of the larger outsourcing orgs. It could >> also be written up as a paper outside the WG process and referenced as >> non-normative, just like I referenced the KnowPrivacy paper in the >> intro. >> >> Normally, such best practices are written after the standard has >> reached consensus. >> >> >> Cheers, >> >> Roy T. Fielding <http://roy.gbiv.com/> >> Principal Scientist, Adobe Systems <http://adobe.com/enterprise> >> >> > > >
Received on Sunday, 18 March 2012 18:48:16 UTC