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

Re: ACTION-326 and ACTION-327 BLOCKED on ISSUE-5

From: Rob van Eijk <rob@blaeu.com>
Date: Sun, 18 Nov 2012 20:01:12 +0100
To: <public-tracking@w3.org>
Message-ID: <42374a6eba01dda90eeefe279fd0503c@xs4all.nl>

Rigo,

>> Not tracking means no collection of personal data except those 
>> permitted.
I disagree with this. To me the permitted uses also are forms of 
tracking. If these would not be tracking, there would not be a reason to 
include them in the standard as exempt. It would suffice to declare them 
out of scope. The main reason I include them in any tracking definition 
is due to the use of unique identifiers.

Rob

Kimon Zorbas schreef op 2012-11-18 19:47:
> Rigo,
>  The definition you proposed could be a reasonable start for
> discussions. Obviously, the current definitions in the draft EU law
> will determine the degree of acceptance.
>
>  Kind regards,
>  Kimon
>
> ----- Reply message -----
>  From: "Rigo Wenning" <rigo@w3.org>
>  To: "public-tracking@w3.org" <public-tracking@w3.org>
>  Cc: "Roy T. Fielding" <fielding@gbiv.com>, "Lauren Gelman"
> <gelman@blurryedge.com>
>  Subject: ACTION-326 and ACTION-327 BLOCKED on ISSUE-5
>  Date: Sun, Nov 18, 2012 7:26 pm
>
> Roy,
>
>  I don't know what you want to accomplish here. I guess you want to
> reduce the
>  scope of the obligations by defining that collection/use limitations
> only
>  apply in case of "tracking". This would allow to continue to collect
> where
>  there is no "tracking" involved, right?
>
>  I suggested a definition on IRC at the 14 November meeting saying:
>
>  Tracking is defined by all the collection of personal data in the
> browsing
>  context. Not tracking means no collection of personal data except
> those
>  permitted.
>
>  One might argue on "browsing context". I would define it as every
> exchange
>  over HTTP. (As W3C is somewhat limited to HTTP)
>
>  Would that fit your needs? It excludes responsibility for data
> collection by
>  snail-mail campaigns.
>
>  BTW, the definition above is not specific enough for informed 
> consent
> in the
>  EU, that's why we need a more precise, but open-ended, definition of
> DNT:0 So
>  DNT:0 is the definition of tracking and DNT:1 says: "I don't do 
> that,
> except
>  for the permitted uses".
>
>  Any more narrow definition of "tracking" will actually interfere 
> with
> the
>  permissions and requirements as laid down in the Specification and
> thus
>  opening the entire discussion again, which means return to day one 
> in
> Santa
>  Clara. I certainly would like to avoid that.
>
>  Rigo
>
>  On Friday 16 November 2012 00:42:14 Roy T. Fielding wrote:
>  > On Nov 15, 2012, at 4:43 PM, Lauren Gelman wrote:
>  > > Roy. I just don't understand what this means. Your point about 
> an
> open
>  > > web relying on servers having some flexibility to reject
> misconfigured
>  > > headers was well taken. But isn't the point of any spec to
> displace
>  > > semantics?
>  > No, the point is to describe semantics and bound the 
> implementation
>  > space to something that hopefully accomplishes the semantics. I
> have
>  > yet to see an Internet spec that covered more than 5% of what it 
> is
>  > required to actually implement the semantics. Generally, we limit
>  > our requirements to known interoperability concerns. There are
>  > very few useful specs that have no errata, and even those specs
> will
>  > become obsolete over time if not maintained. The semantics, in
>  > contrast, are not supposed to change over time.
>  >
>  > > Whether a **server** and a **UA** are accurately communicating
> with each
>  > > other only depends on whether each knows what signals to send 
> and
> what
>  > > actions to take in response. The spec should describe that.
>  > Sorry, that simply isn't true of HTTP. It would take us years just
>  > to discuss the full array of implementations that communicate via
>  > HTTP.
>  >
>  > > Whether a UA accurately describes to **users** what a 
> **feature**
> does is
>  > > a problem we know how to address using messaging and where that
> fails,
>  > > legally under misrepresentation. This group should pass on that.
>  > I agree with that, assuming we have some standard by which 
> accuracy
>  > can be determined.
>  >
>  > > Please, someone. Do a find/replace "tracking" with
> "froobalicious" in the
>  > > documents. Make sure all the actors affected by the doc will 
> know
> what
>  > > to do in the absence of any reliance on shared semantics about
> privacy or
>  > > the meaning of the word tracking. Even add a sentence to the
> intro that
>  > > explicitly states "Tracking means many things to many people and
> this
>  > > spec does not attempt to define it. Instead, it describes a
> technique
>  > > for users to express a limited preference for how certain data
> about them
>  > > is used, a mechanism for recipients to respect that preference,
> and
>  > > exceptions that permit certain business functions to continue
> even if the
>  > > preference is activated."
>  > That would be a reasonable solution if it weren't for the minor
>  > details that browsers are advertising this feature to users as a
>  > "do not track" preference, advocates constantly use the word
> tracking
>  > to accuse industry of evil doings, users are turning the
> configuration
>  > on because they don't want to be tracked, and this tracking
> protection
>  > working group was specifically created to address the issue of
> tracking,
>  > not how to express a preference about how certain data is used.
>  >
>  > I am here to define a protocol for turning off tracking, which
>  > I interpret broadly as anything that has the effect of connecting
>  > a user's activity across multiple websites that do not share the
>  > same user-perceived context. I have no doubt that some people
>  > want DNT to do more than that, and also that some people want
>  > DNT to do less that that. That's why we need an agreed definition.
>  > If we can't agree on a single definition, then we will not agree
>  > on a single set of requirements for accomplishing that definition.
>  >
>  > ....Roy
Received on Sunday, 18 November 2012 19:01:42 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:38 UTC