fiala@ - Thanks for filing the issue...!!

Could you please provide a sample test file to test the issue from TE-end.
If possible please provide a sample screen cast or screenshot of issue.
This will help us in triaging the issue further.

Thanks...!!

Hi,

Please see: https://jsfiddle.net/davidfiala/6dcsho4w/1/

Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I tried in Safari 10.1, Firefox 56, and Edge 16. None of them show a foo cookie using the jsfiddle steps either.

document.cookie returns the "cookie-string for the document's URL"
https://html.spec.whatwg.org/multipage/dom.html#dom-document-cookie

And document.pushState() changes the document's URL:
https://html.spec.whatwg.org/multipage/history.html#dom-history-replacestate

... so the reporter's intuition that the reported cookies would change is reasonable.

On the other hand, knowing how browsers are implemented, I'd be surprised if this behaved that way. :) Similarly, I would not expect the controlling Service Worker to change if the document's URL is modified.

bsittler@, mkwst@ - any idea if this behavior is specified anywhere? File a bug against HTML?

I don't know about standardization, but I certainly wouldn't want us to change this behavior without careful thought. I certainly would not expect pushState to change the view of the cookie jar, no more than I would expect setting document.domain to do so.

mkwst@: Assigning to you for security expertise. Please assign back to me if you'd like us (OWP Storage) to track & implement the resolution, once we have it.

Intuitively, I agree with #6 -- being able to get cookies for different directories via pushState seems to defeat the point of scoping. On the flip side, given that no other storage APIs I'm aware of has path scoping (the principal is the origin), I could accept the perspective that paths are only used as a query filter (on the cookie store), and don't provide any security guarantees.

Which perspective is right?

I agree with the existing behavior in browsers. Conceptually, I don't think `pushState` _really_ change the document's URL. It just pretends to. The comparison to `document.domain` is apt.

+Anne for a perspective from HTML, perhaps he disagrees with me?

I think the HTML Standard needs to define something like "cookie URL" (also to make about:blank and such clearer); there's an open issue somewhere. We wouldn't update the "cookie URL" for pushState(). (Currently cookies have all kinds of issues, see https://github.com/whatwg/html/labels/topic%3A%20cookie.)

I filed https://github.com/whatwg/html/issues/3274 to track the spec change. It seems like we won't be changing our behavior, so I'm closing this bug.

I'll be watch the spec issue, but please don't hesitate to file a bug should we need to change our implementation.