The wildcard is a little weird for an origin, and it's not a parseable URL. We would have to specialize the parser for it.
{
"id": "/",
"name": "Example",
"display": "standalone",
"start_url": "/index.html",
"scope_extensions": [
{"origin": "https://example.com", "treat_as_registrable_domain": true },
// but this could also parse OK too:
{"origin": "https://www.example.com", "treat_as_registrable_domain": true },
{"origin": "https://www.example.co.uk"},
]
}
This would allow only the www.example.co.uk part of example.co.uk, but allow ANY subdomain of example.com, as we treat the origin as a registrable domain.
Also, the spec already has a definition of registrable domain / eTLD+1, so we can parse that correctly. And we should likely require inclusion the https of the origin.
I'm in favour of this change. We should stick with standard URL parsing if possible as there are likely edge cases this simplified form fails to handle.
The wildcard is a little weird for an origin, and it's not a parseable URL. We would have to specialize the parser for it.
This would allow only the
www.example.co.uk
part of example.co.uk, but allow ANY subdomain of example.com, as we treat the origin as a registrable domain.Also, the spec already has a definition of registrable domain / eTLD+1, so we can parse that correctly. And we should likely require inclusion the https of the origin.