New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 14 users

Issue metadata

Status: Started
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 2
Type: Feature

Blocking:
issue 703223



Sign in to add a comment
link

Issue 539938: iframe sandbox does not prevent download

Reported by s.h.h.n....@gmail.com, Oct 6 2015

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36

Steps to reproduce the problem:
1. Open new.html.
2. Click on Download.

What is the expected behavior?
iframe sandbox prevent download.

What went wrong?
iframe sandbox does not care about download and let them download.

Did this work before? N/A 

Chrome version: 45.0.2454.101  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 19.0 r0

This maybe HTML5 spec issue. However I'm reporting this to vendors because I didn't get feedback from HTML5 after waiting for more than a month.
 
new.html
135 bytes View Download

Comment 1 by f...@chromium.org, Oct 7 2015

Cc: jww@chromium.org mkwst@chromium.org nparker@chromium.org
+jww,mkwst for an iframe sandbox issue

Comment 2 by f...@chromium.org, Oct 7 2015

I can't tell whether this is a feature request or a bug, tbqh, because I can't find a canonical list of things sandbox is supposed to disable in Chrome.

Comment 3 by s.h.h.n....@gmail.com, Oct 7 2015

FYI,

IE and Firefox does not allow download from sandboxed iframe.
new.html
145 bytes View Download

Comment 4 by mkwst@chromium.org, Oct 7 2015

Cc: est...@chromium.org
Labels: -Restrict-View-SecurityTeam -OS-Windows OS-All Cr-Blink-SecurityFeature
Status: Available
Yeah. We should do this: https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Feb/0010.html. I didn't realize that IE and Firefox had already changed their behavior. In that case, it sounds like we can fairly easily make that change.

Comment 5 by mkwst@chromium.org, Oct 7 2015

(By "we should do this", I mean "we should submit a patch to HTML that mandates this behavior, because it currently doesn't")

Comment 6 by f...@chromium.org, Oct 8 2015

Labels: -Type-Bug-Security Type-Feature Cr-Security

Comment 7 by sheriffbot@chromium.org, Oct 7 2016

Project Member
Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been available for more than 365 days, and should be re-evaluated. Please re-triage this issue.
The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 8 by mkwst@chromium.org, Feb 23 2017

Labels: -OS-All Sandbox OS-Android OS-Chrome OS-Linux OS-Mac OS-Windows
Status: Available (was: Untriaged)
We should do this, it's just on noone's roadmap.

Comment 9 by mkwst@chromium.org, Feb 23 2017

Issue 521715 has been merged into this issue.

Comment 10 by ojan@chromium.org, Mar 20 2017

Blocking: 703223

Comment 11 by ojan@chromium.org, Mar 20 2017

Owner: bi...@google.com

Comment 12 by meacer@google.com, Nov 10 2017

I don't think comment #3 is accurate for Firefox. The iframe in the example has x-frame-options set, which is causing the blocking.

