W3C home > Mailing lists > Public > public-tracking@w3.org > August 2012

RE: RESENT: Batch Closing of Issues against TPE [Deadline for validating can-live-with consensus: August 20]

From: Shane Wiley <wileys@yahoo-inc.com>
Date: Mon, 20 Aug 2012 10:15:02 -0700
To: David Singer <singer@apple.com>, David Wainberg <david@networkadvertising.org>
CC: "Matthias Schunter (Intel Corporation)" <mts-std@schunter.org>, "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
Message-ID: <63294A1959410048A33AEE161379C8024F8FDD4A04@SP2-EX07VS02.ds.corp.yahoo.com>
Resending... (See attached)

From: David Singer [mailto:singer@apple.com]
Sent: Monday, August 20, 2012 9:59 AM
To: David Wainberg
Cc: Matthias Schunter (Intel Corporation); public-tracking@w3.org (public-tracking@w3.org)
Subject: Re: RESENT: Batch Closing of Issues against TPE [Deadline for validating can-live-with consensus: August 20]

On Aug 19, 2012, at 8:32 , David Wainberg <david@networkadvertising.org<mailto:david@networkadvertising.org>> wrote:

ISSUE-112 (How are sub-domains handled for site-specific exceptions?) should not be closed. I agree with Shane's last post on the issue. We should not toss out the *.domain.com<http://domain.com> model for speculative fear of misuse. And, we have not adequately explored the repercussions of not providing that option. The issue should remain open pending further exploration.

I fear I may have missed Shane's last post.  Do you have a link to it in the archives?  Sorry!

The issue was two-fold.  If we allow suffix names, rather than fully-qualified names, then (a) the matching process is more complex and (b) we need rules such as in cookies to control (against) the use of public suffixes (see http://publicsuffix.org). These complicate both the specification and the implementation (though it's true that any UA has to do the public suffix control in their cookie code already).


On 8/15/12 12:16 PM, Matthias Schunter (Intel Corporation) wrote:
Hi Team,

in preparation for tomorrow's TPE call, I started assessing the status of our TPE-related ISSUES:

I'd like to thank Roy and David for preparing the next major revision of the TPE spec! They have performed a huge push towards implementing all our prior discussions and draft agreements as updates to the TPE spec. As a consequence, many of our informal agreements are now documented in the text and we have the opportunity to make a large leap towards closing the remaining TPE issues.

Enclosed is a list of issues that I believe satisfy the following criteria:
   - Have been discussed before
   - Proposed text is in TPE spec
   - I believe that all participants can live with the current text

I would like to double-check that my perception is correct and then close these issues.

- Double check that you can live with the proposed resolution and the current corresponding text in the TPE
- Send any comments and clarifying questions to the mailing list
- Send a note if you cannot live with one of the proposed resolutions to the chairs and editors at:
  team-tracking-editors@w3.org<mailto:team-tracking-editors@w3.org> [In this case, some of the issues will be discussed further]

DEADLINE: August 20
- If I do not get further input on any of the issues below, I plan to close them by August 20


-----------------------------------------8>--- ISSUES to be closed + proposed Resolutions ---------------------

ISSUE-47: Should the response from the server indicate a policy that describes the DNT practices of the server?
- A policy attribute at the well-known URI may point to a site-wide policy (Section 5.4.1)
- The response header may identify a more specific policy at a different URL (Section 5.3.2)

ISSUE-61: A site could publish a list of the other domains that are associated with them
- "partners" attribute at the well-known URI identifies partner sites (Section 5.4.1)

ISSUE-84: Make DNT status available to JavaScript
- Revised text in section 4.3.3

ISSUE-107: Exact format of the response header?
- Revised response header values in Section 5.2 and syntax in 5.3

ISSUE-112: How are sub-domains handled for site-specific exceptions?<http://www.w3.org/2011/tracking-protection/track/issues/112>
- Exceptions are granted for fully qualified domain names (Section 6.3.1)

How shall we express responses from a site to a user agent (headers, URIs, ...)?<http://www.w3.org/2011/tracking-protection/track/issues/124>
- Well-known URI + Headers where the essential information needs to be provided with one of the mechanisms

ISSUE-128: HTTP error status code to signal that tracking is required?<http://www.w3.org/2011/tracking-protection/track/issues/128>
- "409" ;-)

ISSUE-130: User-granted Exceptions b) Web-wide Exception for Third Parties (thisthirdparty, anywhere)<http://www.w3.org/2011/tracking-protection/track/issues/130>
- We agreed that web-wide exceptions shall be possible. Text in Section 6.5

ISSUE-155: Remove the received member from tracking status<http://www.w3.org/2011/tracking-protection/track/issues/155>
- Removed attribute has been removed
  since we assume reliable communication

David Singer
Multimedia and Software Standards, Apple Inc.

attached mail follows:

Wouldn’t it be possible for the 1st party to request the sub-domain breadth of site-specific exception that meets the 1st party definition in the argument of the request?

Site-Wide Exception (one domain, all subs):  *.exampledomain.com

Site-Wide Exception (one domain, single sub):  sub.exampledomain.com

Site-Wide Exception (one domain, multiple subs):  [list].exampledomain.com

This somewhat follows the multi-domain list concept in the TPE.

Most websites will rely on the first structure and the 2nd two structures can be collapsed to the [list] approach (example #2 could be supported by a list of one entry).

This does create a window of opportunity to “over request” for an exception but we can hold the 1st party accountable for an inappropriate request.  I don’t want to be hampered by the fear of misuse by bad actors in creating a solution that appropriately matches the real-world.

I don’t believe an exception would need to branch at the protocol level (HTTP vs. HTTPS) – does anyone have a real-world example where the secure element of a sub/domain pair is not owned & operated by the same 1st party of the non-secure element?

- Shane

From: Nicholas Doty [mailto:npdoty@w3.org]
Sent: Thursday, July 26, 2012 7:04 PM
To: ifette@google.com
Cc: public-tracking@w3.org Group WG
Subject: Re: ACTION-201 (ISSUE-112)

On Jul 25, 2012, at 8:36 AM, Ian Fette (イアンフェッティ) wrote:

"How are sub-domains handled for site-specific exceptions?" - from a browser standpoint, I don't wish to further propagate the notion of "registry controlled domains" which is an unfortunate reality that we currently have with cookies, where browsers try to keep a list of what is a "public suffix" (contains multiple unrelated entities beneath it, such as .com). We have ~6,800 entries in there so far (http://mxr.mozilla.org/mozilla-central/source/netwerk/dns/effective_tld_names.dat?raw=1) - this is only getting worse now that ICANN has, in a rather questionable move (personal opinion), decided to make the top-level domain namespace a wild west.

So, I don't want to say "all subdomains" because we have no idea what that means.

Rather, I would prefer to say "A site can request a site-wide exception for its own origin and any other origins that it considers to also be in the same party, e.g. http://www.example.com<http://www.example.com/> could request a site-wide exception for http://www.example.com, https://www.example.com<https://www.example.com/>, https://example.com<https://example.com/>, https://mail.example.com<https://mail.example.com/>, https://www.example.de, http://www.example.de<http://www.example.de/>"

Sadly, I fear this is going to become nightmarish as sites add and delete origins over time ("Hey, now we're http://search.google!" or "Hey, we just launched example.az<http://example.az/>" or "newproduct.example.com<http://newproduct.example.com/>"). That said, I've got nothing better to offer...

I certainly agree this could get nightmarish. What if we indicate that as a semantic matter, an exception is requested for the effective script origin (a la [0]) and then note that user agents might provide users with the option to automatically extend/persist such permissions on other affiliated origins? We could note the use of the "same-party" field in the tracking status resource (or, for that matter, OUR-HOST [1]) and if browsers implement this technique, that would provide an incentive for sites to document their party relationships.

It sounds like there's agreement that exception requests should not extend to sub-domains, given the uncertainty over what a sub-domain implies.



[0] http://lists.w3.org/Archives/Public/public-tracking/2012Jul/0104.html

[1] http://www.w3.org/P3P/2004/03-domain-relationships.html

Received on Monday, 20 August 2012 17:15:44 UTC

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