- From: Ninja Marnau <ninja@w3.org>
- Date: Wed, 22 Jan 2014 22:36:23 +0100
- 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