- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Wed, 8 Feb 2012 17:15:43 -0800
- To: Rigo Wenning <rigo@w3.org>
- Cc: public-tracking@w3.org
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 01:16:11 UTC