- From: Jonathan Mayer <jmayer@stanford.edu>
- Date: Wed, 14 Mar 2012 09:18:31 -0700
- To: Roy T. Fielding <fielding@gbiv.com>
- Cc: Tracking Protection Working Group WG <public-tracking@w3.org>
On Mar 14, 2012, at 3:22 AM, Roy T. Fielding wrote: > On Mar 14, 2012, at 1:09 AM, Jonathan Mayer wrote: > >> 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. > > They would qualify for the exemption for fraud prevention, assuming > the data use and retention is so limited. That's a question of how we scope the exception. It's easy to add clarifying language that that's not what this text is about. > I did not consider them > under the outsourcing exemption because siloing their data per > first-party would be unusual. My understanding is practices substantially vary. It would be helpful to hear from companies in the space. >> 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. > > No, my point was that DNT cannot have an impact on fraud control, period. > If it did, then the presence of DNT:1 would be indicative of > "reasonable grounds to believe the user or user agent is presently > attempting to commit fraud". The chance that a randomly chosen browser with DNT: 1 is committing fraud, independent of other evidence, will be very low. That's not "reasonable grounds." > In any case, the nature of data collection for fraud prevention is > to collect a lot of data on non-fraudulent behavior, so that when > an anomalous set of behavior is encountered the "alarm" is triggered. Many websites (not just third parties) already use a proportionate response approach to fraud prevention and security. I'm not aware of any third-party service (save fingerprinters) that presently uses a non-cookie active tracking technology for every user that has disabled cookies. > The premise on which your two operative texts are based is that the > fraud control engine can determine "reasonable grounds" without > first collecting or using data about the user agent. It does not > work that way (and I am not just talking about advertising fraud). The text is premised on the notion that protocol logs and interaction information are sufficient to establish "reasonable grounds." > I am not saying this isn't a privacy concern. I am saying it won't > be addressed by DNT because lessening fraud control on the basis of > a signal received from the client is simply not a viable option. > I would encourage the regulators to find a solution to this concern > outside of DNT, since it has nothing to do with preferences/consent. If there's a blanket security or fraud exception, then the privacy properties of DNT are mooted. I don't believe the privacy advocates in the group would ever accept such an exception. Let's talk with potential implementers about their needs before concluding we're between a rock and a hard place. > ....Roy > >
Received on Wednesday, 14 March 2012 16:19:13 UTC