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

RE: Deciding Exceptions (ISSUE-23, ISSUE-24, ISSUE-25, ISSUE-31, ISSUE-34, ISSUE-49)

From: Shane Wiley <wileys@yahoo-inc.com>
Date: Wed, 8 Feb 2012 07:03:31 -0800
To: Rigo Wenning <rigo@w3.org>, "public-tracking@w3.org" <public-tracking@w3.org>
CC: "Roy T. Fielding" <fielding@gbiv.com>, Jonathan Mayer <jmayer@stanford.edu>
Message-ID: <63294A1959410048A33AEE161379C8023D0C8AC9EE@SP2-EX07VS02.ds.corp.yahoo.com>
Arbitrary timeframes are just that - arbitrary.  I would recommend the group continue to uphold minimization standards and force parties to defend their retention periods that are unique and specific to their business model.

-----Original Message-----
From: Rigo Wenning [mailto:rigo@w3.org] 
Sent: Wednesday, February 08, 2012 3:21 AM
To: public-tracking@w3.org
Cc: Roy T. Fielding; Jonathan Mayer
Subject: Re: Deciding Exceptions (ISSUE-23, ISSUE-24, ISSUE-25, ISSUE-31, ISSUE-34, ISSUE-49)

On Tuesday 07 February 2012 18:29:45 Roy T. Fielding wrote:
> You defined collection as merely receiving the information.  The user is
> sending the information across the network.  Therefore, the third party
> will collect it regardless of our protocol.  Retention, however, can be
> limited in such a way that the user's browsing history cannot be discovered
> from the data retained for frequency capping.  Is that sufficient?  If not,
> why?

Wasn't that the first suggestion Ninja made in Brussels when confronted with 
this issue? She said 24-48 hours. Let's discuss that...

We could resolve by having 2 options: Either have a client-side storage 
solution under the user's control OR the service has a shorter retention time 
and will not be able to maintain the capping over an entire campaign of 
several month.

That sets the incentives to explore the client-side solutions under user 
control without forcing people to it.

Received on Wednesday, 8 February 2012 15:09:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:38:33 UTC