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

On Apr 9, 2012, at 4:33 AM, Andy Zeigler wrote:
> 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.

That's fair. I could hypothesize that perhaps some users are more comfortable with making requests (even tracking requests) over HTTPS because at least the body of the request won't be visible to others on the network, but that may be a narrow edge case.

> 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!

My question is more to the point of how a third-party URI is defined (maybe this is your Issue 4, apologies if I'm being repetitive). The current spec defines a third-party URI as one with a different second-level domain. This seems potentially underinclusive: 1) are all *.co.uk hosts first party to one another?, and 2) in cases either of DNS aliasing or shared hosting (foo.wordpress.com and bar.wordpress.com), are subdomains a good indicator of the same business relationship?

Thanks,
Nick

Received on Monday, 16 April 2012 04:18:48 UTC