1128673 - Deal with brand TLDs appropriately in the PSL

Status: RESOLVED WONTFIX

(Core Graveyard :: Networking: Domain Lists, defect)

Description

[Peter Bowen]

ICANN has defined a new kind of a TLD, a ".brand TLD" (http://newgtlds.icann.org/en/applicants/agb/base-agreement-spec-13-proposed-06dec13-en.pdf)

These TLDs are different from most existing TLDs as all subdomains are controlled by a single entity.  So the public suffix for these TLDs is really "."

Additionally, I think there is a solid argument that "mil" should be retroactively considered a brand TLD.  It is exclusively used by the US Department of Defense, which is a single entity inside of the US federal government.  It would probably be .mil.fed.us (or .mil.us) if they didn't have the grandfathered TLD.  The PSL should reflect suffixes which are private all the way to the TLD.

Comment 1

[Ryan Sleevi]

(In reply to Peter Bowen from comment #0)
> The PSL should reflect suffixes which are private all the way to the TLD.

I would disagree with this assertion, in as much as the PSL reflects domain boundaries. Consider .us has, within the PSL, multiple sub-levels to reflect organizational separation. Or, similarly, a variety of the CC TLDs.

As it relates to the broader question of .brand TLDs, this is really on a case-by-case basis. A large multi-national may wish to have the PSL reflect the administrative / scope of authoritity boundaries that it has declared. For example, foo.brand might be operated by the Foo subdivision of .brand, and would itself be a legally different entity than bar.brand, and similarly be operated under different cookie scoping.

That ICANN has decided it wishes to sell more TLDs without consideration of the impact is certainly a decision ICANN can make, but we can infer nothing from their (effectively) marketing material on how it materially shapes the contents of the PSL.

Comment 2

[Peter Bowen]

I agree that not all "brand TLDs" will be private all the way to the TLD, but some might be.  As far as I can tell, the PSL has no way to describe any such TLD.  It always assumes something longer than "." is the public suffix.

Should it have defined syntax so when .suzuki or .ibm says they want to set cookies at that level or want a *.suzuki certificate, it can be handled?

Comment 3

[Jothan Frakes]

@peter Could you help us out - would like more clarity from you on precisely what you are asking for.  

For example are you saying some special behavior needs to happen for .brand TLDs?  Does this relate to cookies, certificates, DOM, or perhaps some other derivative use like search engine or anti-spam?  Or is this simply that you'd be requesting that the PSL include some indicia of a TLD being a .brand?

In reading through this request, it appears that there might be a misunderstanding of the PSL.

I am inclined to agree with Ryan's comment about this being case by case.  I have spoken with the Brand Registry Group during the Los Angeles ICANN meeting and now personally know many of the brands and the administrators of these spaces.  From what has been shared with me about plans for their TLD namespace(s), they really vary widely.  To assert that they are all alike might cause solutions to problems that create other problems.


I disagree with the following 2 statements:

>These TLDs are different from most existing TLDs as 
>all subdomains are controlled by a single entity.  

True in some cases and not in others, as Ryan commented.  Horses for courses.  The status quo

>So the public suffix for these TLDs is really "."

Always false.   PS for these would be <TLD> (ie .COM-esque flat zones).  

This happens by default with the PSL getting updates fairly frequently as ICANN announces contract signing with the TLD registry operator, per TLD, in batches.

For all intents and purposes, the default behavior with respect to PSL is that each is a flat namespace underneath the TLD.  An authorized representative of the registry or their registry service provider can request something which diverges from that.  For sub-domains to have distinct or shared cookie realms should be completely the discretion of that TLD (for example, distinct at <domain>.<affiliate>.<brand>, across .<division>.<brand> or .<country>.<brand> each or all sharing at .<brand>) should be designated by the respective registry. 

It might help to review some of the diversity currently present across many of the ccTLDs in the PSL and then identify what specific problem needs to be solved per TLD by the registry administrator, and let them request them.

Again, if you could share some insight into exactly what is being asked, it would help know what problem to solve.

Comment 4

[Peter Bowen]

(In reply to Jothan Frakes from comment #3)
> For all intents and purposes, the default behavior with respect to PSL is
> that each is a flat namespace underneath the TLD.  An authorized
> representative of the registry or their registry service provider can
> request something which diverges from that.  For sub-domains to have
> distinct or shared cookie realms should be completely the discretion of that
> TLD (for example, distinct at <domain>.<affiliate>.<brand>, across
> .<division>.<brand> or .<country>.<brand> each or all sharing at .<brand>)
> should be designated by the respective registry. 

Today there is no way for a TLD to have a shared cookie realm across the whole TLD when using the PSL.  The PSL makes an assumption that <something>.<tld> is the minimum cookie realm.  

I'm expecting that at least one TLD will, in the not too distant future, request the "all sharing at .<tld>" option.  Due to the number of users of the PSL and the number of libraries for parsing and processing it, the syntax to support such a request should established well before the request arrives.

Comment 5

[Ryan Sleevi]

If wishes were horses...

To the extent it influences the conversation one way or the other, Chrome has no plans to support "All sharing at the .<TLD>" level, and have shared that feedback. This is part of what I meant by brand-TLDs being marketing fluff.

Now, it may still serve some applications to know the distinction, so I am not intrinsically opposed to putting it in the PSL. But for the most common case - cookies - we will NOT be supporting and are not supportive of.

Comment 6

[Jothan Frakes]

>Today there is no way for a TLD to have a shared cookie realm 
>across the whole TLD when using the PSL.  The PSL makes an 
>assumption that <something>.<tld> is the minimum cookie realm. 

This is more clear what the request might be seeking specifically.  

I'll be more diplomatic about this, but it seems like this is not really something for PSL volunteers to solve, but rather something for those registries seeking it to pursue, as it is not solved by adding a line (or even a syntax to a line) in the PSL.  

It appears that part of the request would be to create an option to 'opt out' of the privacy protection and allow cross-TLD cookies.  But also that the behavior would be desired in other realms as well (such as certificate wildcards, DOM realms potentially, etc.) based upon this new opt out concept.

If one wanted to go this route, just tossing it over the fence to the PSL volunteers to sort it may significantly trivialize the extent of change and individual campaigns that are going to be needed (level of effort and time) just in convincing people of the required changes and getting support for it, THEN potentially making those changes.

This request is less of a PSL request and should be directed at Mozilla Security and would need to get kicked up to the security realm for discussion - and that in of itself is specific to the Firefox browser.   

I suspect in this journey
a] there will be some entrenched (and perhaps visceral) resistance to this type of change in an era of adding and reinforcing security and personal privacy, and 
b] that dialog will be per browser - that the PSL is not a one-stop shop for such a change.
b2] If you read https://publicsuffix.org/learn/ you will see that there are a number of other uses for the PSL that have evolved over time - I also suspect that each of these would require additional outreach beyond just browsers.

