WebPageProxy::receivedPolicyDecision() and receivedNavigationResponsePolicyDecision() run in the UIProcess and, when the policy action is PolicyAction::Download, construct a DownloadProxy via ProcessPool::createDownloadProxy(). The last argument to that call is the originating frame info, which becomes the download’s originatingFrame / associated origin exposed to the client (e.g. WKDownload.originatingFrame). Before the patch, both paths unconditionally passed navigation->originatingFrameInfo() (or the navigationAction’s originatingFrameInfoData) as the originating frame. The invariant being violated is that a download’s originating frame/origin should reflect the actual frame that initiated the resource load, and only when that association is meaningful. For navigations that are back/forward list traversals (navigation->targetItem() is set) or that came from client/user input rather than from web content (navigation->isRequestFromClientOrUserInput()), there is no legitimate web-content frame origin to attribute the download to — yet the old code still stamped the download with the previous/opener frame’s originatingFrameInfo, incorrectly associating the download with an origin (e.g. the prior page’s host) that did not actually initiate it.

The fix adds a condition: when navigation exists and it is either a targetItem (go-back/forward) navigation or a client/user-input-initiated request, the download proxy is created with std::nullopt for the originating frame info, so no misleading origin is attached (the client sees an empty host / about:blank-like frame). Otherwise the original originatingFrameInfo is preserved. The added API tests (OriginatingFrameHostWhenDownloadComesFromGoBackNavigation and …FromClientInputNavigation, plus the isClientOrUserInitiated branch in the opener test) assert exactly this: for go-back and client-initiated downloads, download.originatingFrame.securityOrigin.host is empty, while genuinely frame-initiated downloads still equal the opener main frame. This restores correct, non-spoofable origin attribution for downloads.

This is a logic/origin-attribution bug in the UIProcess download path, not a memory-safety issue; there is no corruption primitive and no path to code execution. The concrete impact is that a download can be labeled with an originating origin that did not initiate it, misleading origin-based UI or client policy and undermining download provenance (a spoofing/CrossOrigin-attribution weakness). It is confined to UIProcess metadata handling and its severity is medium because it can defeat security decisions keyed on the download’s origin without granting broader compromise.