W3C home > Mailing lists > Public > public-tracking@w3.org > October 2011

Re: ISSUE-5: What is the definition of tracking?

From: David Wainberg <dwainberg@appnexus.com>
Date: Thu, 13 Oct 2011 17:25:18 -0400
Message-ID: <4E97573E.4080903@appnexus.com>
To: Brett Error <brett@adobe.com>
CC: public-tracking@w3.org
I agree with Brett and all the others who have expressed concern about 
the name "Do Not Track." It has great potential to be confusing or even 
misleading to users. I see an inconsistency here. On one hand many seem 
to think that users cannot possibly understand what's happening, so need 
regulation to protect them. On the other hand, it seems we might be 
willing to release a feature with such a confusing name, and then expect 
users to understand it?

On 10/13/11 4:47 PM, Brett Error wrote:
> How many consumers will really visit the page explaining it?  About 
> the same number that read through the EULA click-wraps.
> In today’s world of intuitive design a consumer needing to turn to 
> documentation is a failure.  Why not simply set the proper expectation 
> up front?  We can still have the page… it will be just that much less 
> necessary.  I can’t see the downside of using an name tuned to the 
> function.  On the upside we at least save consumers some time and 
> frustration.
> At the outside perhaps we even cure cancer with all the extra 
> computing cycles Folding@home can take advantage of instead of 
> consumers using them trying to figure out what “Do Not Track” REALLY 
> means. :)
> *From:*Jonathan Mayer [mailto:jmayer@stanford.edu]
> *Sent:* Thursday, October 13, 2011 2:32 PM
> *To:* Brett Error
> *Cc:* Roy T. Fielding; Tracking Protection Working Group WG
> *Subject:* Re: ISSUE-5: What is the definition of tracking?
> I completely share Aleecia's view that the scope of Do Not Track need 
> not match how "tracking" is defined in a dictionary.  We're setting a 
> technical standard here - it will be very open and explicit about 
> what's covered and what's not.  Our standard will be guided largely by 
> user expectations, but also by tech, business, law, policy, and 
> politics constraints.  To the extent we deviate from user 
> expectations, the onus is on us to explain why and how.  But in my 
> view that's a question of follow-on education and discussion, not how 
> we write the standard itself.  For example, I think we would be wise 
> to produce a page explaining in plain terms what's covered and what 
> isn't that all browsers can link to from their privacy settings.  I'm 
> not at all concerned about some sort of media backlash about our 
> definition.  From the outset almost every stakeholder has been clear 
> that Do Not Track is about third-party tracking.  And just about all 
> the press coverage has been about third-party tracking.  I'm 
> particularly surprised to hear these hypocritical arguments coming 
> from IAB and others in the self-regulatory space, since the opt outs 
> y'all currently offer are orders of magnitude more misleading than a 
> transparent Do Not Track standard will ever be.
> As for changing the name from Do Not Track, I would strongly oppose 
> the move.  First, it's the name the world knows this proposal by. 
>  (See, e.g., http://www.google.com/trends?q=do+not+track.)  Attempting 
> a retitle to "Tracking Preference Expression" caused lots of 
> unnecessary confusion among stakeholders.  Second, Do Not Track has 
> real messaging force.  It's no real secret that there are differing 
> degrees of influence around the table.  For some, myself included, the 
> name has been instrumental in making progress on third-party web tracking.
> Jonathan
> On Oct 13, 2011, at 1:16 PM, Brett Error wrote:
>         slow clap<< :)
> -----Original Message-----
> From: public-tracking-request@w3.org 
> <mailto:public-tracking-request@w3.org> 
> [mailto:public-tracking-request@w3.org] On Behalf Of Roy T. Fielding
> Sent: Thursday, October 13, 2011 1:52 PM
> To: Brett Error
> Cc: Tracking Protection Working Group WG
> Subject: Re: ISSUE-5: What is the definition of tracking?
> The essential problem with relying on a set of exceptions is that the 
> end user cannot be expected to know those exceptions.  All they know 
> is the configuration that is set.
> If we give the user an expectation of requesting "Do Not Track"
> and then allow sites to ignore that request on the basis of our set of 
> exceptions, then I think regulators will treat this protocol in the 
> same way that they treat fine print in contracts.
> In other words, we are setting up the situation where the mechanism 
> will be implemented according to our standard but the regulations will 
> be implemented according to the user's expectations -- nullifying our 
> standard in the process.
> Users don't see header fields, so there is no need to change the DNT 
> field name.  However, my current plan is to stop referring to it as 
> "Do Not Track" in the document.
> ....Roy
> On Oct 12, 2011, at 6:02 PM, Brett Error wrote:
> Any time you are recording the behavior/path of something, you are 
> tracking it.  There isn't anything we can do to redefine that in a 
> consumer's lexicon, nor do I think we really want to.
>     The urge to define "tracking" stems from the concern that  "do not
>     track" sounds like it will forbid all tracking.  That, of course,
>     also is not our intention so we feel compelled to redefine the
>     word "track" to curtail its scope (in more of a legal document
>     type of context).
>     That would be one approach.  We can take (and indeed already are
>     taking) a different approach.
>     PROPOSAL: Close ISSUE-5 with the following notes:
>     1) The DNT specification covers a standard way wherein a consumer
>     can express a tracking preference.  It is entirely up to the
>     site/service whether or not to respect that preference.
>     2) It is entirely possible for a site/service to be in full
>     compliance with the DNT specification, and still track a consumer,
>     TRACKED.  An example of this is the first party exemption around
>     which we've reached a (conceptual) consensus.  There are others
>     being discussed.
>     The notion here is that in certain situations, there may be
>     reasons a party may have a right/need to do tracking.  It is our
>     responsibility to define 1) what those situations are, 2) how,
>     even in these situations, we do our best to protect the spirit of
>     what the consumer is requesting (privacy), and 3) how, if at all,
>     the service doing the tracking responds in this type of situation
>     so that the consumer's agent can take action (if any).
>     In doing so, we actually define "track" in the context of DNT, but
>     avoid the messy aspects of a semantics battle.
>     -----Original Message-----
>     From: public-tracking-request@w3.org
>     <mailto:public-tracking-request@w3.org>
>     [mailto:public-tracking-request@w3.org] On Behalf Of Bjoern Hoehrmann
>     Sent: Wednesday, October 12, 2011 6:17 PM
>     To: Aleecia M. McDonald
>     Cc: public-tracking@w3.org <mailto:public-tracking@w3.org>
>     Subject: Re: ISSUE-5: What is the definition of tracking?
>     * Aleecia M. McDonald wrote:
>         I am not convinced either Roy or I have the first case quite
>         solid
>         yet, perhaps because we have each phrased this as more
>         absolute than
>         what people think. It would be very good if people who think
>         there is
>         more to tracking than just data moving between sites could please
>         chime in with a lucid explanation of what they mean.
>     The Working Group cannot define "tracking" without additional
>     modifiers in a manner that is inconsistent with typical english
>     usage. "This user arrived on this page and then moved on to that
>     page" is a statement that cannot be made if the user's movements
>     around the site are not tracked.
>     --
>     Björn Höhrmann · mailto:bjoern@hoehrmann.de ·
>     http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon:
>     +49(0)160/4415681
>     · http://www.bjoernsworld.de
>     25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 ·
>     http://www.websitedev.de/
Received on Thursday, 13 October 2011 21:25:54 UTC

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