- From: Rigo Wenning <rigo@w3.org>
- Date: Thu, 09 Feb 2012 11:36:58 +0100
- To: "Roy T. Fielding" <fielding@gbiv.com>, Ninja Marnau <nmarnau@datenschutzzentrum.de>
- Cc: public-tracking@w3.org
Roy, I agree that this sounds like a plan. I think Ninja should look at this whether it addresses her concerns. Rigo On Wednesday 08 February 2012 17:15:43 Roy T. Fielding wrote: > On Feb 8, 2012, at 2:30 AM, Rigo Wenning wrote: > > On Sunday 05 February 2012 16:30:59 Roy T. Fielding wrote: > >> I am not following the part where it is assumed server-side frequency > >> capping cannot be done while preserving privacy. If we are assuming > >> that > >> the server is a good actor, then there should be ways to store the > >> data > >> such that it is no more of a privacy concern than using the network. > > > > How? :) > > I would not specify a single mechanism in the standard, but only the > properties required of an allowed mechanism. > > Frequency capping, as I understand it, can be limited to a campaign > token, user token, and a count. Neither token has to be unique, though > they work best if the probability of collisions (two users with the same > token, or two campaigns with the same token) is very low. Most importantly, > frequency capping does not need to include information about where the ad > was seen. Hence, it is sufficient to forbid creation or retention of the > user token at the server in a form that can be correlated across multiple > referral sites or ad campaigns. > > For example, the frequency capping can be allowed if the count is > identified by a hash(hash(user-id) + hash(campaign-id)), where the > randomly-assigned user-id token is set in a time-limited cookie that > is *not* retained by the server and the campaign-id is embedded > in each ad URI. Hence, both user-id and campaign-id are passed in the > request by the user, the capping service is limited to incrementing > the count for the probably-unique double-hashed key, and the server > does not retain the information necessary (user-id) to cross-match > and correlate the user's activity across sites or multiple campaigns. > Moreover, the user-id is reset whenever the cookie expires or is > deleted by the user. > > I realize that this does not prevent a bad actor from using or > retaining the user identifier and referral information. There is > no general solution to bad actors other than denying them any > information (e.g., not making requests on their sites, excluding > third-party cookies, or pairwise seclusion of cookie data on > the client). > > ....Roy
Received on Thursday, 9 February 2012 10:37:21 UTC