From: uazo Date: Tue, 28 Mar 2023 15:43:18 +0000 Subject: Enable Document Open Inheritance Removal License: GPL-2.0-or-later - https://spdx.org/licenses/GPL-2.0-or-later.html --- .../blink/renderer/core/dom/document.cc | 64 ------------------- .../platform/runtime_enabled_features.json5 | 1 - 2 files changed, 65 deletions(-) diff --git a/third_party/blink/renderer/core/dom/document.cc b/third_party/blink/renderer/core/dom/document.cc --- a/third_party/blink/renderer/core/dom/document.cc +++ b/third_party/blink/renderer/core/dom/document.cc @@ -3442,70 +3442,6 @@ void Document::open(LocalDOMWindow* entered_window, // https://chromestatus.com/metrics/feature/timeline/popularity/4375 CountUse(WebFeature::kDocumentOpenMutateSandbox); } - - if (!RuntimeEnabledFeatures:: - DocumentOpenSandboxInheritanceRemovalEnabled()) { - // We inherit the sandbox flags of the entered document, so mask on - // the ones contained in the CSP. The operator| is a bitwise operation - // on the sandbox flags bits. It makes the sandbox policy stricter (or - // as strict) as both policy. - // - // TODO(arthursonzogni): Why merging sandbox flags? - // This doesn't look great at many levels: - // - The browser process won't be notified of the update. - // - The origin won't be made opaque, despite the new flags. - // - The sandbox flags of the document can't be considered to be an - // immutable property anymore. - // - // Ideally: - // - javascript-url document. - // - XSLT document. - // - document.open. - // should not mutate the security properties of the current document. - // From the browser process point of view, all of those operations are - // not considered to produce new documents. No IPCs are sent, it is as - // if it was a no-op. - // - // TODO(https://crbug.com/1360795) Remove this. Only Chrome implements - // it. Safari/Firefox do not. - dom_window_->GetSecurityContext().SetSandboxFlags( - dom_window_->GetSecurityContext().GetSandboxFlags() | - entered_window->GetSandboxFlags()); - } - - // We would like to remove this block. See: - // https://docs.google.com/document/d/1_89X4cNUab-PZE0iBDTKIftaQZsFbk7SbFmHbqY54os - // - // This is not specified. Only Webkit/Blink implement it. Gecko doesn't. - // - // 2023-06-02: Removal would impact 0.02% page load. - // https://chromestatus.com/metrics/feature/timeline/popularity/4535 - // We hope the document.domain deprecation is going to drive this number - // down quickly: - // https://developer.chrome.com/blog/document-domain-setter-deprecation/ - if (!RuntimeEnabledFeatures::DocumentOpenOriginAliasRemovalEnabled()) { - dom_window_->GetSecurityContext().SetSecurityOrigin( - entered_window->GetMutableSecurityOrigin()); - - // The SecurityOrigin is now shared in between two different window. It - // means mutating one can have side effect on the other. - entered_window->GetMutableSecurityOrigin() - ->set_aliased_by_document_open(); - } - - // Question: Should we remove the inheritance of the CookieURL via - // document.open? - // - // Arguments in favor of maintaining this behavior include the fact that - // document.open can be used to alter the document's URL. According to - // prior talks, this is necessary for web compatibility. It looks nicer if - // all URL variations change uniformly and simultaneously. - // - // Arguments in favor of eliminating this behavior include the fact that - // cookie URLs are extremely particular pieces of state that resemble the - // origin more than they do actual URLs. The less we inherit via - // document.open, the better. - cookie_url_ = entered_window->document()->CookieURL(); } } diff --git a/third_party/blink/renderer/platform/runtime_enabled_features.json5 b/third_party/blink/renderer/platform/runtime_enabled_features.json5 --- a/third_party/blink/renderer/platform/runtime_enabled_features.json5 +++ b/third_party/blink/renderer/platform/runtime_enabled_features.json5 @@ -1441,7 +1441,6 @@ { name: "DocumentOpenSandboxInheritanceRemoval", status: "stable", - copied_from_base_feature_if: "overridden", }, { name: "DocumentPictureInPictureAPI", -- 2.25.1