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

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