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

RE: Best Practices for Outsourcing (ACTION-47, ISSUE-49)

From: Shane Wiley <wileys@yahoo-inc.com>
Date: Sun, 18 Mar 2012 10:50:27 -0700
To: Jonathan Mayer <jmayer@stanford.edu>, "Roy T. Fielding" <fielding@gbiv.com>
CC: Vinay Goel <vigoel@adobe.com>, Tracking Protection Working Group WG <public-tracking@w3.org>
Message-ID: <63294A1959410048A33AEE161379C8023D105D87E3@SP2-EX07VS02.ds.corp.yahoo.com>

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.


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 17:51:12 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:44:46 UTC