Re: Proportionate Response for Fraud Prevention and Security (ISSUE-24)

I think there are two lines of thinking to unpack here.

1) What does Do Not Track do to third-party services that provide fraud prevention and security functionality for first-party websites (e.g. 41st Parameter, BlueCava)?

My proposal isn't about those services.  At present they get the same treatment as any other third party; in many cases they'll qualify for the outsourcing exception.  If a stakeholder wants to propose a special exception for those services, we could discuss it.

2) How can Do Not Track accommodate fraud prevention and security for pure third-party services without being overly prescriptive?

My proposed text gives quite broad latitude to third party websites.  What is "reasonable" will vary by industry and company.  I agree that guiding examples would be valuable.

On Mar 14, 2012, at 12:54 AM, Roy T. Fielding wrote:

> On Mar 13, 2012, at 11:42 PM, Jonathan Mayer wrote:
> 
>> Industry participants have expressed concern that DNT could curtail their ability to detect fraud and thwart attacks.
> 
> I think you misunderstand.  Industry will not reduce fraud detection or
> attack prevention just because the potential attacker has DNT on, for
> obvious reasons.  It would not be beneficial for legitimate DNT users.
> This is not even open to debate.
> 
>> Civil society participants have expressed concern that blanket exceptions for fraud and security would undermine DNT's privacy protections.
>> 
>> I'd like to propose proportionate response as a direction for compromise.  The notion is straightforward: once there is reason to suspect a user or user agent of foul play, DNT's limits dissipate.  Proportionate response is nothing new in online advertising; many businesses, including some in the group, have already deployed it.  (To some measure proportionate response is already necessary since an attacker could trivially clear cookies.)
> 
> In a word, no.  I will not compromise here.
> 
> Some sites use cookies as a means to differentiate legitimate traffic from
> other traffic -- clearing cookies doesn't impact that at all because the
> user just gets directed back to the setting part.  Generally speaking,
> cookie setting for fraud is only relevant to first-party sites.
> 
> Third-party fraud control is a lot more aggressive, and none of those folks
> will ever implement DNT.  It is their function not to.  Laws and regulations
> are the only things that will ever impact their function (and for some cases,
> not even then).
> 
> There are existing regulatory vehicles for limiting fraud protection and
> associated data retention to what is necessary to perform that function.
> The "necessary" will be different for every site. It should be evaluated
> by folks who are competent in the specific market for which the fraud is
> being prevented.  In some cases, a proportionate response will be the
> recommended course of action; in others, it won't.  In any case, the same
> limitations will apply with or without DNT.
> 
> We should ignore collection by fraud prevention companies and focus instead
> on ways to limit the damage.  For example, forbid data sharing of collected
> data -- only allow aggregate/probabilistic answers regarding a specific
> user so that there is no dual-use of the data and no sharing of user
> activity trails across sites.  Limit retention to what is necessary.
> 
> We could also suggest specific examples of performing fraud prevention
> in specific markets (like online advertising) in ways that are more
> DNT-friendly than storing user activity.  In other words, reduce the scope
> of "necessary" for folks who read the spec.
> 
> ....Roy
>

Received on Wednesday, 14 March 2012 08:09:48 UTC