1884648 - Partitioned cookies are not included in document.cookie

Status: RESOLVED DUPLICATE of bug 1874174

(Core :: Networking: Cookies, defect, P2)

Description

[Jarda Snajdr [:jsnajdr]]

Steps to reproduce:

1. Load a site like service.com as top-level document.
2. The service.com page embeds a cross-origin iframe, <iframe src="https://widget.com">
3. The widget.com response has a Set-Cookie: widget_cookie=value; Secure; Partitioned header.
4. When a script in the widget.com document issues a same-origin fetch request, the widget_cookie is included in that request. That's an evidence that the cookie was not somehow malformed and that it was correctly stored in the partitioned storage for the service.com/widget.com pair.
5. However, when a script in the widget.com document calls document.cookie, the returned string is empty. The expected result is that it contains the widget_cookie=value string.

This behavior would be correct only if the widget_cookie had the httponly attribute, but it doesn't.

In console there is an expected message:

Partitioned cookie or storage access was provided to “https://widget.com” because it is loaded in the third-party context and dynamic state partitioning is enabled.

In Chrome the same steps lead to the expected result, i.e., document.cookie === 'widget_cookie=value'.

I'm using the latest Firefox Nightly 125.0a1 (2024-03-10) (64-bit)

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

FYI ed, perhaps you know something about this

Comment 2

[edgul]

I believe this will be fixed once Bug 1874174 has been implemented.

Comment 3

[edgul]

While the implementation mentioned in comment 2 was finished, we still have CHIPS and optInPartitioning preffed off.
As currently written (and this code is kind of in flux), I wouldn't expect to see this kind of cookie on the content process until we enable optInPartitioning. https://searchfox.org/mozilla-central/source/netwerk/cookie/CookieService.cpp#1164-1166

Tim, the order of rollout of chips and optInPartitioning pref flips is unclear to me. Will both be enabled at the same time?
If chips is enabled first (without optInpartitioning) then it seems like we might have a problem with getting Partitioned cookies into the content process.

Comment 4

[Tim Huang[:timhuang]]

The CHIPS pref will be enabled first without the optInPartitioning pref enabled.

I think the partitioned cookies will still be sent to the content processes. The check you linked here is to stop sending non-CHIPS partitioned cookies to content processes if optInPartitioning is enabled.

Comment 5

[Jarda Snajdr [:jsnajdr]]

As the reporter, I can confirm that document.cookie and Partitioned have been working correctly in recent Nightly builds.

However, for the past two weeks, I've been experiencing very frequent Nightly crashes. I only know that:

• they were happening mostly on our wordpress.com sites, which heavily use nested iframes with 3rd party cookies
• the crashes stopped when I disabled the optInPartitioning pref

I was unable to figure out anything else about the crashes, not even the C++ call stacks. But I submitted a lot of reports with the crash reporter.

In the last two or three Nightly builds these crashes no longer happen, so something apparently got fixed.

Does this sound familiar to anyone involved in the CHIPS part of the codebase?

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to Jarda Snajdr [:jsnajdr] from comment #5)

I was unable to figure out anything else about the crashes, not even the C++ call stacks. But I submitted a lot of reports with the crash reporter.

Thanks a lot for submission! Would you mind to check about:crashes and give us one or more of these crashreporter URLs so that we can take a look?

Comment 7

[Jarda Snajdr [:jsnajdr]]

Nice, I didn't know about about:crashes :) Here are the last three ones:

bp-f7c0f5a9-46fd-4305-8e66-0e8830240522
bp-3e7b3b4d-71e9-46b1-85a3-3cbf50240522
bp-495b36b2-ba94-4b1e-8ed5-c56760240522

And they are really all about cookies:

nsTArray_Impl<T>::AppendElementsInternal<T> | nsTArray<T>::AppendElement | mozilla::net::CookieServiceParent::SerializeCookieListTable 

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I checked and there is no such crash filed yet. Would you mind filing a new bug? You can do that easily by opening https://crash-stats.mozilla.org/report/index/f7c0f5a9-46fd-4305-8e66-0e8830240522#tab-bugzilla and click on Core. Then all details will be automatically filled in and maybe you can add some additional information. Please let us then know about the bug number. Thanks!

Comment 9

[Jarda Snajdr [:jsnajdr]]

Submitted as bug 1898700.

Comment 10

[edgul]

As the reporter, I can confirm that document.cookie and Partitioned have been working correctly in recent Nightly builds.

Awesome, thanks. Closing