RE: Issue-207

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Jack,

You are right, I meant Tk.

The status-id is there to indicate the specific TSR if there is a subtree of them, so not really designed to carry in-response qualifiers. We could override the definition but that would need changes to the TPE.

The qualifiers property in the TSR could be used to dynamically return different indications but this would be very long-winded and would require the use of a unique identifier to chain the non-atomic transactions, which many would see as a fail for the standard.

mike



From: Jack Hobaugh [mailto:jack@networkadvertising.org]
Sent: 18 April 2014 13:22
To: Mike O'Neill
Cc: Shane M Wiley; Rob van Eijk; Justin Brookman; W3C DNT Working Group Mailing List
Subject: Re: Issue-207

Hi Mike,

For purposes of furthering the discussion, I am assuming by "Tr" you mean "Tk."

As I interpret the spec, the TSR is optionally available in the Tk response through the status-id portion of the Tk-field-value.  I am referring to section 6.3.1 of the TPE.

For example:

Tk: D; DisregardReason

where the DisregardReason would refer to the "specific tracking status resource" that could contain the qualifiers.

Best regards,

Jack

On Thu, Apr 17, 2014 at 6:03 PM, Mike O'Neill <michael.oneill@baycloud.com> wrote:
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Jack,

That’s the TSR ( the well-known named tracking resource), I meant the TSV in the Tr response header so a server responding with a D can qualify it.

mike

From: Jack Hobaugh [mailto:jack@networkadvertising.org]
Sent: 17 April 2014 22:38
To: Mike O'Neill
Cc: Shane M Wiley; rob@blaeu.com; Justin Brookman; W3C DNT Working Group Mailing List
Subject: Re: Issue-207

Hi Mike,

I don’t understand your statement rewarding not being able to add qualifiers.  As I interpret the TSV, qualifiers are available:
6.5.4 Qualifiers Property
An origin server may send a property named qualifiers with a string value containing a sequence of case sensitive characters corresponding to explanations or limitations on the extent of tracking. Multiple qualifiers indicate that multiple explanations or forms of tracking might apply for the designated resource. The meaning of each qualifier is presumed to be defined by one or more of the regimes listed in compliance.
qualifiers    = %x22 "qualifiers" %x22
qualifiers-v  = %x22 *qualifier %x22
qualifier     = id-char

Are you suggesting that these qualifier’s are not available for a “tracking” status of “D”?

Best regards,

Jack
On Apr 17, 2014, at 5:14 PM, Mike O'Neill <michael.oneill@baycloud.com> wrote:
- - -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Only offering a list of reasons why the signal "might" be disregarded does not improve transparency and encourages arbitrarily ignoring of DNT. As there is no way to add qualifiers to the TSV we either have to 1) come up with a mechanism in the TPE to report qualifiers, or 2) add a further set of single character values to signal different disregard reasons, or 3) abolish the "D" signal or 4) reiterate the note in the TCS that a disregard response is assumed to be an exceptional event.

My vote would be for 3, i.e. Jonathan's point but if that is too radical we should at least do 4.

So:

A third party to a given user action that disregards a DNT signal MUST indicate so to the user agent, using the response mechanism defined in the [TRACKING-DNT] recommendation. (5.0 4th para)

Becomes:
A third party to a given user action that disregards a DNT signal MUST [indicate its reason for doing] so to the user agent, using the response mechanism defined in the [TRACKING-DNT] recommendation. This specification is written with an assumption that disregarding DNT would only be used in situations that can be adequately described to users as an exception to normal behavior. If this turns out not to be the case, either the server's decision to disregard the signal needs re-examination, or this specification, or both.

Mike
- - -----Original Message-----
From: Shane M Wiley [mailto:wileys@yahoo-inc.com]
Sent: 17 April 2014 20:24
To: rob@blaeu.com; Justin Brookman
Cc: W3C DNT Working Group Mailing List
Subject: RE: Issue-207

Rob,

The Working Group had originally agreed on two principles pre-W3C Staff/Co-
Chair "June Draft" Compliance document that I believe are in alignment with
your thinking here:

1) If a Server is representing compliance then they must send the "D" response
when disregarding the user's signal, not simply disregard it.
2) A Server must accompany a "D" response with a resource link to explain why
the user may be receiving the disregard response.
- - - Shane

- - -----Original Message-----
From: Rob van Eijk [mailto:rob@blaeu.com]
Sent: Thursday, April 17, 2014 12:02 PM
To: Justin Brookman
Cc: W3C DNT Working Group Mailing List
Subject: Re: Issue-207


Hi Justin,
Dear group members,

Having given this issue a bit more thought, I have come to the conclusion that
something needs to be added the discussion. I therefore request the issue to
remain open.

The TCS should IMHO include text that a party MUST provide information
regarding the specific reason for not honoring the user expression. A key
element, addressed in the TPE is that Tracking providers should not ever have to
second-guess a user's expressed Do Not Track preference. It is fair to say, that
users should not have to second-guess with regard to the D-signal (quid pro quo
principle). Just responding with 'D' would not be enough IMHO to fulfill the quid
pro quo. The user / user agent needs to know about the reason why the signal
got disregarded. The party's representation MUST be easy discoverable, clear
and unambiguous. It MAY be machine readable. The guiding principle IMHO, is
that transparency is key in the granular discussion between the user agent and
the server to prevent e.g., discrimination based on the use of (a certain brand of)
technology, or just plain arbitrariness.

I am trying to strike the right balance hear, and welcome your views.

Regards,
Rob
- - ---
Recital 66

"Third parties may wish to store information on the equipment of a
user, or gain access to information already stored, for a number of purposes,
ranging from the legitimate (such as certain types of cookies) to those involving
unwarranted intrusion into the private sphere (such as spyware or viruses). It is
therefore of paramount importance that users be provided with clear and
comprehensive information when engaging in any activity which could result in
such storage or gaining of access.
The methods of providing information and offering the right to refuse should be
as user-friendly as possible. Exceptions to the obligation to provide information
and offer the right to refuse should be limited to those situations where the
technical storage or access is strictly necessary for the legitimate purpose of
enabling the use of a specific service explicitly requested by the subscriber or
user. Where it is technically possible and effective, in accordance with the
relevant provisions of Directive 95/46/EC, the user’s consent to processing may
be expressed by using the appropriate settings of a browser or other application.
The enforcement of these requirements should be made more effective by way
of enhanced powers granted to the relevant national authorities. "

Justin Brookman schreef op 2014-04-17 20:22:
On yesterday's call, we discussed ISSUE-207 (Conditions for
Disregarding (or Not) DNT Signals) against the Compliance
specification.  Previously, some working group participants had argued
that servers should never disregard or second guess DNT signals that
are correctly formed (syntactically valid).  However, as we crafted
the TPE, we explicitly provided for a mechanism that allows servers to
signal to a user that they are disregarding the signal.  As adherence
to TCS (or any other compliance regime) is voluntary anyway, there may
no longer be an argument that TCS should prohibit disregarding certain
DNT headers.  In any event, no one on the call yesterday expressed
support for the previous change proposal to require servers to honor
all DNT requests.

If anyone wishes to argue for amending the TCS to require compliance
with all DNT signals --- or alternatively thinks that TCS needs to be
revised to make it more clear that servers have the option to send a D
(disregard) signal --- please reply on the mailing list.  Otherwise,
we will close the issue with no further edits as decided by consensus
in two weeks.
- - -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
Comment: Using gpg4o v3.2.42.4591 - http://www.gpg4o.de/
Charset: utf-8

iQEcBAEBAgAGBQJTUERCAAoJEHMxUy4uXm2JdnUIAIF3hoyZBdngzbNhncg+6Uuu
OxR+eo9Mw4hwqF6c5arHZb3VdPB8pJSpj6xOPci4EG57mCdkk4B4Cy0LPjWdrusk
rKpSnY4xJzp1xD8oDbGSE986YzB8DmbLiN16OdS7Ax5GFZSyB375sM+rI2spnzD0
x50C8b00E5ZdZ4w3Le3uN4sBgxZJARCHUR2uxqtepSM6Kgk2RzyAVW0y8fnOp55p
hEAFu0aKH2L5j+2jKNWm26LppaO6QFY33rpuwVsxn75hC2NhDDhICapaqxG4HIf5
MUjdLTViX95CYtYdgrYdU7UGvkP1VYu7yyetwkUKIZp/CVBEWYjbxv6ugFmP1m8=
=SYu8
- - -----END PGP SIGNATURE-----

- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
Comment: Using gpg4o v3.2.42.4591 - http://www.gpg4o.de/
Charset: utf-8
iQEcBAEBAgAGBQJTUE+lAAoJEHMxUy4uXm2JbIYH/08gmnFEyzNmPbxJm3dDUgUm
QRjIRmNWE3yUECgHAzUJAMwxnCF6/0GhkRbQ9nQot8Hyu3XdTNi5czygYdTncRef
VL9ru7+OWbNb0A4w2YfBWn+Oz7U8qaFrzjK7si9hgRaPrv4HmYtPnZnR1XHRJ1Rv
MDiC3AqAo5rkJ1CUI/k/3Z/tHSrbWr78Tcc7DYGALAc3fA5i5pbtt6pGzDi4nbgk
3h7yTWPIUXsAOF8d3cTB+oHyqFnL47kZjqw2lEIUKz91Tp3vcEgkfYr9kflMmTNC
X2vvKdO3IQkqRRhz756fsqv8lbVH9oiNcldCO2qQriPOBp7uXl0cv1F1jXo7Lys=
=/WdP
- -----END PGP SIGNATURE-----




- --
Jack L. Hobaugh Jr
Network Advertising Initiative | Counsel & Senior Director of Technology
1620 Eye St. NW, Suite 210 Washington, DC 20006
P: 202-347-5341 | jack@networkadvertising.org

The information contained in this e-mail is confidential and intended for the named recipient(s) only. However, it is not intended as legal advice nor should you consider it as such. You should contact a lawyer for any legal advice. If you are not an intended recipient of this email you must not copy, distribute or take any further action in reliance on it and you should delete it and notify the sender immediately.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
Comment: Using gpg4o v3.2.42.4591 - http://www.gpg4o.de/
Charset: utf-8

iQEcBAEBAgAGBQJTUSDxAAoJEHMxUy4uXm2JxN8IALFDIYLgst/TJIZP3dNitiUK
aVnVAkWmd+CUgrGFF8g2aQDD0ysB4N7QH3C2nqyIuh5y0FyH/W6nQvsj/lA49Mup
lzMWfFYFzm7yhG7swozkw17UWgm8V58UEDhKzyzT6pZUFgeNdAQC2O312+v1essz
xt5S4rvr2ED9vmAm0odmIYsh5QgrFIgPDwx99p7p34hV0AzYKODoHygG2GbesXFT
4QpwdoY/xDJptrUfIblSUD9d2urXYP3W/oWKpFlRLgjO7skx+rpxOuqPMnOtTwzJ
ck5J4IOH+wFKvIp7UT828uduF+FY2LBMI2KiWjmWEYDD8AZ3SDWOSk4YN1wn/sg=
=qxAo
-----END PGP SIGNATURE-----