@hober please can we get this added to the agenda to discuss at the next privacy-cg?

Why would this cause scoping issues? A subdomain would not be able to set the domain attribute to this domain (as it's a public suffix) and this domain would be considered cross-site with any subdomain as per https://html.spec.whatwg.org/#site (and also the equivalent definition in the cookie RFC that will eventually depend on this).

I'm pretty sure this is accounted for, though there is currently an issue with the definition of document.domain (but that's a specification-only regression).

I don't think we should discuss this unless someone can pinpoint an actual problem in the various specifications.

This is quite hard to actually test without owning a long-term entered PSL domain, so I'd still like to have a conversation in a group with attendees from each browser to understand how they interpret the logic.

The scenario I'm thinking of is the inverse; the parent domain setting a cookie that would be valid on all of the subdomains:

1. When a user visits e.g. gov.au, a cookie is set with parameters "domain=.gov.au"
2. Subdomains of gov.au all treated as their own eTLD+1s by the browser due to PSL listing.
3. Cookie from step 1 is present on all subdomains, creating a tracking vector

Spec-wise, I agree this is strictly a cross-site scenario, but I think we need to understand what the implementation actually is

If you did .gov.au that would not domain match. If you did gov.au it would act as if the domain attribute was the empty string. https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis#section-5.4 details this.

I guess what I'm saying is that unless there is something more concrete I'm not sure how a discussion will help.

You're right - I realised I could play around with document.cookie on gov.au. Domain matching will prevent a .gov.au cookie domain being set.

@johnwilander was this the main issue you were considering or was there another scenario?

I’m mostly thinking about partitioning (which is why I suggested the issue be filed here). What is the partition for subresources on an eTLD “site?”

See the link to the HTML Standard above. For https://gov.au/ it would be (https, gov.au). For https://subdomain.gov.au/ it would be (https, subdomain.gov.au).

Doesn’t that make eTLDs not be like TLDs? A much cleaner model is to not allow loads from eTLDs.

That's why we don't call them eTLDs. :-)

I do not expect it's possible to make changes here at this point, but I also have yet to see a problematic case.

Doesn’t that make eTLDs not be like TLDs?

How so? Real TLDs can have navigable A/AAAA DNS records as well. e.g. http://ai/

Are folks still interested in discussing this at the F2F?

From my perspective the main concerns I had around cookie security are resolved.

I still think there's value in understanding how each browser treats and uses the PSL because it does seem there are inconsistencies in expectations here, which are important to understand given the number of privacy proposals that rely on eTLD+1 + PSL.

Perhaps this isn't a broad F2F topic but something that may be better suited to a breakout with representatives from each browser vendor

Not me. Largely resolved.

Ok, lets agenda- this one and revisit as part of a broader conversation later in the year when I'll invite the PSL maintainers to come speak at a privacy-CG about some of the implications of using eTLD+1/PSL as the basis for the current range of privacy preserving proposals.

Ok, lets agenda- this one and revisit as part of a broader conversation later in the year when I'll invite the PSL maintainers to come speak at a privacy-CG about some of the implications of using eTLD+1/PSL as the basis for the current range of privacy preserving proposals.

We'll just accumulate wontfix for PRs until then. Who's cel can we give the mob?

Once the FB intake process is created, I'd advise we mop up all existing PSL requests related to iOS 14.5 and send them there. I've commented separately on privacycg/private-click-measurement#78 - this cannot be something we just leave bubbling away with the upcoming slew of privacy preserving proposals that rely on PSL

I can see the problem with PCM and PSL, but I don't see the problem with storage partitioning or other privacy proposals. Is there a reason to keep this issue open? OP was based on a misunderstanding and the last couple of comments are about something else entirely.

We're tracking this on privacycg/private-click-measurement#78. I'll close out this issue