W3C home > Mailing lists > Public > public-tracking@w3.org > March 2012

RE: Work ahead; volunteers?

From: Kevin Smith <kevsmith@adobe.com>
Date: Tue, 6 Mar 2012 12:49:32 -0800
To: Rigo Wenning <rigo@w3.org>, "public-tracking@w3.org" <public-tracking@w3.org>
CC: Shane Wiley <wileys@yahoo-inc.com>, Matthias Schunter <mts@zurich.ibm.com>
Message-ID: <6E120BECD1FFF142BC26B61F4D994CF3064CC200C6@nambx07.corp.adobe.com>
Rigo - I do agree that the 1st party would like to know which 3rd parties its visitors are uncomfortable with, however, that only works if the user has any clue what the various 3rd parties do so that they can make an intelligent decision.  What percentage of web users do you think have ever heard of doubleclick (just an example because its one of the biggest 3rd party services out there)?  Many services will be drastically more cryptic.  Do you really think you (not you specifically) can come up with a UI that educates people to the point that they will understand what service doubleclick provides to the 1st party, and why the 1st party requires that service in order to show the content the person is trying to view, and help them feel comfortable with doubleclick?  Perhaps once or twice for a couple of 3rd parties.  Could you do so in a way that people will be willing to go through that process multiple times for every major website they visit, sometimes repetitively as they drill deeper into that single site?  I personally do not think so.

No - I am not trying to prescribe specific UI treatments.  However, simply waving our hands and saying 'That is out of scope because it is a UI problem' is no excuse for publishing a spec that makes said UI treatments so difficult if not impossible.  I personally cannot envision any UI that would make this process palatable to many users.

This solution is just as bad for the user as it is for the 1st party.  Its expensive for the 1st party, and frustrating for the user.  Their comfort level is with the 1st party, not a cryptic 3rd party they have never heard of (that's why we are doing this after all).  Certainly the 3rd parties and tracking practices need to be well documented and readily accessible for any user with concerns that is willing to invest the effort to understand such things.  However, to forcefully insert it into the primary workflow for all users with DNT:1 turned on will result in much fewer users with DNT:1 turned on.

-----Original Message-----
From: Rigo Wenning [mailto:rigo@w3.org] 
Sent: Tuesday, March 06, 2012 11:43 AM
To: public-tracking@w3.org
Cc: Shane Wiley; Matthias Schunter
Subject: Re: Work ahead; volunteers?


only to be sure I understand:

I think you're addressing an issue of the user agent. And I think a user agent should communicate with the service about the exceptions of _that_ service. 
This is a necessary communication channel IMHO if we want consent building and adaptive services. So if you're arguing for that, I'm with you. 

But this shouldn't mean that anybody can just query all exceptions which could be a privacy disaster if you go to health.insurance.example.com and they discover you have a DNT exception entry for contentious.health.form.example.org. 

Kevin, IMHO this is needed for human reasons because the service wants to know whether their opt-back-in strategy worked or on which page users are tripping and put on DNT etc. Just social experience from DNT and no strong feeling from me about whether to allow or not. IMHO it is just better with such a query system. 


On Tuesday 06 March 2012 06:59:18 Shane Wiley wrote:
> I don't believe the following issue is closed (or if it is, I'll 
> propose we reopen the issue as Server-Side interrogation of 
> site-specific exceptions will be an important option -- bad actors can 
> find numerous other ways to digitally fingerprint a user's system and 
> I believe we've agreed to not cripple the DNT standard in attempts to manage bad actors).
> "- we decided not to provide an API for retrieving the set
>   of exceptions for a server due to the resulting finger
>   printing risks"
Received on Tuesday, 6 March 2012 20:50:08 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:44:46 UTC