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

RE: [ISSUE-81, ACTION-13] Response Header Format

From: Matthias Schunter <mts@zurich.ibm.com>
Date: Wed, 19 Oct 2011 02:08:31 -0400
To: "JC Cannon" <jccannon@microsoft.com>
Cc: "David Singer" <singer@apple.com>, "Shane Wiley" <wileys@yahoo-inc.com>, "public-tracking@w3.org" <public-tracking@w3.org>
Message-ID: <OFC1257067.003A1E53-ONC125792E.0021B2E8@ch.ibm.com>

Hi Folks,

Thanks for all the input on response headers. Roy and I will summarize it
for the strawman.

Regards,
 Matthias

-original message-
Subject: RE: [ISSUE-81, ACTION-13] Response Header Format
From: "JC Cannon" <jccannon@microsoft.com>
Date: 2011/10/19 00:42



This is starting to sound like P3P again, where websites are doing a lot of
work to send responses that aren’t really used. If it is not for the
consumer and user-agent processing is optional then how do we justify
asking sites to do the work?



JC

Twitter



From: public-tracking-request@w3.org
[mailto:public-tracking-request@w3.org] On Behalf Of David Singer
Sent: Tuesday, October 18, 2011 3:36 PM
To: Shane Wiley
Cc: public-tracking@w3.org
Subject: Re: [ISSUE-81, ACTION-13] Response Header Format





On Oct 18, 2011, at 15:26 , Shane Wiley wrote:



My concern with deep response layers is that explaining this to the average
consumer becomes problematic and undermines to a degree the goal of
consumers understanding what DNT means and how it impacts their online
experiences.



The response doesn't go to the average consumer, it goes to their user
agent. How well (or even whether) the user-agent processes the response and
explains it to the consumer is firmly out of our scope. Our job is to make
a clear protocol between two pieces of software, not manage the
relationships and explanations at either end beyond the scope of the
protocol.



That's why I think that if the protocol enables the two ends to be clear,
we enable further clarity.





- Shane



From: public-tracking-request@w3.org
[mailto:public-tracking-request@w3.org] On Behalf Of David Singer
Sent: Tuesday, October 18, 2011 3:23 PM
To: public-tracking@w3.org
Subject: Re: [ISSUE-81, ACTION-13] Response Header Format



I think the idea of a 'nuanced' answer is good.  I fear the number of times
that a 'simple' answer unambiguously applies might be quite small.



The responses in the 100-range below are the 'exception' ones ("I am
tracking you"), and I'd suggest that 100-series is probably more logically
the 'success' (your request not to be tracked is being more-or-less
honored).  I like the idea that the existence of these responses allows web
sites to say what they are doing even without a request, that's cool.



100 = I see your DNT and respect it completely (same as currently suggested
1)

101 = You have an opt-out cookie, and I am therefore not tracking you

102 = I never track anyone anyway



200 = You asked for DNT but I will not respect it (same as currently
suggested 0) [[ should this be a 400-series?? ]]

201 = Will not respect because I am a 1st party

202 = Will not respect because you have explicitly opted in to my tracking

203 = I claim I am Allowed to track because it’s for research (possibly)

205 - I am tracking you to the extent required by law

206 - I am still tracking you for some other/unspecified reason for which
there is no distinct response code




300 = I don’t know (could be the default, and probably means the same thing
as no response)



4xx - error situations? (like?)





From: JC Cannon [mailto:jccannon@microsoft.com]
Sent: Saturday, October 15, 2011 2:01 PM
To: Kevin Smith; public-tracking@w3.org
Subject: RE: [ISSUE-81, ACTION-13] Response Header Format



First parties should not have to return a response.



I think it's really helpful, especially if the user and the site disagree
about what a first party is. It provides excellent feedback.





David Singer

Multimedia and Software Standards, Apple Inc.





David Singer

Multimedia and Software Standards, Apple Inc.

Received on Wednesday, 19 October 2011 06:09:02 UTC

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