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

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

From: Karl Dubost <karld@opera.com>
Date: Thu, 23 Feb 2012 15:08:48 -0500
Message-Id: <9A1A5CD5-AC54-4CCD-BE18-498822912BCD@opera.com>
Cc: "public-tracking@w3.org Group WG" <public-tracking@w3.org>
To: Alan Chapell <achapell@chapellassociates.com>
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.

> 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 20:09:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:38:34 UTC