In any case, the request, while potentially prescient about TLD behavior, is unfortunately not really actionable by the PSL volunteers by my read.

I'll allow Gerv to weigh in with respect to what might be an appropriate course, if any with respect to Firefox.

Comment 7

[Jothan Frakes]

@Gerv please take a look at this - trying to determine next steps on this request

Comment 8

[Gervase Markham [:gerv]]

ICANN has forbidden A records at the top level, so no-one can do "http://brandname" on the public internet. However, if they were to do http://www.brandname and http://www2.brandname and want them to e.g. share cookies, that doesn't sound like a totally unreasonable request. Of course, if Chrome (or any other browser with significant market share) decides not to support it, then it won't happen whatever the PSL says.

If we were to do this, and I'm not saying yet that we should, then it would be on an opt-in basis from the TLD owner.

If we were to do this, and I'm not saying yet that we should, then I think the correct syntax would be an entry of the following form:

!brandname

Just as
*.xx
!foo.xx

says that normally people register myname.co.xx or myname.org.xx, but for foo.xx that's not true, the public suffix of foo.xx is "xx", then saying !brandname would say that brandname was an exception to the implied rule that all unlisted suffixes are treated like a one-name entry; this should be treated like a "zero-name" entry.

Gerv

Comment 9

[Gervase Markham [:gerv]]

Ryan: what say you to comment 8? Does your earlier comment suggest that you are unwilling, in Chrome, to allow www.amazon and www2.amazon to share cookies?

Gerv

Comment 10

[Ryan Sleevi]

Gerv: I think on principle, we're opposed, but not unwilling.

The concern of course is that the failure model for applications that don't keep the PSL updated, for these domains, would be to "fail closed" (e.g. restricting cookies), rather than the current model with PSL updates, in which a solution "fails open" (e.g. allows cookie sharing between foo.example.com and bar.example.com)

Not that I'm wanting to claim that the security properties of failing open are better, just that it introduces a larger dynamic into the PSL update cycle, and I'm not sure we're wanting to encourage that.

Comment 11

[Gervase Markham [:gerv]]

