- From: Chris Blouch <cblouch@aol.com>
- Date: Fri, 20 Jul 2012 16:56:22 -0400
- To: public-tracking@w3.org
- Message-ID: <5009C5F6.4050403@aol.com>
Be gentle, I'm new here :) Comments are specific to the mechanics of
exposing the DTN response header value to the page content/scripts:
Generally very little of the http header response fields are exposed via
JS and the few which are seem to be hung from the document object. For
example, document.modified showing the Last-Modified field or
document.location exposing the Location field. All others are locked
away in the header even though it might be quite useful for Javascript
to be able to pull the Content-Language or Age. How the few fields which
are exposed were chosen is a mystery to me but they might give some
illumination as to how, or whether, another header value should be
exposed as a read-only JS value.
In the wild, the remaining headers gets exposed in one of two ways.
Either the server-side script injects header values into the document
content in some non-standardized format (such as a snippet of JS or
microformatted CSS classes added to tags) or the client-side JS does a
second Ajax header request to the URL of the page it is on so it can
then examine the response object's header contents. The former method
has limitations because it is the wild wild west for exactly how the
header values are exposed. The latter not only requires a second fetch
but has possible erroneous data due to reading headers of a separate
request, which usually, but not always, will be identical to the actual
page.
If we want to eliminate both home grown solutions (and the baggage they
bring) it makes the most sense to expose a new javascript var which
simply states what is contained in the response header. The surrounding
circumstances and ramifications of which are probably already handled by
the business rules encoded into other embedded data and scripts. In
other words, I suggest following the existing response header pattern by
using document.dnt to expose exactly what is in the header for that
document when it came back from being processed by the server.
Chris Blouch
AOL
On 7/18/12 12:31 PM, Jonathan Mayer wrote:
> Agreed. I would make the what-are-the-future-implications? language
> on the header and attribute parallel. I would also drop the last
> sentence (websites already MUST check the HTTP header, right?), and
> instead add an explanatory note about how the doNotTrack attribute is
> merely a convenience accessor.
>
> On Wednesday, July 18, 2012 at 5:44 AM, Ed Felten wrote:
>
>> It seems more consistent to say "MUST NOT" instead of "SHOULD NOT" in
>> the suggested text. Using "SHOULD NOT" implies that it might
>> sometimes be acceptable to interpret the doNotTrack attribute as a
>> guarantee of the header value that will be sent in future requests,
>> which conflicts with the later statement that servers MUST rely on the
>> header value that is actually received in a future request.
>>
>>
>> On Wed, Jul 18, 2012 at 2:38 AM, Nicholas Doty <npdoty@w3.org
>> <mailto:npdoty@w3.org>> wrote:
>>> I did not see responses to this proposal back in May. Matthias asked
>>> (ACTION-224) that I ensure the editor's draft reflected this
>>> proposal. Here are the changes I think the editors would need to
>>> make (and I'm happy to help them with the actual wordsmithing and
>>> HTML-editing) to implement this proposal.
>>>
>>> Thanks,
>>> Nick
>>>
>>> Add to section 4.3.2:
>>> The doNotTrack attribute must have a string value that is the same
>>> as the DNT-field-value sent to the origin of the corresponding
>>> `document`.
>>>
>>> Add to 4.3 or to a new sub-section:
>>> The value of the doNotTrack attribute SHOULD be considered guidance
>>> and SHOULD NOT be interpreted as a guarantee of the value of the DNT
>>> header sent on future requests. A user's tracking preference may
>>> change and may differ for different origins. Servers MUST rely on
>>> the DNT header received in a request even if it differs from what a
>>> script previously observed in the `doNotTrack` attribute. Trackers
>>> that commonly expect to receive a user-granted exception (as
>>> described in Section 6) SHOULD assess the user's preference in the
>>> HTTP request loading that script.
>>>
>>> On May 30, 2012, at 12:31 AM, Nicholas Doty wrote:
>>>
>>>> (This is more broadly related to ISSUE-84, and this summary and
>>>> proposal addresses ACTION-180.)
>>>>
>>>> ## Quick summary
>>>>
>>>> It would be nice if JavaScript on the page could access the
>>>> appropriate DNT preference for the user so as to know not to take
>>>> actions that initiate or involve tracking, or to provide a
>>>> different user experience (like privacy options, or an exception
>>>> request). One concern with a naively implemented
>>>> navigator.doNotTrack property is that the DNT value may vary (in
>>>> the case of user-agent-managed user-granted exceptions) for
>>>> different domains but the DOM property is singular. In particular,
>>>> if a script is embedded via a <script> tag, it will have the same
>>>> effective script origin as the first party page but may have a
>>>> different expressed tracking preference. We would like JavaScript
>>>> running on the page to make decisions based on the DNT value and
>>>> not receive mixed signals about the user's DNT preference.
>>>>
>>>> ## Proposal
>>>>
>>>> navigator.doNotTrack reflects the value of the DNT header sent to
>>>> the 1st party (the top-level document origin). For the simplest
>>>> implementation (DNT:1 sent for all requests, no exceptions yet
>>>> granted), this is already effective; this reflects current
>>>> implementations in IE and Firefox. First party JavaScript can
>>>> safely use the DOM property to determine the user's tracking
>>>> preference for the first party domain and as an indicator that
>>>> embedded third parties may be receiving a DNT:1 value.
>>>>
>>>> Guidance is provided that the doNotTrack DOM property is a hint but
>>>> does not guarantee the value of the DNT header sent on future
>>>> requests (via XmlHttpRequest, for example); compliant servers must
>>>> use the HTTP header on a particular request to respect the user's
>>>> preference. A user's preference may have changed (even within a
>>>> first-party context) or may be different for different domains.
>>>>
>>>> This is especially important guidance for third-party trackers
>>>> which may commonly receive a different DNT header value than the
>>>> first party. For trackers that do not commonly expect to receive
>>>> user-agent-managed exceptions, the first party value is likely to
>>>> be sufficient guidance (assuming the header is always sent to first
>>>> parties, see below). For trackers that do commonly expect to
>>>> receive user-granted exceptions, the user's DNT preference should
>>>> be assessed during the HTTP request and should not rely on the DOM
>>>> property.
>>>>
>>>> ## Relevant related questions
>>>>
>>>> Some questions turn on what value the first party will receive. If
>>>> a first party is guaranteed to receive a DNT header starting with
>>>> "1" if the user has configured *any* third party domain to receive
>>>> DNT:1, then the DOM property is guaranteed to be no more permissive
>>>> than the value for the third party. Some user agents might like the
>>>> option of not sending DNT:1 to every first party domain if a user
>>>> has configured the browser to opt out of tracking for only some
>>>> trackers (as in the current self-regulatory opt-out cookie approach).
>>>>
>>>> Depending on how we conclude ISSUE-111, the first party header may
>>>> explicitly indicate a separate value for third parties in the case
>>>> of a site-wide exception. For example, if DNT:10 is sent when a
>>>> user has granted a site-wide exception, then third party JavaScript
>>>> in that case could determine the presence of the relevant exception
>>>> by checking the value of navigator.doNotTrack[1]. (I would support
>>>> this resolution of ISSUE-111, which would help substantially with
>>>> this issue and address some concerns we've heard re: publishers and
>>>> server-side decision-making.)
>>>>
>>>> ## Alternatives that I've heard but am not proposing
>>>>
>>>> A parameterized function, a la navigator.mayTrack("thirdparty.com
>>>> <http://thirdparty.com>").
>>>> Pros: Flexibility and detailed info for tracking JavaScript.
>>>> Cons: Seems inelegant, enables fingerprinting, enables one third
>>>> party to determine the exception status of another.
>>>>
>>>> A different navigator.doNotTrack value for JavaScript from a
>>>> different domain.
>>>> Pros: Magically gives all JS the correct value.
>>>> Cons: Hard to distinguish in the browser (since effective script
>>>> origin is the same) and especially in the case of browser plugins.
>>>>
>>>> Removing the DOM property altogether.
>>>> Pros: Straightforward.
>>>> Cons: Non-dynamically-generated JavaScript can't make efficient
>>>> decisions re: DNT status.
>
Received on Friday, 20 July 2012 20:56:52 UTC