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

Re: ACTION-114 ISSUE-107 : Revised response header.

From: Sean Harvey <sharvey@google.com>
Date: Thu, 9 Feb 2012 15:50:58 +0000
Message-ID: <CAFy-vufFm5JdHygk8fJFVT302ObAjzvbts_1X0fOovKH8b6-CQ@mail.gmail.com>
To: Shane Wiley <wileys@yahoo-inc.com>
Cc: Matthias Schunter <mts@zurich.ibm.com>, Nick Doty <npdoty@w3.org>, Heather West <heatherwest@google.com>, "public-tracking@w3.org" <public-tracking@w3.org>
that would really help


On Thu, Feb 9, 2012 at 3:47 PM, Shane Wiley <wileys@yahoo-inc.com> wrote:

> Specific to Issue #1, the draft text for Site-Specific Exceptions
> recommends that the user agent send a DNT:2 to the 1st party to let them
> know site-specific exceptions exist for the current user.****
>
> ** **
>
> - Shane****
>
> ** **
>
> *From:* Sean Harvey [mailto:sharvey@google.com]
> *Sent:* Thursday, February 09, 2012 6:29 AM
> *To:* Matthias Schunter
> *Cc:* Nick Doty; Heather West; public-tracking@w3.org
> *Subject:* Re: ACTION-114 ISSUE-107 : Revised response header.****
>
> ** **
>
> Thanks Matthias, I didn't want to be alarmist but I think this is a real
> potential problem -- though I continue to hold out hope that I am simply
> misunderstanding something. ****
>
> ** **
>
> Context and a couple of clarifying questions in this respect:****
>
>    1. How is the third party going to know from the DNT:0 that they may
>    only collect site specific information? What if the user visits two sites
>    consecutively, both of which have site specific exceptions? Might not the
>    third party server unknowingly (re)place a cookie on the browser when they
>    see DNT:0 and then check that cookie on both site 1 and site 2 because they
>    both have DNT-off values? ****
>    2. The majority of third parties are probably not going to start by
>    supporting site specific exceptions because of the technical complexity
>    involved in sometimes-on/sometimes-off states, and the work involved in
>    creating site-specific partitions. What they want to know is the user's
>    default state so they can opt them out of any cookie-ing and be done with
>    it. Will they now be unable to do this based on the current state of the
>    dnt header spec? ****
>
> thanks -- again I may be fundamentally misunderstanding the current state
> of conversations, but want to double-check that we haven't steered off down
> the wrong road. ****
>
> ** **
>
> sean****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> On Thu, Feb 9, 2012 at 2:06 PM, Matthias Schunter <mts@zurich.ibm.com>
> wrote:****
>
> Hi Sean,
>
> Somewhat I do not understand your question.
>
> My point was that the DNT header is the definitive resource for user
> preference info.
> In case of site-specific-exceptions, the header will change to DNT;0,
> i.e., the site can still rely on the header as the sole source of
> preference information.
>
> We discuss whether we provide means for a server to obtain more info
> (what exceptions, am I an exception,  and the like).
>
> The point wrt cookies is that if a site uses other means to 'cache'
> DNT preferences, it does so at its own risk.
>
> While a portal that translates incoming DNT signals to cookies to
> allow back-end systems to use the legacy cookie mechanisms, the site
> needs to ensure that this translation is sound and that DNT;1 is
> always respected (while loosing some DNT'0 preferences should be OK
> by, eg., not being fast enough to destroy an opt-out cookie for your
> site after receiving a DNT;0 signal).
>
> Did this clarify your point?
>
> Regards,
> matthias****
>
>
>
>
>
> On 2/8/2012 11:22 AM, Sean Harvey wrote:
> > Thanks Matthias. just a quick double check without having to waste
> > everyone's time. The point here is that the server should not have to
> > check any cookies including opt out cookies to determine the user's
> > default DNT status. I assume we are not saying that currently there is
> > no clear way for the server to understand the user's default DNT state
> > when a site-specific exception is in place?
> >
> >
> >
> >
> > On Mon, Feb 6, 2012 at 9:28 PM, Matthias Schunter <mts@zurich.ibm.com***
> *
>
> > <mailto:mts@zurich.ibm.com>> wrote:
> >
> >     Hi Sean,
> >
> >
> >     thanks for reviewing the header proposal. I agree with Nick that this
> >     should largely work:
> >
> >     1. The user browses SITE and sends whatever DNT value (or none) that
> >     he prefers
> >     2. The site discovers an opt-out cookie and interprets this as DNT;1
> >     3. The site responds with a response header that signals its intended
> >     usage
> >         (e.g., no tracking / third party)
> >
> >     However, I believe that obtaining headers may be more reliable than
> >     using redundant information from cookies. Consider a case where:
> >      a) The user prefers DNT;1 and sends this header everywhere
> >           and has an opt-out cookie as well.
> >      b) The site only interprets the cookie (ignoring the header)
> >           and assumes DNT;0 if it receives no cookie
> >      c) the user deletes all cookies while continuing to send DNT;1
> >
> >     In this case, the site would assume DNT;0 while the user has sent
> >     DNT;1.
> >
> >     Note that this is not a problem of the response headers. It is rather
> >     an issue how to keep the DNT header info in sync with other opt-out
> >     schemes. The challenge is to ensure that the cookies used by the site
> >     are always in sync with the DNT header sent by the user.
> >
> >
> >     Regards,
> >     matthias
> >
> >
> >
> >
> >     On 2/5/2012 11:15 PM, Sean Harvey wrote:
> >     > The concern is that some systems may wish to respect a DNT header
> >     > being on (in part) by setting an opt-out cookie. This opt-out
> cookie
> >     > would mean that site-specific exemptions will be ignored and the
> >     user
> >     > will be treated as DNT=on in all cases. This is practically
> >     easier in
> >     > some cases, and we would want this to at least be an option for a
> >     > server when faced with an array of DNT states.
> >     >
> >
> >
> >
> >
> >
> > --
> > Sean Harvey
> > Business Product Manager
> > Google, Inc.
> > 212-381-5330****
>
> > sharvey@google.com <mailto:sharvey@google.com>****
>
>
>
> ****
>
> ** **
>
> --
> Sean Harvey
> Business Product Manager
> Google, Inc.
> 212-381-5330
> sharvey@google.com****
>



-- 
Sean Harvey
Business Product Manager
Google, Inc.
212-381-5330
sharvey@google.com
Received on Thursday, 9 February 2012 15:51:32 UTC

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