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

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

From: Shane Wiley <wileys@yahoo-inc.com>
Date: Sat, 15 Oct 2011 23:06:03 -0700
To: Kevin Smith <kevsmith@adobe.com>, JC Cannon <jccannon@microsoft.com>, "public-tracking@w3.org" <public-tracking@w3.org>
Message-ID: <63294A1959410048A33AEE161379C8023D021027E4@SP2-EX07VS02.ds.corp.yahoo.com>
Would it be possible simplify this further?

<No Response> = DNT not implemented  (initial state for the vast majority of websites in the world)
0 = You've not turned on DNT but I have implemented support <not sure if this is needed>
1 = Received your DNT signal and honoring it
2 = Received your DNT signal and not honoring it due to prior exception granted

It'll be important to record exceptions client side as a Publisher will need some signal on whether to trigger an exception dialogue with a user or not.  I'll look up the appropriate item # to also attach this comment and example to.

Example Use Case:

1.       User turns on DNT and visits ExamplePublisher1.com

2.       ExamplePublisher1.com does not receive a signal it's on the exceptions list

3.       ExamplePublisher1.com requests exception from user to access content for free

4.       User grants exception to ExamplePublisher1.com (and listed parties <to be discussed separately>)

5.       User views content

6.       User returns to ExamplePublisher1.com a week later

7.       DNT signal is still turned on but ExamplePublisher1.com is sent an exemption flag (or else doesn't send a DNT signal at all)

8.       In either case, it'll be important that ExamplePublisher1.com know to not trigger the exception request for this user/web browser/device

- Shane

From: public-tracking-request@w3.org [mailto:public-tracking-request@w3.org] On Behalf Of Kevin Smith
Sent: Saturday, October 15, 2011 8:43 PM
To: JC Cannon; public-tracking@w3.org
Subject: RE: [ISSUE-81, ACTION-13] Response Header Format

I agree with you.  In fact, I am still not sure we need a response header at all.  I was just pointing out that if we do have a return header, we might want to think about possibly grouping answer types.  As for the 300 series options, I thought it might make a good web server default (ie for small sites using shared hosting that do not even look at their server settings), although the absence of a header would likely meant the same thing.

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. We could have a response for third parties acting in a first-party context such as search windows that are in use.

I don't see how the 300 series responses are practical.


From: public-tracking-request@w3.org [mailto:public-tracking-request@w3.org] On Behalf Of Kevin Smith
Sent: Friday, October 14, 2011 2:40 PM
To: public-tracking@w3.org
Subject: [ISSUE-81, ACTION-13] Response Header Format

I am still not convinced a return header is necessary, but if we decide it is, as Tom mentioned in Action 13, it is important that our spec be very extensible for possible future modifications.  The binary approach he suggested (1 = Respect the DNT signal, 0 = Will not respect) is certainly easy to extend.  If other responses are needed, you can easily add additional codes.  If we wanted to add textual explanations as Peter (I think) suggested in Boston, or URIs to definition documents as Roy suggested, they could easily be appended to the header.

However, one thing that a 0|1 response would make it difficult to do in the future would be to group different types of responses such as defined reasons why a site may or may not respect the DNT header.  If we think it is likely that additional responses will be needed now or in the future, we may want to follow something closer to the http response codes (ie 200s = ok, 300s = redirect, 400s = bad request etc)

For example,

100 = Will not respect DNT (same as currently suggested 0)
101 = Will not respect because I am a 1st party
102 = Will not respect because you have opted in to my tracking
103 = Allowed to track because it's for research (possibly)
104 = Allowed to track because of exemption X

200 = Will Respect DNT (same as currently suggested 1)
201 = Even though DNT was not turned on, you have an opt-out cookie
202 = I never track

300 = I don't know (could be the default, and probably means the same thing as no response)
301 = Don't know because I have never set up a web server before, I don't know what DNT means and I will never get enough hits for anyone to care about what I do anyway.  (OK, we probably do not need a code for this - just checking if you are still reading)

Then if a browser or plugin wanted to provide a more customized experience to the user, it could use this additional information.  I am not saying that we should take this approach now (or ever), but if we wanted to start with the simple binary approach, perhaps we should start with codes 100=No, 200=Yes (or something similar), so that we leave our options open in the future.

Note: this is certainly not the only way to do it.  We could also go with a 0|1 now, and then add a delimiter with a subcode (ie - 1:2 = You have opted back in).  I just thought this may be a good grouping mechanism that is easy to parse and process.

Just food for thought.

Received on Sunday, 16 October 2011 06:06:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:38:26 UTC