Localhost port numbers

[Sora2455]

From what I can see, the specification doesn't mention localhost or port numbers anywhere, relying on the existing cookie specifications to handle this.

My understanding is that normally, otherwise-identical URLs are treated as different domains... except on localhost, where they are treated as the same domain by default. (For the purpose of setting and receiving cookies).

So if a cookie is set for localhost:1142, it will also be received by a server running at localhost:1141, even if it doesn't set the Domain attribute.

In Chrome, this happens even if the cookie is partitioned. In Firefox, however, the partitioning uses the port number, which means that partitioned cookies cannot be shared between localhost domains. Even though the equivalent non-localhost domains could share the same partitioned cookies using the Domain attribute.

While I personally find Chrome's behaviour here preferable to Firefox's, could this issue be addressed in the spec directly, so that there isn't two different behaviours here?

[johannhof]

That sounds like a bug in Firefox given that the spec says it's supposed to be partitioned by site.

@bvandersloot-mozilla any thoughts? A bit surprising that Firefox's partitioning would consider the port, sounds like this is something we should align on more broadly for partition keys?

cc @DCtheTall @annevk

[martinthomson]

This seems like an improvement to me, even if it isn't in the spec. There are no guarantees that two ports on the local machine are the same entity, so keeping cookies separate is probably a good idea. To some extent, we're relying on that fact that the OS is limiting what ports a given program can access, but this is probably wise. Consider something operating on a privileged port (<1024 on systems where that matters), would you want cookies that were sent to that being sent to $random-program running on an unprivileged port?

Now, I'm not saying that this is entirely defensible in terms of being a rigorous design, but there is at least a credible argument for why this is an improvement.

[johannhof]

Yeah I agree it seems reasonable to separate by port. I guess we already missed that train for cookies though? That's from the spec at least, I haven't looked at what browsers do in practice...

[bvandersloot-mozilla]

We missed that train in the context of cookies without the Partitioned attribute. No reason that cookie partitioning can't consider this as well.

A bit surprising that Firefox's partitioning would consider the port, sounds like this is something we should align on more broadly for partition keys

Agreed!

[annevk]

Wouldn't it be confusing that partitioned cookies work differently from non-partitioned cookies? I would expect web developers to only hit this in certain edge cases and I could see them being annoyed with us making non-443 ports even more useless than they already were.

Having said that, https://github.com/privacycg/storage-partitioning/ does allow for additional keys and there's a hope to eventually align on them. So I suppose the port might as well be one of those tentative keys.

I guess the other question is to what extent "site" in general could be moved to be inclusive of ports and to what extent that effort is worth the squeeze. My initial take is that this is probably not worth pursuing even though historically there was some push to get this done, but maybe?

[Sora2455]

Some context as to why I'm interested in getting this resolved:

I work on a website that has two major subdomains. These two subdomains share session state between themselves by setting the Domain attribute on the cookie. On localhost this isn't necessary - besides, setting Domain to 'localhost' has no effect.

Our site is sometimes - not usually, but sometimes - run as an embedded iFrame in a third-party context. To avoid complex logic around what attributes to set on the session cookie when, we always set the SameSite=None and Partitioned attributes on our session cookie (we're not interested in sharing state between embedded and non-embedded contexts, just between those two subdomains).

On Chrome, this works without any issues. On Firefox, because of the partitioning using the port number, the session sharing between the two "subdomains" on localhost (represented as two different port numbers) is broken when the session cookie is Partitioned.

At the moment I'm set not setting the Partitioned attribute on localhost when I UA-sniff Firefox. But this means that, going forward, I won't be able to test embedded contexts in Firefox on localhost, as non-partitioned cookies are blocked when strict security settings are used.

[martinthomson]

It might help to separate this into two:

1. The bug. It seems like Firefox is doing something off-spec.
2. The spec. We should resolve whether the spec could be improved with respect to localhost (which is already a special case - and therefore a complete mess - as far as many security-related things are concerned).

That is, this discussion probably needs to move two places: bugzilla.mozilla.org for the first, whatwg/html for the latter. I don't think that CHIPS really has much play in either.

[Sora2455]

That is, this discussion probably needs to move two places: bugzilla.mozilla.org for the first, whatwg/html for the latter. I don't think that CHIPS really has much play in either.

I lodged this as a Firefox bug before opening this issue. The bug was closed as expected behaviour on Firefox's part, and the spec is ambiguous enough to allow both Chrome and Firefox's behaviours. That's why I then opened this issue, trying to see if one or the other behaviours could be specified directly.