W3C home > Mailing lists > Public > public-tracking@w3.org > January 2014

Re: ISSUE-241 - Signals for internal / external usage of site elements (the signals formerly called "1" and "3")

From: Roy T. Fielding <fielding@gbiv.com>
Date: Wed, 22 Jan 2014 14:28:17 -0800
Message-Id: <EACEA59A-7E5F-4446-81DE-248A4F6055F4@gbiv.com>
To: Tracking Protection Working Group <public-tracking@w3.org>
Dear Chairs,

I would like to suggest that the chairs take a more active stance in
reducing proposals to text which addresses the issue being discussed.

Mike's proposal doesn't seem to have anything to do with this issue.
It instead revisits several other CLOSED issues for the sake of
simplifying the protocol. IMO, if he wants to revisit the other TSVs,
then he needs to have the chairs reopen those issues.  If he wants
to propose a "no change", then the text should reflect the current
text of the document, where "N" and "T" are currently being used
for those options.  If he just wants to change the symbols from
"N" -> "0" and "T" -> "1", then he should raise an issue specifically
for that purpose.

Likewise, Nick's text reintroduces *all* of the qualifiers that
were discussed (but never closed) under Compliance.  Any change
proposal that intends to do that must also include definitions
for the phases "frequency capping", "financial logging",
"security and anti-fraud", "debugging", and "audience measurement".
In other words, it would have to import most of Compliance.

I don't think it is fair to ISSUE-241 to mix these together.
We are only talking about the "designed for first/third-party use"
distinctions in ISSUE-241.  Other distinctions belong in their own
issues, if anywhere.  [IMO, none of them belong in TPE.]

I will add a "no change" proposal that explains why qualifiers for
1/3 are not needed under the new definition of tracking.


On Jan 22, 2014, at 1:27 PM, Ninja Marnau wrote:

> I created a wiki page for ISSUE-241: https://www.w3.org/wiki/Privacy/TPWG/Proposals_on_elements_for_1and3_party_use
> Currently it lists Mike's and Nick's proposal. Please feel encouraged to add further text proposals as the chairs will decide within the next two weeks whether to proceed to Call for Objections.
> Ninja
> Am 18.01.14 21:14, schrieb Mike O'Neill:
>> Hi Matthias,
>> Here is my text suggestion.
>> Tracking Status Value
>> A tracking status value (TSV) is a short notation for communicating how a
>> designated resource conforms to the tracking protection protocol, as defined
>> by this document and [TRACKING-COMPLIANCE]. For a site-wide tracking status
>> resource, the designated resource to which the tracking status applies is
>> any resource on the same origin server. For a Tk response header field, the
>> corresponding request target is the designated resource and remains so for
>> any subsequent request-specific tracking status resource referred to by that
>> field. A Tracking Status Value of "0" means that the origin server is
>> tracking as defined in this document. A TSV of "1" means that the user is
>> not being tracked. Any other value, or if the TSV is not present, indicates
>> that the origin server may be tracking. Other values MAY be described in the
>> document referenced by the URI in the policy property of the Tracking Status
>> Resource.
>> TSV    =  "1"                  ; the origin server is not tracking
>>            /  "0"	         ; The origin server is tracking
>>           / ALPHA/DIGIT   ; the origin server may be tracking, and this
>> value may be described in the policy resource
>>        Justification.
>> The DNT protocol is supposed to be a simple way for a user to express their
>> general preference on tracking and all this response element does is over
>> complicate that. It is of no practical use other than to obscure the issue
>> and will anyway probably be ignored by user-agents. A user simply requires
>> to know if their request not to be tracked is being honoured and having
>> upward of 9 possible values of the TSV convey very little to them. A 1 or 0
>> response maps simply to the DNT header values and will be easier for users
>> to understand.
>> Mike
Received on Wednesday, 22 January 2014 22:28:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:40:06 UTC