Summary: | document.cookie should not do a sync IPC to the network process for iframes that do not have storage access | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Chris Dumez <cdumez> | ||||||||||||||||
Component: | WebKit2 | Assignee: | Chris Dumez <cdumez> | ||||||||||||||||
Status: | RESOLVED FIXED | ||||||||||||||||||
Severity: | Normal | CC: | achristensen, beidson, berto, cgarcia, commit-queue, dbates, ews-watchlist, galpeter, ggaren, gustavo, japhet, webkit-bug-importer, wilander, youennf | ||||||||||||||||
Priority: | P2 | Keywords: | InRadar | ||||||||||||||||
Version: | WebKit Nightly Build | ||||||||||||||||||
Hardware: | Unspecified | ||||||||||||||||||
OS: | Unspecified | ||||||||||||||||||
Bug Depends on: | |||||||||||||||||||
Bug Blocks: | 206442 | ||||||||||||||||||
Attachments: |
|
Description
Chris Dumez
2020-01-10 16:26:55 PST
Created attachment 387397 [details]
WIP Patch
Created attachment 387535 [details]
WIP Patch
Created attachment 387567 [details]
WIP Patch
Created attachment 387593 [details]
WIP Patch
Almost ready.
Created attachment 387681 [details]
Patch
Created attachment 387684 [details]
Patch
Comment on attachment 387684 [details]
Patch
r=me
Comment on attachment 387684 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=387684&action=review Thanks for fixing the preferences read and the improvements to when blocking is done and to test async behavior. See inline comments. > Source/WebKit/ChangeLog:6 > + Reviewed by NOBODY (OOPS!). I thought we always described the change in both the WebCore and the WebKit change logs, at least when there are significant changes in both. > Source/WebKit/WebProcess/WebPage/WebCookieJar.cpp:65 > + return false; Does this match some existing behavior? > Source/WebKit/WebProcess/WebPage/WebCookieJar.cpp:69 > + return false; What does this imply? Can there be cookies for empty resource domains? > Source/WebKit/WebProcess/WebPage/WebCookieJar.cpp:108 > + if (!WebProcess::singleton().ensureNetworkProcessConnection().connection().sendSync(Messages::NetworkConnectionToWebProcess::CookiesForDOM(document.firstPartyForCookies(), sameSiteInfo(document), url, frameID, pageID, shouldIncludeSecureCookies(document, url), delegatesCookieBlockingToNetworkProcess ? ShouldApplyITPCookieBlockingPolicy::Yes : ShouldApplyITPCookieBlockingPolicy::No), Messages::NetworkConnectionToWebProcess::CookiesForDOM::Reply(cookieString, secureCookiesAccessed), 0)) Now that I see the use of ShouldApplyITPCookieBlockingPolicy, I think a more detailed enum is called for, such as { IsFirstParty, IsThirdPartyWithStorageAccess, IsThirdPartyWithoutStorageAccess, IsMissingPartyContext }, the last value being my attempt to encode the two cases with empty domains as commented on above. Then ITP in the network process can make an informed decision instead of being served a decision Apply policy Yes or No. Such an enum would also make sense in both places instead of this delegatesCookieBlockingToNetworkProcess boolean plus the Yes/No enum. Comment on attachment 387684 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=387684&action=review >> Source/WebKit/ChangeLog:6 >> + Reviewed by NOBODY (OOPS!). > > I thought we always described the change in both the WebCore and the WebKit change logs, at least when there are significant changes in both. Not sure what the policy is. I can add the changelog to both WebKit and WebCore. >> Source/WebKit/WebProcess/WebPage/WebCookieJar.cpp:65 >> + return false; > > Does this match some existing behavior? This logic is identical to what is used in NetworkStorageSession::shouldBlockCookies() on network process side. >> Source/WebKit/WebProcess/WebPage/WebCookieJar.cpp:69 >> + return false; > > What does this imply? Can there be cookies for empty resource domains? This logic is identical to what is used in NetworkStorageSession::shouldBlockCookies() on network process side. >> Source/WebKit/WebProcess/WebPage/WebCookieJar.cpp:108 >> + if (!WebProcess::singleton().ensureNetworkProcessConnection().connection().sendSync(Messages::NetworkConnectionToWebProcess::CookiesForDOM(document.firstPartyForCookies(), sameSiteInfo(document), url, frameID, pageID, shouldIncludeSecureCookies(document, url), delegatesCookieBlockingToNetworkProcess ? ShouldApplyITPCookieBlockingPolicy::Yes : ShouldApplyITPCookieBlockingPolicy::No), Messages::NetworkConnectionToWebProcess::CookiesForDOM::Reply(cookieString, secureCookiesAccessed), 0)) > > Now that I see the use of ShouldApplyITPCookieBlockingPolicy, I think a more detailed enum is called for, such as { IsFirstParty, IsThirdPartyWithStorageAccess, IsThirdPartyWithoutStorageAccess, IsMissingPartyContext }, the last value being my attempt to encode the two cases with empty domains as commented on above. Then ITP in the network process can make an informed decision instead of being served a decision Apply policy Yes or No. > > Such an enum would also make sense in both places instead of this delegatesCookieBlockingToNetworkProcess boolean plus the Yes/No enum. The logic for checking is the same on the network process and WebProcess side. A yes/no bit is thus enough to communicate to the network process that we already did the check. Created attachment 387730 [details]
Patch
Comment on attachment 387730 [details]
Patch
The shouldAskITPInNetworkProcess boolean and the ShouldAskITP enum are both good improvements. I assume you are waiting for EWS before you add cq+. Regardless, I'm OK for it to go on the queue.
The commit-queue encountered the following flaky tests while processing attachment 387730 [details]: editing/spelling/spellcheck-async-remove-frame.html bug 158401 (authors: morrita@google.com, rniwa@webkit.org, and tony@chromium.org) The commit-queue is continuing to process your patch. Comment on attachment 387730 [details] Patch Clearing flags on attachment: 387730 Committed r254556: <https://trac.webkit.org/changeset/254556> All reviewed patches have been landed. Closing bug. |