RE: Issue 2: Use of the term "3rd-party"

Hey Nick,

Great point - thanks for bringing this up. We took a look at the "document origin" definition when drafting our original submission. I agree that it's a well-understood Web security concept, and it's really close to what we needed, but not quite.

>From a "List Author" (one who authors a TSL that blocks tracking content) point of view, we didn't really see a use case for writing rules against the scheme or port. More specifically, we don't know of any practical use cases where a TSL would allow content from http, but block content for https, or vice-versa. The reality is that domain names, and not schemes and ports, establish business relationships. By eliminating scheme/port, you get a cleaner list format that's easier to implement.

With regards to domain labels, the spec (as drafted today) and the Microsoft implementation both allow for flexible matching of allow/block rules across subdomain labels. However, what I think you're asking is if it's possible to block "first-party" URIs with the Microsoft implementation. The answer there is "no" - and the spec currently has text ("A user-agent must apply a selection list to third-party URIs only") that disallows this. There is an open thread/issue on this (see Issue 4, attached). Feedback welcome!

Thanks,

Andy

From: Nicholas Doty [mailto:npdoty@w3.org] 
Sent: Sunday, April 08, 2012 6:15 PM
To: Andy Zeigler
Cc: public-tracking-lists@w3.org
Subject: Re: Issue 2: Use of the term "3rd-party"

Is the key distinguishing factor that the "third-party" resources come from a different document origin?

"document origin" is defined by HTML5 [0] (and for URLs in particular in an RFC [1]) and refers to a tuple of host, scheme and port. It's a standard concept in Web security which might make it easier to understand, implement or use.

Does the Microsoft implementation also apply the lists to URIs with domains that are subdomains of the top-level document's origin?

-Nick

[0] http://dev.w3.org/html5/spec/single-page.html#origin-0
[1] http://tools.ietf.org/html/rfc6454

On Apr 6, 2012, at 6:06 PM, Andy Zeigler wrote:


"Issue 2: Third-party URIs might be confusing when reading along the two other Tracking Protection WG documents. The XLink definition doesn't help either. The third party is vaguely defined in the compliance document with A "third party" is any party, in a specific network interaction, that cannot infer with high probability that the user knowingly and intentionally communicated with it."

I agree that it would probably better to use a different term here, since we have a real technical definition for what we're trying to describe, which is: 

Currently:

- Any Internet URI that uses DNS has a second-level domain name (SLD), e.g. "example.com" or "example.co.uk".
- There is a topmost document, specified by a URI. This is commonly displayed in the Address/URL bar of user-agents.
- Any subsequent URIs requested by the topmost document also have an SLD.
- IF the SLDs of the topmost document and a particular subsequently requested URI differ, then the subsequent URI is currently "third-party"

Instead of "third-party", here are some other ideas:
	"Different Domain Name" 
	"Foreign URIs"
	"Foreign SLD"

Just a few ideas. Open to suggestion here.

Thanks,

Andy