(test link with no x-frame-options: https://storage.googleapis.com/www.meacer.com/sandbox_iframe_download/download.html)

Comment 13 by est...@chromium.org, Nov 10 2017

Labels: Hotlist-EnamelAndFriendsFixIt

Comment 14 by est...@chromium.org, Nov 10 2017

 Issue 783930  has been merged into this issue.

Comment 15 by mkwst@chromium.org, Nov 17 2017

Cc: -jww@chromium.org andypaicu@chromium.org vogelheim@chromium.org
Components: -Blink>SecurityFeature -Security UI>Browser>Downloads Blink>SecurityFeature>IFrameSandbox
We should actually do something about this: I filed https://github.com/whatwg/html/issues/3236 in the hopes of spurring conversation around changing the spec.

vogelheim@, andypaicu@: Would one of you be interested in poking at this? (Or, binlu@, are you already working through it?)

Comment 16 by mkwst@chromium.org, Nov 17 2017

Cc: jochen@chromium.org
(Or jochen@, really, since he's poking at `<a download>` anyway and is hopefully familiar with the code?)

Comment 17 by bi...@google.com, Nov 17 2017

I haven't started yet, and so it would be great if someone can take it. The plan was to add some metrics first for this, as well as for download triggered with vs. with user gesture (vs. on pages which had ever received user gesture) for cross-origin iframe and in general.

Comment 18 by jochen@chromium.org, Nov 20 2017

hum yes. Implementing something here is easy, but figuring out what we want to do may be hard.

Comment 19 by jochen@chromium.org, Nov 23 2017

Cc: -jochen@chromium.org binlu@chromium.org
Owner: jochen@chromium.org

Comment 20 by jochen@chromium.org, Nov 23 2017

Mike, should we disregard clicks on <a download>? should we treat them as a navigation? should we also block resources that are served with an content-disposition header?

Comment 21 by bugdroid1@chromium.org, Nov 23 2017

Project Member
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b8e3cbc5e907064231444ad6fb06bb5a1abac02b

commit b8e3cbc5e907064231444ad6fb06bb5a1abac02b
Author: Jochen Eisinger <jochen@chromium.org>
Date: Thu Nov 23 20:35:58 2017

Measure how often downloading anchors are clicked in sandboxes

BUG=539938
R=mkwst@chromium.org

Change-Id: I5464d9f9e8dac070cb79faa09471df2c410435ee
Reviewed-on: https://chromium-review.googlesource.com/787915
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Cr-Commit-Position: refs/heads/master@{#519017}
[modify] https://crrev.com/b8e3cbc5e907064231444ad6fb06bb5a1abac02b/third_party/WebKit/Source/core/dom/SandboxFlags.cpp
[modify] https://crrev.com/b8e3cbc5e907064231444ad6fb06bb5a1abac02b/third_party/WebKit/Source/core/dom/SandboxFlags.h
[modify] https://crrev.com/b8e3cbc5e907064231444ad6fb06bb5a1abac02b/third_party/WebKit/Source/core/html/HTMLAnchorElement.cpp
[modify] https://crrev.com/b8e3cbc5e907064231444ad6fb06bb5a1abac02b/third_party/WebKit/Source/core/html/HTMLIFrameElementSandbox.cpp
[modify] https://crrev.com/b8e3cbc5e907064231444ad6fb06bb5a1abac02b/third_party/WebKit/Source/platform/runtime_enabled_features.json5
[modify] https://crrev.com/b8e3cbc5e907064231444ad6fb06bb5a1abac02b/third_party/WebKit/common/sandbox_flags.h
[modify] https://crrev.com/b8e3cbc5e907064231444ad6fb06bb5a1abac02b/third_party/WebKit/public/platform/web_feature.mojom
[modify] https://crrev.com/b8e3cbc5e907064231444ad6fb06bb5a1abac02b/tools/metrics/histograms/enums.xml

Comment 22 by jochen@chromium.org, Dec 8 2017

Cc: jochen@chromium.org
Owner: cbentzel@chromium.org

Comment 23 by jochen@chromium.org, Dec 8 2017

Status: Assigned (was: Available)

Comment 24 by mlamouri@chromium.org, Jan 31 2018

Cc: mlamouri@chromium.org

Comment 26 by est...@chromium.org, Feb 18 2018

Labels: -Hotlist-EnamelAndFriendsFixIt

Comment 27 by jkarlin@chromium.org, Mar 19 2018

Cc: -jochen@chromium.org cbentzel@chromium.org
Owner: asanka@chromium.org

Comment 28 by jkarlin@chromium.org, Oct 31

Owner: yaoxia@chromium.org
Yao is landing a CL* to measure downloads from navigations or <a download> clicks. On a download, it measures if the subframe is 1) sandboxed 2) has a transient gesture 3) is an ad subframe and 4) if the frame is x-origin to the top frame.


* https://chromium-review.googlesource.com/c/chromium/src/+/1309096

Comment 29 by jkarlin@chromium.org, Oct 31

Yao: It would be good to land a usage counter for the number of navigation downloads from sandboxed iframes to go with Jochen's usage counter of <a download> in sandboxed iframes from comment #21.

Comment 30 by yaoxia@chromium.org, Nov 9

Cc: jkarlin@chromium.org
Thoughts needed:

Given that the usage in sandbox download looks low (https://uma.googleplex.com/p/chrome/histograms?endDate=latest&dayCount=7&histograms=Download.Subframe.SandboxOriginAdGesture), I'm going to implement the blocking, and I need advice on the UX change (if anything) for prevented download: 

Presumably we’ll silently ignore them (maybe log to console?) but we could optionally show UX for the user to download again.

Does anyone have a opinion?

Comment 31 by bugdroid1@chromium.org, Nov 16

Project Member

Comment 32 by bugdroid1@chromium.org, Dec 3

Project Member
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/dc16b78b188be1bec1c15895613456856bae0981

commit dc16b78b188be1bec1c15895613456856bae0981
Author: Yao Xiao <yaoxia@chromium.org>
Date: Mon Dec 03 17:34:11 2018

Prevent download in sandbox

Implements the feature while keeping it disabled. Will follow the
Intent to Implement/Ship process to enable it.

Bug: 539938
Change-Id: I83ef89691e5977717cdcf2c9a121177e5de52ab1
Reviewed-on: https://chromium-review.googlesource.com/c/1336493
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Josh Karlin <jkarlin@chromium.org>
Commit-Queue: Yao Xiao <yaoxia@chromium.org>
Cr-Commit-Position: refs/heads/master@{#613137}
[modify] https://crrev.com/dc16b78b188be1bec1c15895613456856bae0981/chrome/browser/page_load_metrics/observers/ads_page_load_metrics_observer_browsertest.cc
[modify] https://crrev.com/dc16b78b188be1bec1c15895613456856bae0981/content/common/navigation_params.cc
[modify] https://crrev.com/dc16b78b188be1bec1c15895613456856bae0981/content/common/navigation_params.h
[modify] https://crrev.com/dc16b78b188be1bec1c15895613456856bae0981/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/dc16b78b188be1bec1c15895613456856bae0981/third_party/blink/public/web/web_navigation_params.h
[modify] https://crrev.com/dc16b78b188be1bec1c15895613456856bae0981/third_party/blink/renderer/core/exported/local_frame_client_impl.cc
[modify] https://crrev.com/dc16b78b188be1bec1c15895613456856bae0981/third_party/blink/renderer/core/html/html_anchor_element.cc
[modify] https://crrev.com/dc16b78b188be1bec1c15895613456856bae0981/tools/metrics/histograms/enums.xml

Comment 33 by bugdroid1@chromium.org, Dec 3

Project Member
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e70df53cd4089dac471a009a04a00c2cb1f86a7f

commit e70df53cd4089dac471a009a04a00c2cb1f86a7f
Author: Yao Xiao <yaoxia@chromium.org>
Date: Mon Dec 03 23:06:37 2018

Whitelist WebFeatures DownloadInSandbox

To get a sense of which sites are having sandboxed download, so we might
be able to provide evidence that the blocking is worthwhile.

Bug: 539938
Change-Id: I672077892064b0f156a78aac1ff5be044f6c3ef8
Reviewed-on: https://chromium-review.googlesource.com/c/1356890
Reviewed-by: Bryan McQuade <bmcquade@chromium.org>
Commit-Queue: Yao Xiao <yaoxia@chromium.org>
Cr-Commit-Position: refs/heads/master@{#613305}
[modify] https://crrev.com/e70df53cd4089dac471a009a04a00c2cb1f86a7f/chrome/browser/page_load_metrics/observers/use_counter/ukm_features.cc

Comment 34 by bugdroid, Jan 24

Project Member
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4d572e9d38fa4366aefa2f357eb699df7b600fc6

commit 4d572e9d38fa4366aefa2f357eb699df7b600fc6
Author: Yao Xiao <yaoxia@chromium.org>
Date: Thu Jan 24 08:09:40 2019

Fixed the download intervention in sandbox for RemoteFrame::Navigate path.

Also, fixed test assertions that verify download is not happening: previously we
check the UMA too soon before download decision is made, which may give us false
negatives. The fix is to explicitly wait for
OnDidFinishSubFrameNavigation(), and check the UMA after the waiting.

Bug: 539938
Change-Id: Ib1a829420d68969877454413d0e2c7390a323b21
Reviewed-on: https://chromium-review.googlesource.com/c/1406153
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Commit-Queue: Yao Xiao <yaoxia@chromium.org>
Cr-Commit-Position: refs/heads/master@{#625557}

Comment 35 by bugdroid, Jan 24

Project Member
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/860deb6cec934fa4ce6faf30add8b6ef961b2052

commit 860deb6cec934fa4ce6faf30add8b6ef961b2052
Author: Yao Xiao <yaoxia@chromium.org>
Date: Thu Jan 24 23:56:00 2019

Only block download in sandbox without user activation

Follow the proposal discussed in https://github.com/whatwg/html/issues/3236.

Bug: 539938
Change-Id: I1841eb1f3c1f121586eed5a08e7e0e9f94ec4430
Reviewed-on: https://chromium-review.googlesource.com/c/1413377
Commit-Queue: Yao Xiao <yaoxia@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#625878}

Comment 36 by bugdroid, Jan 26

Project Member
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/726375b6a0c5583f4d6c37a0d5edaf2421cb72b9

commit 726375b6a0c5583f4d6c37a0d5edaf2421cb72b9
Author: Yao Xiao <yaoxia@chromium.org>
Date: Sat Jan 26 01:05:24 2019

Add tentative WPT to verify download in sandbox

General testing idea:
For a network request, we store a token in stash. And after a fixed
period of time sufficient for the download to finish, if there are
any, we validate the token in the stash to see if the network request
was issued and finished successfully.

In the case of <a download> where the decision of download can be made
before resource fetching, the server sets the token immediately.

In the case of navigation to a download, the server will stream a
response over 1 seconds and set the token at the end only when the
socket has been connected. So it is able to detect any download
cancellation while fetching the resource.

Bug: 539938
Change-Id: I734c8cc18d1f761f16646c6b859a6b731ab40ff5
Reviewed-on: https://chromium-review.googlesource.com/c/1422667
Commit-Queue: Yao Xiao <yaoxia@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626289}

Comment 37 by bugdroid, Jan 26

Project Member
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ae88ba39f884a27f1753b8a03328a8ba8505be4a

commit ae88ba39f884a27f1753b8a03328a8ba8505be4a
Author: Findit <findit-for-me@appspot.gserviceaccount.com>
Date: Sat Jan 26 04:30:32 2019

Revert "Add tentative WPT to verify download in sandbox"

This reverts commit 726375b6a0c5583f4d6c37a0d5edaf2421cb72b9.

Reason for revert:

Findit (https://goo.gl/kROfz5) identified CL at revision 626289 as the
culprit for flakes in the build cycles as shown on:
https://findit-for-me.appspot.com/waterfall/flake/flake-culprit?key=ag9zfmZpbmRpdC1mb3ItbWVyQwsSDEZsYWtlQ3VscHJpdCIxY2hyb21pdW0vNzI2Mzc1YjZhMGM1NTgzZjRkNmMzN2EwZDVlZGFmMjQyMWNiNzJiOQw

Sample Failed Build: https://ci.chromium.org/buildbot/chromium.mac/Mac10.13%20Tests/9272

Sample Failed Step: webkit_layout_tests on Intel GPU on Mac

Sample Flaky Test: external/wpt/html/semantics/embedded-content/the-iframe-element/iframe_sandbox_navigation_download_allow_downloads_without_user_activation.sub.tentative.html

Original change's description:
> Add tentative WPT to verify download in sandbox
> 
> General testing idea:
> For a network request, we store a token in stash. And after a fixed
> period of time sufficient for the download to finish, if there are
> any, we validate the token in the stash to see if the network request
> was issued and finished successfully.
> 
> In the case of <a download> where the decision of download can be made
> before resource fetching, the server sets the token immediately.
> 
> In the case of navigation to a download, the server will stream a
> response over 1 seconds and set the token at the end only when the
> socket has been connected. So it is able to detect any download
> cancellation while fetching the resource.
> 
> Bug: 539938
> Change-Id: I734c8cc18d1f761f16646c6b859a6b731ab40ff5
> Reviewed-on: https://chromium-review.googlesource.com/c/1422667
> Commit-Queue: Yao Xiao <yaoxia@chromium.org>
> Reviewed-by: Mike West <mkwst@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#626289}

Change-Id: Id343b8de2a751856b27907ba4c8dfb52715e4598
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 539938
Reviewed-on: https://chromium-review.googlesource.com/c/1437999
Cr-Commit-Position: refs/heads/master@{#626323}

Comment 38 by bugdroid, Jan 27

Project Member
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9b54c9ade4a8ea96046ca2c2492e55b2ed04047b

commit 9b54c9ade4a8ea96046ca2c2492e55b2ed04047b
Author: Yao Xiao <yaoxia@chromium.org>
Date: Sun Jan 27 17:09:45 2019

Give console warning for deprecation of DownloadInSandboxWithoutUserActivation

Add a method to cover features that was logged from the browser side.

Bug: 539938
Change-Id: I4b6cbdcb8e37afdd5862f15f2f7c877b13d30897
Reviewed-on: https://chromium-review.googlesource.com/c/1437775
Commit-Queue: Yao Xiao <yaoxia@chromium.org>
Reviewed-by: Charlie Harrison <csharrison@chromium.org>
Cr-Commit-Position: refs/heads/master@{#626402}

Comment 39 by yaoxia@chromium.org, Jan 28

Labels: Merge-Request-73
Status: Started (was: Assigned)
TPM: The Merge-Request-73 is mainly for the CL https://chromium-review.googlesource.com/c/1437775 to give console warnings for the deprecation. We wish to deprecate in M73 and if things goes well remove in M74.

It was manually tested - the console shows the expected warning when we trigger a "download in sandboxed frame without gesture".

Comment 40 by sheriffbot@chromium.org, Jan 29

Project Member
Labels: -Merge-Request-73 Hotlist-Merge-Approved Merge-Approved-73
Your change meets the bar and is auto-approved for M73. Please go ahead and merge the CL to branch 3683 manually. Please contact milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), cindyb@(ChromeOS), srinivassista@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 41 by bugdroid, Jan 30

Project Member
Labels: -merge-approved-73 merge-merged-3683
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7befe3cc8cf8e6efd93bc528647caf317a9072d1

commit 7befe3cc8cf8e6efd93bc528647caf317a9072d1
Author: Yao Xiao <yaoxia@chromium.org>
Date: Wed Jan 30 15:55:07 2019

Give console warning for deprecation of DownloadInSandboxWithoutUserActivation

Add a method to cover features that was logged from the browser side.

Bug: 539938
Change-Id: I4b6cbdcb8e37afdd5862f15f2f7c877b13d30897
Reviewed-on: https://chromium-review.googlesource.com/c/1437775
Commit-Queue: Yao Xiao <yaoxia@chromium.org>
Reviewed-by: Charlie Harrison <csharrison@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#626402}(cherry picked from commit 9b54c9ade4a8ea96046ca2c2492e55b2ed04047b)
Reviewed-on: https://chromium-review.googlesource.com/c/1444238
Cr-Commit-Position: refs/branch-heads/3683@{#66}
Cr-Branched-From: e51029943e0a38dd794b73caaf6373d5496ae783-refs/heads/master@{#625896}
[modify] https://crrev.com/7befe3cc8cf8e6efd93bc528647caf317a9072d1/chrome/browser/page_load_metrics/observers/use_counter_page_load_metrics_observer.cc

Comment 42 by cr-audit...@appspot.gserviceaccount.com, Feb 7

Project Member
Labels: Merge-Merged-73-3683
The following revision refers to this bug: 
https://chromium.googlesource.com/chromium/src.git/+/7befe3cc8cf8e6efd93bc528647caf317a9072d1

Commit: 7befe3cc8cf8e6efd93bc528647caf317a9072d1
Author: yaoxia@chromium.org
Commiter: csharrison@chromium.org
Date: 2019-01-30 15:55:07 +0000 UTC

Give console warning for deprecation of DownloadInSandboxWithoutUserActivation

Add a method to cover features that was logged from the browser side.

Bug: 539938
Change-Id: I4b6cbdcb8e37afdd5862f15f2f7c877b13d30897
Reviewed-on: https://chromium-review.googlesource.com/c/1437775
Commit-Queue: Yao Xiao <yaoxia@chromium.org>
Reviewed-by: Charlie Harrison <csharrison@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#626402}(cherry picked from commit 9b54c9ade4a8ea96046ca2c2492e55b2ed04047b)
Reviewed-on: https://chromium-review.googlesource.com/c/1444238
Cr-Commit-Position: refs/branch-heads/3683@{#66}
Cr-Branched-From: e51029943e0a38dd794b73caaf6373d5496ae783-refs/heads/master@{#625896}

Comment 43 by bugdroid, Feb 15 (5 days ago)

Project Member
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a98d07b33d3897a42090496f9c1421dafe6bea99

commit a98d07b33d3897a42090496f9c1421dafe6bea99
Author: Yao Xiao <yaoxia@chromium.org>
Date: Fri Feb 15 00:42:49 2019

Support |allow-downloads-without-user-activation| flag

It should be okay to support the flag without enabling the intervention feature
(i.e. when a website adapts by adding the "allow-downloads-" token, we should no
longer give deprecation warnings & should not give console errors "...invalid
sandbox flag". Both would happen if we don't support the token.).

Supporting the token will also change the result of
IsSandboxed(kSandboxDownloads): previously it was always True; now it will be
False if the "allow-downloads-" token is set. It will make the UseCounter
DownloadInSandbox keep decreasing as more and more websites are adapting to the
change. This also looks positive as it gives an idea of ongoing compatibility
risk rather than the maximum risk.

Bug: 539938
Change-Id: I002f1a556205344953dabf094849af7e1222dd9f
Reviewed-on: https://chromium-review.googlesource.com/c/1471002
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Reviewed-by: Josh Karlin <jkarlin@chromium.org>
Commit-Queue: Yao Xiao <yaoxia@chromium.org>
Cr-Commit-Position: refs/heads/master@{#632417}
[modify] https://crrev.com/a98d07b33d3897a42090496f9c1421dafe6bea99/chrome/browser/page_load_metrics/observers/ad_metrics/ads_page_load_metrics_observer_browsertest.cc
[modify] https://crrev.com/a98d07b33d3897a42090496f9c1421dafe6bea99/third_party/blink/renderer/core/frame/sandbox_flags.cc
[modify] https://crrev.com/a98d07b33d3897a42090496f9c1421dafe6bea99/third_party/blink/renderer/core/html/html_iframe_element_sandbox.cc
[modify] https://crrev.com/a98d07b33d3897a42090496f9c1421dafe6bea99/third_party/blink/web_tests/fast/dom/HTMLIFrameElement/sandbox-feature-detection.html

Comment 44 by yaoxia@chromium.org, Feb 15 (5 days ago)

Labels: Merge-Request-73
Requesting to merge https://chromium-review.googlesource.com/c/chromium/src/+/1471002. It lets websites to prepare for the upcoming deprecation by adding "allow-downloads-" sandbox flag without introducing "unsupported flag" console error. This also allows sites to verify their fix would work, by checking they no longer receive a deprecation message.

Comment 45 by sheriffbot@chromium.org, Feb 15 (5 days ago)

Project Member
Labels: -Merge-Request-73 Check-String-Translation Merge-Review-73 Hotlist-Merge-Review
This bug requires manual review: There is .json file changes and we are only 24 days from stable. Please confirm this does not require string translation.
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), cindyb@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 46 by srinivassista@google.com, Feb 17 (3 days ago)

yaoxia@ can you confirm what is priority of this fix to go into M73? can it wait until M74? How safe is the merge if needed for M73, Also can you verify the change in canary and share the results

Comment 47 by yaoxia@chromium.org, Today (21 hours ago)

srinivassista@ I think it's not urgent to fix but the risk is also low, both because of the change only affects console messages.

I've tested on canary vs. beta, by having a site creating a sandboxed iframe to download and setting "allow-downloads-without-user-activation" token. The result is:
beta: still can see deprecation console warning; and even worse, an invalid sandbox flag console error.
canary: no warnings / errors.

Comment 48 by abdulsyed@google.com, Today (18 hours ago)

Labels: -Merge-Review-73 Merge-Rejected-73
Let's target M74 for this. If you think it's critical for m73, please re-request merge with more justification.

Sign in to add a comment