Yes, that's a good point - although I'd note that Chrome's use of the PSL in the Omnibox to detect what's a search and what's  TLD already "fails closed", in that if ".bar" is not in Chrome's PSL but is in the DNS, typing "foo.bar" in the Omnibox still does a search. Right?

I guess a .brand TLD which wanted to use www.brand as their front page and still share cookies with other subdomains could use foo.www.brand (and bar.www.brand and so on), right? It looks a bit weird, but it would work.

I'm sure you can't reveal exactly what Google's plans are for .google beyond the amusing "com.google", but I would expect Google to want to share cookies across the entire TLD space. Have you had an internal discussion and decided that this is not, in fact, necessary?

Gerv

Comment 12

[Ryan Sleevi]

(In reply to Gervase Markham [:gerv] from comment #11)
> Yes, that's a good point - although I'd note that Chrome's use of the PSL in
> the Omnibox to detect what's a search and what's  TLD already "fails
> closed", in that if ".bar" is not in Chrome's PSL but is in the DNS, typing
> "foo.bar" in the Omnibox still does a search. Right?

Not always :) I forget all the exact heuristics, other than noting "not always" for things that are DNS-y shaped.

> I guess a .brand TLD which wanted to use www.brand as their front page and
> still share cookies with other subdomains could use foo.www.brand (and
> bar.www.brand and so on), right? It looks a bit weird, but it would work.

Right. It does mean that shop.brand and visit.brand and explore.brand couldn't share cookies between them.

> I'm sure you can't reveal exactly what Google's plans are for .google beyond
> the amusing "com.google", but I would expect Google to want to share cookies
> across the entire TLD space. 

Why would you expect that? 

> Have you had an internal discussion and decided that this is not, in fact, necessary?

There are always lots of internal discussions, especially for a company the size of Google. Sometimes left-hand and right-hand don't always know what they're doing, and sometimes disagree because of different priorities.

Yes, there have been talks about supporting .brands as special. However, as implemented in Chrome, that would bring with it a variety of risks in implementation, and so we have no plans at present to support them. I don't even remember all the bugs filed, but I think as it stands, it's not something high on the priority list to tease out all of the security assumptions that may break (and it extends beyond cookies)

Comment 13

[Jothan Frakes]

For what appears to be a good healthy dialog on chrome and firefox cookie / PSL stuff, this discussion is good to throw out there about conceptual implementation - and I'd like to throw some concepts in.

The .brand TLDs are mixed needs, and not all of them know what they want to do, or have a very healthy 'don't know what they don't know' going on with respect to their plans for their TLD.  There are .brand TLDs who will want the ability to share cookies across their SLD, and some that will not.  Many are still thinking.  

If there were a means to allow a .brand to behave such that shop.brand and visit.brand would be share-able cookie realms within .brand, that behavior seems like it is exactly what the PSL was created to avoid - so introducing exception functionality would best be done with care.

In listening to the diversity of applicant use cases that exist, there are some other potential things to consider as use cases we'll be hearing.

There is a use case that might also be across 'equivalent' TLDs - where second or lower names might have something akin to each other.  DBOUND IETF work is looking at this.  

In the context of brand, though, this would be like user.google and user.gmail sharing cookies.  I recognize effective aliases might be 'out on the periphery' if even touching the concept of top level cookies discussion, but it might be worth considering this while in under the cookie hood doing some engine work.  

This next part gets a little further astray, but importantcause.ong and importantcause.ngo might need equivalency of second level space.

The practical value of these with the general use case beyond .brand registries (and perhaps this is best located in a different ticket) are where there are TLDs that Public Interest Registry (PIR), Afilias, and VeriSign applied for in the recent round which are localized versions of ORG, INFO, or COM in different languages that the registries are looking at ways to offer equivalency in.  PIR in particular has .ONG and .NGO as well that might have a similar user benefit in some equivilence mapping.

Comment 14

[Gervase Markham [:gerv]]

(In reply to Ryan Sleevi from comment #12)
> > I'm sure you can't reveal exactly what Google's plans are for .google beyond
> > the amusing "com.google", but I would expect Google to want to share cookies
> > across the entire TLD space. 
> 
> Why would you expect that? 

I guess because I assumed Google uses cross-google.com cookies to keep track of users logged into their Google accounts who are using different Google services, and that if Google were going to make use of .google, they would do the same. 

Jothan: I think most of the sharing use cases you mention are out of scope for the PSL. IF dbound wants to define a mechanism to enable importantcause.org and importantcause.ngo to share cookies, good luck to them :-)

It seems, then, that the status quo should be kept for now - just keep adding them to the list as they get delegated.

Gerv