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: Ninja Marnau <ninja@w3.org>
Date: Wed, 22 Jan 2014 22:36:23 +0100
Message-ID: <52E039D7.3060802@w3.org>
To: public-tracking@w3.org, Mike O'Neill <michael.oneill@baycloud.com>
Hi Mike,

not sure if I understand your proposal correctly, but I think what you 
suggested might still be included in the current Editors' TPE draft:

http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html#TSV-N
By the tracking status value of “Not Tracking” (N) and “Tracking” (T)

Ninja

Am 22.01.14 22:27, schrieb Ninja Marnau:
> 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
>>
>>> -----Original Message-----
>>> From: Matthias Schunter (Intel Corporation) 
>>> [mailto:mts-std@schunter.org]
>>> Sent: 16 January 2014 20:00
>>> To: public-tracking@w3.org
>>> Subject: Re: Signals for internal / external usage of site elements 
>>> (the
>> signals
>>> formerly called "1" and "3")
>>>
>>> Hi Folks,
>>>
>>> I had the impression that some people may be interested in retaining
>>> these signals in the TPE.
>>> If this is the case, I would like to solicit text proposals...
>>>
>>>
>>> Regards,
>>>    matthias
>>>
>>> Am 08.01.2014 09:14, schrieb Roy T. Fielding:
>>>> On Jan 7, 2014, at 9:55 PM, Mike O'Neill wrote:
>>>>
>>>>> Anyway, its removal in the first place was a chairs/editors decision,
>> never
>>> requested by the rest of us.
>>>> First, the editors' draft doesn't have it because I don't know of any
>> way to
>>> express a first/third party design distinction without some notion 
>>> of the
>>> constraints on first vs third (i.e., that's 100% compliance).
>>>> Second, there have been dozens of requests to avoid importing
>> definitions into
>>> TPE that are not necessary to express the protocol.  Clearly, these
>> definitions
>>> are right on the borderline -- the distinctions that this group has 
>>> made
>> regarding
>>> first and third parties are not discernible by either side of the
>> connection, so it is
>>> extremely unlikely that any technical implementations of those 
>>> ownership
>>> concepts will be correct. They are regulatory concerns, not technical
>> concerns.
>>>> Hence, if at all possible, my preference is to avoid using these terms
>> within the
>>> protocol exchange.  This does not prevent them from being used to 
>>> guide or
>>> explain compliance.
>>>>> My problem was solely with overloading the definition of tracking 
>>>>> with
>> the
>>> ambiguous multiple contexts limitation, which I still feel is
>> inappropriate in the
>>> TPE.
>>>> That is both incorrect and irrelevant to this discussion.  One of the
>> nice
>>>> things about closed issues is that we aren't allowed to discuss them
>> again
>>>> without new information.
>>>>
>>>>> Mike
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: David Singer [mailto:singer@apple.com]
>>>>>> Sent: 08 January 2014 00:10
>>>>>> To: Matthias Schunter (Intel Corporation)
>>>>>> Cc: Mike O'Neill; Tracking Protection Working Group; Dobbs, Brooks
>>>>>> Subject: Re: Signals for internal / external usage of site elements
>> (the signals
>>> formerly called "1" and "3")
>>>>>> I think that the browser being able to tell in a uniform way 
>>>>>> whether a
>> site
>>> was
>>>>>> designed as first party or third party, without making any 
>>>>>> statements
>> about
>>> what
>>>>>> first party or third party rules it conforms to, is useful.
>>>> I will try once again to explain the problem space.
>>>>
>>>> First, we aren't talking about sites.  A browser might care to know
>> whether a
>>> given subrequest is to the same origin, same parent domain, or to a
>> resource
>>> that is controlled by the same owner as the page that they intended to
>> visit.
>>> Unfortunately, the browser doesn't know what page the user intended to
>> visit,
>>> let alone who owns that page.  The initial request target is not
>> necessarily a first
>>> party; the first party depends on how the potential action (i.e., link)
>> was
>>> presented to the user, not the URI referenced in that action.  This is
>> something
>>> that only a user (or regulator acting as a user) can determine.
>>>> The fact that the browser has been told to fetch a number of pages and
>>> eventually render content within a frame on one of those pages and, 
>>> as a
>> result,
>>> make more subrequests as instructed by an assortment of page rendering
>>> choices, driven from some combination of local configuration, standard
>> HTML,
>>> CSS, and non-standard scripting, does not in any way inform the browser
>> which
>>> of those requests correspond to the intent of the user. In fact, it is
>> quite possible
>>> that none of them do (e.g., phishing).
>>>> A browser, therefore, has no idea whether a given page ought to be 
>>>> first
>> party,
>>> let alone the elements within that page.
>>>> Second, if a browser happens to think it is on a first party page and
>> makes a
>>> subrequest to a resource that claims to be first party, why would 
>>> the user
>> think
>>> there might be something amiss?  Because of the domain names?  Browsers
>>> don't know what parties own/control what domains.  Browsers can't see
>>> common branding.  Browsers can't make any of the decisions that would
>>> somehow distinguish one resource owner from another even when they are
>>> operating on different domains, and there's no guarantee that two
>> different
>>> parties can't occupy the same domain (in fact, they often do).
>>>> Finally, if by some miracle the browser does manage to distinguish one
>>> resource from another as being owned by different parties, and somehow
>>> manages to know which of those parties the user actually intended to
>> interact
>>> with, and also that this is not a case of joint first parties, then 
>>> what
>> is it going to
>>> do?
>>>> Is it going to
>>>>
>>>>     a) make the subrequest with DNT:1 and hope it all works out?
>>>>     b) fetch the TSR for this designated resource and inspect its
>>>>        info before doing (a)?
>>>>     c) check the resource's reputation with some listing service?
>>>>
>>>> Those are the three choices.  Here are the implications:
>>>>
>>>>     (a) it has already decided that informing the user before they are
>>>>         tracked is not desired; the 1/3 flag will not be received.
>>>>
>>>>     (b) the TSR will either not exist (no compliance) or contain
>> sufficient
>>>>         detail for the browser to make a decision based solely on 
>>>> whether
>>>>         it trusts the identified controller -- whether or not the
>> resource
>>>>         is designed for first or third party use is irrelevant if the
>> controller
>>>>         is trusted (to somehow comply) with DNT:1, and even less 
>>>> relevant
>> if
>>>>         the controller isn't trusted.
>>>>
>>>>     (c) the listing service will make a decision for the browser,
>> regardless
>>>>         of the first or third party status.
>>>>
>>>>>> Even if a conformance regime is finally conceived that doesn’t 
>>>>>> make or
>> need
>>> the
>>>>>> distinction, it’s not harmful for the TPE to enable signalling it 
>>>>>> for
>> sites using
>>> that
>>>>>> regime; it’s just not relevant.
>>>> It is always harmful to send bytes that aren't used.  In 
>>>> particular, the
>> 1/3
>>> distinction is the main source of variance in the TSR response, which
>> means it
>>> effects both the likelihood of simple static implementation and the
>> cacheability
>>> of the TSR verification result.  If there is no 1/3 flag, then the vast
>> majority of
>>> servers (both first and third party) can use a single TSR for their 
>>> entire
>> service.
>>>>>> As you say, finding a resource that presumed it was in a 1st party
>> context,
>>> being
>>>>>> used in a 3rd party context, should be a warning flag to the browser
>> that
>>> maybe
>>>>>> the site is not following the rules for the context it has (probably
>>> unwittingly)
>>>>>> been placed in.  In the current compliance document, we place much
>> lighter
>>>>>> constraints on 1st party than on 3rd, so there may well be a concern
>> for the
>>> user
>>>>>> here.
>>>>>>
>>>>>> These flags don’t link to a specific conformance regime.  I don’t 
>>>>>> see
>> the
>>> problem
>>>>>> that Mike sees, honestly, and they really help the user not to be
>> 'flying
>>> blind’.
>>>> There has been no interest shown by browsers in presenting information
>> to
>>> their users, regardless of what the response might be. A user is 
>>> going to
>> be
>>> 'flying blind', no matter how we specify the response, unless they use
>> special
>>> tools or extensions for discovery.  What the response does provide is a
>>> statement of business practice that can be inspected by such concerned
>> users,
>>> advocates, and regulators independent of any specific request.
>>>> In terms of verification features, it would be far more useful to 
>>>> active
>> users for
>>> a tool to obtain the TSR for all page components and color code (or 
>>> graph)
>> them
>>> by controller/owner identification.  The user can then find the 
>>> identity
>> that they
>>> intended to interact with, see all the other parties that are not the
>> same, and
>>> make their own decisions about which ones are intended and which are 
>>> not.
>>>> In contrast, the cost and risk of reporting how each specific resource
>> has been
>>> designed to operate are very real concerns for site operators.  It is
>> fairly easy for
>>> a data controller to say that they will turn off all tracking (i.e.,
>> discard any data
>>> about user activity in contexts other than their own first party 
>>> contexts)
>> for
>>> requests with DNT:1.  It is much harder for them to consistently 
>>> identify
>> and
>>> categorize each and every resource on an origin server.
>>>> Hence, I don't think the merits of a tracking status value for 1/3 
>>>> come
>>> anywhere near to justifying its cost, both in terms of getting 
>>> consensus
>> on TPE
>>> and in getting implementations of the protocol in practice.  If 
>>> there is
>> ever a
>>> need for that information as a means of explaining compliance, then 
>>> it can
>> be
>>> included in a qualifier along with all of the other explanations of
>> compliance.
>>>>
>>>> Cheers,
>>>>
>>>> Roy T. Fielding <http://roy.gbiv.com/>
>>>> Senior Principal Scientist, Adobe <https://www.adobe.com/>
>>>>
>>>>
>>
>>
>
>
Received on Wednesday, 22 January 2014 21:36:50 UTC

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