Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Localhost port numbers #92

Open
Sora2455 opened this issue Oct 22, 2024 · 5 comments
Open

Localhost port numbers #92

Sora2455 opened this issue Oct 22, 2024 · 5 comments

Comments

@Sora2455
Copy link

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
Copy link
Member

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
Copy link

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
Copy link
Member

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
Copy link

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
Copy link

annevk commented Oct 23, 2024

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants