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

RE: Graduated response (ACTION-279)

From: Shane Wiley <wileys@yahoo-inc.com>
Date: Thu, 1 Nov 2012 08:06:08 -0700
To: Rigo Wenning <rigo@w3.org>, "public-tracking@w3.org" <public-tracking@w3.org>
CC: "ifette@google.com" <ifette@google.com>
Message-ID: <63294A1959410048A33AEE161379C8027484803701@SP2-EX07VS02.ds.corp.yahoo.com>

I'm generally okay with Nick's proposed text for the "master rules" for all Permitted Uses.  My comments here are in relationship to Ian's proposed text.

- Shane

-----Original Message-----
From: Rigo Wenning [mailto:rigo@w3.org] 
Sent: Wednesday, October 31, 2012 7:10 PM
To: public-tracking@w3.org
Cc: Shane Wiley; ifette@google.com
Subject: Re: Graduated response (ACTION-279)


IMHO, the data minimization principle and the purpose limitation we installed for permitted uses cut both ways. Only collect what is necessary and only keep it as long as you need it. So "graduate response" by saying I delete stuff that I don't need anymore is an expression of those principles. 
The issue is rather how much "more" will trigger the alarm bells of "unnecessary" collection. There is wiggle room and we can explore that. But I wouldn't assume we can disregard the collection limitation and just bet on the subsequent deletion. No easy answer there. Nick tries to put that in words. Not bad. What would you open up with which changes to Nick's wording?


On Wednesday 31 October 2012 09:15:59 Shane Wiley wrote:
> Would it be possible to look at “graduated response” in the opposite 
> direction as an element of data minimization?  Collect more data 
> up-front (security, debugging, frequency capping) and move to less 
> data where possible as a “graduated response”.  As I stated in 
> Amsterdam, attempting to operational-ize a technical “graduated 
> response” in the less->more sense is not a trivial matter (if at all 
> really possible in most circumstances), whereas the opposite is much 
> more doable.
Received on Thursday, 1 November 2012 15:06:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:39:13 UTC