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

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