Re: [whatwg/url] Feature proposal: eTLD+1 web API (#528)

> To answer that question, I could go manually look through the current public WebPageTest list and then for completeness go look through all of the changelog to see whether it might've possibly changed between the browser build they are using and the current version. That's super-cumbersome.

But exposing a Web API here doesn't change that, which is the point. The fact that there are significantly different cadences and release cycles means that any answer to that question is contingent upon browser and version and may change.

That is, if you had an API, you'd still have to test in every browser you care about to see if you got the answer you wanted.

Worse, if the website was not happy with the answer, and wanted to change the PSL, they're still going to have to deal with all of that. And none of it may affect other users and clients (e.g. system web views, command-line clients and tools, libraries that interact with the browser cookie store on mobile devices, etc)

That's why I think it's a bit of a false equivalence; a Web API could make this marginally easier, but that margin is within the noise threshold of an already overly complex space, and so that saving doesn't amount to much, but makes it even harder to reign that in.

> Another possible use case (which I suspect you might not be happy about) is the best practice documented in [Guidelines for URLDisplay](https://chromium.googlesource.com/chromium/src/+/master/docs/security/url_display_guidelines/url_display_guidelines.md#:~:text=%20Guidelines%20for%20URL%20Display%20%201%20Background.,make%20one...%204%20Further%20Reading.%20%20More%20), which calls for ensuring that the Registrable Domain portion of a URL is always visible. For a web application to implement that Best Practice requires knowing the registrable domain.

Yes, you're right that I think implementing something like Google Search's AMP URL Bar would be actively detrimental to the Web Platform ;) I'm not necessarily sure that primitives and design space specific to a browser trusted UI surface necessarily generalize onto other surfaces, especially web content controlled. This is where a more complete use case would be useful to evaluate, because I don't know that we can or should try to generalize those principles to all display surfaces.

Further, that display also doesn't require a Web API, because it's not fundamentally necessary to keep it in lock-step with a given UA. For that, we can see there are already viable alternatives: If you want to do it in client side, you can ship a public suffix list you control, or you can do it server side.

I realize these are highlighting existing alternatives, and that's perhaps dissatisfying, but this is why it's important to figure out why does it matter what a particular UA is using. At best, it creates another area for API surfaces to drift between UAs and provide different experiences. While this is fundamental to the use of a PSL, it's part of why moving away from the PSL is so fundamentally important. Hence, my concern about adding new dependencies, especially dependencies that, once Web exposed, become part of a mostly-unbreakable API contract, for something we know is fundamentally flawed and irredeemable.


-- 
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/issues/528#issuecomment-676504833