[webkit-changes] [WebKit/WebKit] 968887: Apple Music (MusicKit SDK) authentication fails wh...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 9688876df5251f65fa50e173ff27fb365c99cb76
      https://github.com/WebKit/WebKit/commit/9688876df5251f65fa50e173ff27fb365c99cb76
  Author: Wenson Hsieh <wenson_hsieh at apple.com>
  Date:   2025-01-10 (Fri, 10 Jan 2025)

  Changed paths:
    M Source/WebCore/dom/Document.cpp
    M Source/WebCore/dom/ScriptExecutionContext.cpp
    M Source/WebCore/dom/ScriptExecutionContext.h
    M Source/WebCore/page/LocalDOMWindow.cpp
    M Source/WebCore/page/Page.h
    M Tools/TestWebKitAPI/Tests/WebKit/AdvancedPrivacyProtections.mm

  Log Message:
  -----------
  Apple Music (MusicKit SDK) authentication fails when Advanced Privacy Protections are enabled
https://bugs.webkit.org/show_bug.cgi?id=285715
rdar://124643257

Reviewed by Abrar Rahman Protyasha and Charlie Wolfe.

MusicKit.js currently fails to authenticate users in Private Browsing mode in Safari, when Advanced
Privacy Protections are enabled. This is because MusicKit uses `document.referrer` in the popup
window that handles authentication to sanity check the opener's identity; since opening this cross-
origin popup window qualifies as a cross-site navigation, we hide `document.referrer` from bindings,
which causes this auth flow to fail.

To fix this, we adjust this protection by allowing the page to read `document.referrer`, only in the
scenario where:

- The document where script is attempting to read the referrer has an opener.
- The domain of the script that opened the document matches the security origin of this document.

Because the script responsible for opening the new window has the same origin as the opened window,
the script could have already simply sent the `document.referrer` to the opened window through
`postMessage` anyways, so hiding `document.referrer` in this scenario doesn't yield any privacy win
and instead only risks breakage.

* Source/WebCore/dom/Document.cpp:
(WebCore::Document::referrerForBindings):

Adjust the check for whether we should hide referrer, so that we avoid hiding it for popups in some
cases. See above for more details.

* Source/WebCore/dom/ScriptExecutionContext.cpp:
(WebCore::ScriptExecutionContext::currentSourceURL const):

Add an option here to return the topmost (i.e. immediate) source origin URL in the call stack,
rather than the bottommost. We use this below to attribute the opening of a window to a script
source origin.

* Source/WebCore/dom/ScriptExecutionContext.h:
* Source/WebCore/page/LocalDOMWindow.cpp:
(WebCore::LocalDOMWindow::createWindow):

Use `currentSourceURL` with the new flag (see above) to compute the domain of the script running in
the opener, that created this new window.

* Source/WebCore/page/Page.h:
(WebCore::Page::openedByScriptDomain const):
(WebCore::Page::setOpenedByScriptDomain):

Add new getter/setters for `m_openedByScriptDomain`, which tracks the domain of the script that
programmatically opened this frame (e.g. using `window.open()`).

* Tools/TestWebKitAPI/Tests/WebKit/AdvancedPrivacyProtections.mm:
(TestWebKitAPI::TEST(AdvancedPrivacyProtections, DoNotHideReferrerInPopupWindow)):

Add a new API test to exercise this fix.

(TestWebKitAPI::TEST(AdvancedPrivacyProtections, Canvas2DQuirks)):

Drive-by fix: remove an unnecessary `using namespace`.
Canonical link: https://commits.webkit.org/288708@main



To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications