Public Suffix List/platform.sh Problem

From MozillaWiki
Jump to navigation Jump to search

This page explains the "platform.sh problem", named after the entry whose proposed inclusion triggered the discussion.

The rules which were requested (in bug 1124625) were: 

   // Already-existing
   sh
   ...
   // Newly-added
   *.platform.sh

Recall that the Public Suffix is the registry-controlled suffix, and the "registerable domain" is the Public Suffix + 1 additional label. (This wiki page does _not_ use the confusing notation from test_psl.txt, which has a function called checkPublicSuffix() which returns the registerable domain rather than the Public Suffix.) If we follow the defined PSL algorithm, the above rules should result in the following determinations: 

   get_public_suffix(foo.bar.platform.sh) == "bar.platform.sh"
   get_public_suffix(bar.platform.sh) == "bar.platform.sh"
   get_public_suffix(platform.sh) == "sh"
   get_public_suffix(sh) == "sh"

The problem is that Chrome (and possibly other implementations too) currently implements the algorithm differently, returning the following for case 3: 

   get_public_suffix(platform.sh) == "platform.sh"

and so it would (if it used a PSL with the above entries) refuse to let the website at http://platform.sh/ set any cookies. (Here we use cookie setting as a canonical example of PSL use.) This is because Chrome incorrectly assumes that a rule "*.platform.sh" means that "platform.sh" is also a public suffix, and it's not permitted to set cookies on a public suffix. This divergence in behaviour only occurs for precisely one name/site per instance of this "split rule" pair - platform.sh in this case.

The reason Chrome made this assumption, perhaps, is that there are other instances of this pattern in the PSL and in those instances, the assumption is arguably correct. For example: 

   jp
   *.kobe.jp

In this case, kobe.jp is arguably a public suffix, in the sense that it's registry-controlled. However, it's arguably not a public suffix in the sense that the public can't register names directly under it, as you might expect of a public suffix. There is no website there, and no need for it to set cookies, so that particular issue does not apply.

Question: why does Ryan think that the current Chrome behaviour for kobe.jp is correct? Is there perhaps a non-cookie example which shows the usefulness of the current Chrome behaviour more clearly? Is the problem that instead of checking for 'boundary-passing' when setting cookies, Chrome just checks for equality to any public suffix so, if it did not have the current behaviour, foo.bar.kobe.jp could erroneously set cookies for kobe.jp?

There is a Chrome bug on this behaviour. Chrome's current behaviour gets all existing implementations right, but would get platform.sh wrong. Changing Chrome's assumption to be the opposite would lead it to get platform.sh right, but kobe.jp and friends wrong. So one proposed idea is to fix the bug, and then explicitly add "kobe.jp" and friends to the PSL. That is proposed solution 1, below.

However, Firefox (and possibly other implementations too) has a different bug - bug 1163015. Firefox's internal data model uses a hash table which indexes public suffixes without taking account of the "*" or "!" characters. Therefore, it cannot distinguish the following two rules: 

   *.kobe.jp
   kobe.jp

So explicitly adding "kobe.jp" and its other equivalents to the Public Suffix List would make Firefox unable to properly read the PSL.

Further Information

It may be useful to note that the PSL algorithm has a "default rule" of "*", which is used when a more specific rule is not matched. So the Public Suffix of "foo.example" is "example", as "example" itself is not in the PSL.

However, some implementations do not behave consistently with this. Chrome, for example, when determining whether something the user types is a search or a domain name, will only think it's a domain name if the "TLD" of the thing-that-looks-like-a-domain-name is specifically in the PSL itself. Applying the "*" rule in this case would mean treating everything which was at least two words separated by a "." as a domain name, and they have chosen not to do that.

Proposed Solutions

1. Add the intermediate domains for the existing examples

  • Do not change the PSL algorithm
  • Fix implementations to distinguish between "*.foo.bar" and "foo.bar" everywhere
  • Add "*.platform.sh" to the PSL
  • Add "kobe.jp" and all its friends to the PSL

2. Change algorithm, and add a ! Rule for platform.sh

  • Update the PSL algorithm description to describe what some implementations have so far assumed - i.e. that "*.foo.bar" means that "foo.bar" is also a Public Suffix.
  • This gets the kobe.jp case right
  • Fix implementations to distinguish between "*.foo.bar" and "foo.bar" everywhere
  • Add "*.platform.sh" and "!platform.sh" to the PSL, to opt platform.sh itself out

3. Change algorithm, and tell platform.sh to change their practice

  • Update the PSL algorithm description to describe what implementations have so far assumed - i.e. that "*.foo.bar" means that "foo.bar" is also a Public Suffix.
  • Tell platform.sh that it's deeply unwise of them to give subdomains of their main website domain to their customers, and suggest that instead they offer subdomains of another domain (as Amazon does with amazonaws.com, and other cloud providers do), and that once they do that, we can add them.
Retrieved from "https://wiki.mozilla.org/index.php?title=Public_Suffix_List/platform.sh_Problem&oldid=1076979"