Re: [whatwg/url] Define hosts' public suffix and registrable domain. (#391)

> Isn't detecting that kind of difference in platform restrictions a reason to add the API? Different browsers consider a different set of hosts to have different registrable domains over time: it seems reasonable to expose that to developers so they can make decisions about the environment in which their code is executing.

No, it's actually a reason for not exposing - that the platform does not provide any guarantees about that environment, and you shouldn't be relying on trying to detect the environment. If there is something you could do if you're not on the PSL (for example, using separate domains under a gTLD vs using separate 3LDs), you should do that regardless. Anything you could or would do if you're not on the PSL, you should do regardless. And anything you would or could do 'if' you're on the PSL is wrong. So it's sort of win/win - always treat it as if you're not on it, and you're fine :)

I know it's a fairly extreme position, but the PSL isn't something we can or should be relying on, especially as the Internet scales on. The notion of having a static list of every hosting provider, CMS, and otherwise user-generated content platforms, which the PSL is, is, well, a very 1980s solution :)

> Not writing it down seems worse. :) As long as cookies, document.domain, etc. depend on the notion, we need to explain it in a way that specs can rely on.

Except no one (on the author side) should be building systems that rely on it, and no new specs should be depending on it. To the extent writing it down gets to make explicit that this is a legacy aspect and any spec that references it has security flaws and should be redesigned before being implemented/shipped because of that, sure 👍 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/url/pull/391#issuecomment-392052927

Received on Friday, 25 May 2018 13:10:45 UTC