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

RE: Issue 115, exemptions, best practices: Issue 25 and 34

From: Kevin Smith <kevsmith@adobe.com>
Date: Thu, 23 Feb 2012 15:16:56 -0800
To: Karl Dubost <karld@opera.com>, Alan Chapell <achapell@chapellassociates.com>
CC: "public-tracking@w3.org Group WG" <public-tracking@w3.org>
Message-ID: <6E120BECD1FFF142BC26B61F4D994CF3064CB5DA9A@nambx07.corp.adobe.com>
I think we are largely missing the boat here.  I understand the concern Jeff has that people will be coerced into granting site level exceptions.  However, I think a much much larger concern is that sites will not offer exceptions at all.  I think exceptions are for the user much more than they are for the site.  Exceptions are what makes DNT work for users.  It allows them to have specific trusted sites behave normally while letting them feel comfortable on the web as a whole.  I actually think the success of DNT may ride largely on how smooth the browsers are able to make the exception process for users, and how easy it is for sites to implement exceptions.  

In regions where a site's expected DNT users makes up a small percent of overall users (ie under 2%) it will likely cost much more to offer an exception than to offer limited functionality with a note explaining that full functionality requires DNT being turned off.  Exceptions require a website to collect, store, and use the data they collect differently and this is very expensive.  Unless DNT users make up a significant portion of over users, it would usually be much more cost effective to essentially "throw away" any DNT traffic.

We need to be very careful not to create barriers that are too large for either the user or for the sites.  Regardless of how well it protects privacy, a poorly designed experience may be a mortal wound for DNT if it significantly degrades the experience for users or if sites are unwilling to use it.

-----Original Message-----
From: Karl Dubost [mailto:karld@opera.com] 
Sent: Thursday, February 23, 2012 1:09 PM
To: Alan Chapell
Cc: public-tracking@w3.org Group WG
Subject: Re: Issue 115, exemptions, best practices: Issue 25 and 34

trimming the cc: list

Le 13 févr. 2012 à 15:29, Alan Chapell a écrit :
> It might be helpful to return to Jeff's original post. The primary issue that I'm raising is that Jeff's best practices below exceed the scope of what we as a group should be trying to address.

ok, let's see. 
What follows is my personal opinions when I try to see that from an RFC2119 point of view. What I mean by that is an operational point of view outside of any legal, ethical requirements.

Basically as a *technical* standard working group:


> Best Practices for sites to manage exemptions should include:
> 
> A site must provide accurate information to users on the actual data collection and use practices of the site.  This should include all information used for tracking, targeting, sales of profiles.  


"A site must provide accurate information to users" is NOT TESTABLE without a definition of what is contained in "accurate information"

To achieve this in a meaningful way, the Browser and the Web site needs a common format describing all the data categories. If not an actual grammar or syntax, it means that we would need to come up with a taxonomy for these data. A bit like what has been done by the W3C Note on Test Metadata.
http://www.w3.org/TR/test-metadata/


> A site should not suggest that the ability to access information is dependent on blanket acceptance of a site's data practices.


This is not testable. We can't define it in a way that would improve interoperability. What it tells me is that when a user is sending a "DNT:1", and the site is blocking access as a result of that with a message "We can't grant you access because we need to track you to operate our business. If you want access, opt-in but you understand that your data will be tracked."

The only option I could see that is that the Response header (server->client) contains the information necessary to say that the access has not been granted, that you pay with money or you personal data is the choice of users. It looks a bit like "HTTP 402" [1]

    7.4.3.  402 Payment Required
    This code is reserved for future use.

[1]: http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-18#section-7.4.3


> A site should not use "immersive" multimedia applications designed to foster opt-in as a way to encourage a user agreeing to an exemption.


This is totally out of scope or should be treated differently. This is a "Do not lie to the user"


> A site should not use a special landing page that has been designed principally to convert a user to agree to permit an exemption.


Out of scope. This is typically the Web page of any Web site that makes it possible for a Web site to offer a subscription for example. I wish in fact that there would be more pages like this, telling to the user "You have to pay with your personal data or you can subscribe by paying $AMOUNT"


> A site should not use social media marketing to urge a user to ask their "friends" to approve exemptions.


Out of scope. We can't do anything about that. Same category than the do not lie.


> A site should not offer rewards and incentives for a user to approve of an exemption.


Category of all business practices if you pay for 3 months, you get 1 month free. 



-- 
Karl Dubost - http://dev.opera.com/
Developer Relations, Opera Software
Received on Thursday, 23 February 2012 23:17:37 UTC

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