(unknown charset) Re: definition of (cross-site) tracking

Hi!


I suggest that we unify the language in both specs by consistently
using the terms
  "tracking preference" and "tracking"
that is currently used in the compliance spec while then referring to
the standards compliance document for further qualification.

I believe that a term is a term and a definition is a definition and
both should stay separate is possible in order to make the term too
overloaded. I also believe that the TPE spec should build on the
compliance spec wrt terminology.

Another note: We seem to agree that cross-site tracking is our focus.
Nevertheless, we have some ISSUES on constraints on 1st parties and
other compliance requirements. By using a term that is too narrow
(read: 'only cross-site' tracking), people may get the impression that
the TPE spec only covers the cross-site aspects of the standards
compliance spec (and not the whole spec). This is an impression I
would like to avoid.

Is everyone OK with this approach?


Regards,
matthias



On 1/14/2012 1:53 AM, David Singer wrote:
> Roy,
> 
> I think were basically on the same page; we need a specification that the users feel is achieving what they desire, and that sites feel that they can honor.  If we miss on either, either users won't bother with it or sites won't implement it.  It's a delicate balance.
> 
> Some of what you talk about is perception, nomenclature, and so on.  Some is more substantive.
> 
> On the substantive points: 
> * as far as I know, we've already decided that sites the user chooses and asks for services from are free to track those chosen visits.  
> * we also have a rough direction that the UA must nonetheless send the DNT header to the first  party in part precisely because the first party deserves to know that its third parties are being sent a DNT request; it might (for example) ask for DNT top be turned off, or charge, or change the way it advertises, or restrict the service, in response.
> I think these two are at least partly addressing your 'free-riding' paragraph.  There may be more that needs to be done.
> 
> You seem to think "do not track" is mis-leading and "do not cross-track" is not;  I don't.  I see problems with both.  Having said that, I can't think of something both succinct and better, at the moment.  "Do not track me on sites that I didn't choose to visit and maybe am not even aware of" is a little wordy :-(.  But users really are asking of involuntary, unseen, uncontrollable, general tracking to become at least partly controllable. Making it visible is difficult, and as the first-party sites choose the third parties, making it voluntary on the part of the users is even harder.
> 
> I actually do think that the protocol and compliance is making progress, and that's the meat of what we're doing.  Perhaps we should make up a nonce word for the moment?  ("Do Not Traciate", anyone?).  Once the documents are expressing what is, and is not, requested by the header, it might be easier to get the right words.
> 
> As I said before, there are several meanings I could associate with "cross-site", only some of which (rather uneasily, IMHO) fit our current direction, and the ones that do are not the meanings that I think are the most obvious.  "Do not cross-site track" suggests that *all other* tracking is OK, which could also be misleading (for both sides), if they think they know what "cross-site" means and are wrong.
> 
> I rejoice to be able to say that I also agree with your third-to-last sentence: "What we should have decided, first, is what we are intending to accomplish via the protocol, and then write that down in a form that everyone agrees to or leaves."  It's critical that we do that in a fashion
> * that leaves as little as possible open to 'interpretation'
> * that users feel meets at least some of their needs and desires, that turning it on achieves something
> * that sites feel they can honor
> or we're wasting our time; if we end up with a protocol users don't use (because they feel it is toothless and useless, for example) or sites don't implement (because they feel it is onerous or their site cannot work under it) we'll end up with, as the sage put it, the sound of one hand clapping. Not the kind of applause we want.
> 
> I also think it might help if the users can, in fact, perceive some negative consequences -- that their privacy is enhanced at the expense of something else.  Then they will choose when to turn it on, instead of making it a default.  I'm not sure we've had that conversation yet.
> 
> On Jan 13, 2012, at 1:22 , Roy T. Fielding wrote:
> 
>>
>> I have no reason to honor Do Not Track if it isn't clearly restricted to
>> actual privacy concerns, such as unexpected or undesired data sharing between
>> sites and perhaps the one Björn raised about resurrecting cleared data.
>> And by clearly restricted, I mean communicated to the user so that they
>> do not get confused by propaganda terms like "Do Not Track", but rather are
>> informed of exactly what the preference will mean to sites that receive it.
>>
>> "Do Not Track" without restrictions does not address a privacy concern.
>> Instead, it is an expressed desire to be a free-rider on the Web of content
>> that is, for the most part, paid for by advertising or marketing revenue
>> made possible by tracking in one form or another.  If a person decides to
>> use a site and sends a request to that site, then that site has the right
>> to collect and retain data about that request and its demand on their
>> services.  The user does not have a right to anonymity.  The user does
>> not have a right to free services.  I have no reason to expect that any
>> more than I would expect Apple to provide an 80% discount on iTunes to
>> anyone with DNT: 1 set.
>>
>> Am I going to get all emotional about that? Yes. These are my customers
>> we are talking about, who are being asked to lose revenue or destroy
>> the usability of their site just because an ill-defined checkbox has
>> been selected in a browser config.
>>
>> All of the input documents I read, and the discussion at the F2F in
>> Cambridge, were advocating the exclusion of non-shared first-party
>> (including outsourced) data collection and personalization from being
>> effected whatsoever by the presence of DNT.  The reason for that is simple:
>> We don't want all of the content providers to require an opt-back-in.
>> We want users who are concerned about the privacy issue to be
>> able to turn on DNT and not be blocked by the same user experience
>> one gets when turning off cookies.  We want users who are surfing with
>> DNT on to have the same personalized customer experience as other
>> users aside from forbidding the use of data obtained from other sites.
>> That's the spec that I agreed to edit.
>>
>> If we can't have a restricted definition for DNT, then I'd rather not
>> have DNT at all.  I'd rather not waste all those bytes on the wire for
>> a user preference that will just be ignored or denied.  I'd rather have
>> the regulators address the privacy issues by setting and enforcing
>> restrictions on what can and cannot be shared between sites without
>> prior consent, and then let each site determine how to obtain consent
>> if they really need data from other sites.
>>
>> Quite frankly, I am tired of repeating this over and over.  Everyone
>> has an opinion.  We aren't all going to be satisfied by every aspect
>> of how the protocol works.  What we should have decided, first, is
>> what we are intending to accomplish via the protocol, and then write
>> that down in a form that everyone agrees to or leaves.  In that respect,
>> I agree with David's second-to-last paragraph above.  If we can't
>> agree on what we are trying to constrain, then the definitions for
>> what we express are never going to obtain consensus.
>>
>> ....Roy
> 
> David Singer
> Multimedia and Software Standards, Apple Inc.
> 
> 
> 
> 
>

Received on Monday, 16 January 2012 17:26:04 UTC