Block external protocol handler with sandbox. #7124

ArthurSonzogni · 2021-09-27T14:46:58Z

Developers are surprised that sandboxed iframe can navigate and/or
redirect the user toward an external application.

General iframe navigation in the sandboxed iframe are not blocked
normally, because they stay within the iframe. However they can be seen
as a popup or a top-level navigation when it opens an external
application. In this case, it makes sense to extend the scope of sandbox
flags, and block malvertisers.

This patch gates access to external protocol from sandboxed iframe behind any of:

allow-popup
allow-top-level-navigation
allow-top-level-navigation-by-user-activation + UserGesture.

This addresses:
#2191

At least two implementers are interested (and none opposed):
- Chrome: (I will request for an Intent-To-Ship)
- Firefox: Disable custom protocols in sandboxed iframe. mozilla/standards-positions#581 (worth prototyping)
- Safari: https://lists.webkit.org/pipermail/webkit-dev/2021-September/031988.html (pending)
Tests are written and can be reviewed and commented upon at:
- How can I do it? Hand-off to external application is a at the boundary. Invoking external application or not is not observable from within the web platform.
Implementation bugs are filed:
- Chrome: https://crbug.com/1148777
- Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1735746
- Safari: https://bugs.webkit.org/show_bug.cgi?id=231727

(See WHATWG Working Mode: Changes for more details.)

/acknowledgements.html ( diff )
/browsing-the-web.html ( diff )

Developers are surprised that sandboxed iframe can navigate and/or redirect the user toward an external application. General iframe navigation in the sandboxed iframe are not blocked normally, because they stay within the iframe. However they can be seen as a popup or a top-level navigation when it opens an external application. In this case, it makes sense to extend the scope of sandbox flags, and block malvertisers. This patch gates access to external protocol behind one of: - allow-popup - allow-top-level-navigation - allow-top-level-navigation-by-user-activation + UserGesture.

ArthurSonzogni · 2021-09-27T14:52:07Z

Screenshot of the change:

annevk

This looks good to me, but there are a number of formatting issues and unfortunately we do not have automated formatting.

Apart from indentation and such there also need to be closing tags throughout for the HTML standard.

source

ArthurSonzogni · 2021-09-28T13:26:42Z

Thanks!
I addressed your suggestion.

we do not have automated formatting.

I am wondering how hard it would be for me to make it (I might try one day).

Developers are surprised that sandboxed iframe can navigate the user toward an external protocol. The navigation in the sandbox is not blocked by sandbox normally, only top-level navigation and opening popups are blocked. So not blocking iframe navigations in general is working as intended. However sandboxed iframe navigation toward external protocol handler are navigating the user toward a different application. Somehow, this can be seen as a new popup or a new top-level navigation. This patch gates access to external protocol behind one of: - allow-popup - allow-top-level-navigation - allow-top-level-navigation-by-user-activation + UserGesture. This is not enforced by content/. So this is not a web feature. This is implemented by chrome/ only. The reason is that Android Webview may do not want to apply these restrictions. Android Webview do not support external protocol by itself, but it let the Android app to listen and intercept the request. We decided to let the Android app full power here, to avoid breaking the existing users. Spec: whatwg/html#7124 Mozilla position: mozilla/standards-positions#581 Webkit position: https://lists.webkit.org/pipermail/webkit-dev/2021-September/031988.html Chrome feature: https://chromestatus.com/guide/edit/5680742077038592 Change-Id: I0c3f130d084e7a23555178f3a172efb3607e87b6 Bug: 1148777, 1253379 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3162979 Reviewed-by: Colin Blundell <blundell@chromium.org> Reviewed-by: Roman Sorokin [CET] <rsorokin@chromium.org> Reviewed-by: Devlin <rdevlin.cronin@chromium.org> Reviewed-by: Dominick Ng <dominickn@chromium.org> Reviewed-by: Richard Coles <torne@chromium.org> Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org> Cr-Commit-Position: refs/heads/main@{#926684}

This reverts commit ad1f7db. Reason for revert: ExternalProtocolHandlerSandboxBrowserTest failed on Mac and Win7, more links can be found in crbug.com/1254729 Original change's description: > Block external protocol handler with sandbox. > > Developers are surprised that sandboxed iframe can navigate the user > toward an external protocol. > The navigation in the sandbox is not blocked by sandbox normally, only > top-level navigation and opening popups are blocked. So not blocking > iframe navigations in general is working as intended. However sandboxed > iframe navigation toward external protocol handler are navigating the > user toward a different application. Somehow, this can be seen as a new > popup or a new top-level navigation. > > This patch gates access to external protocol behind one of: > - allow-popup > - allow-top-level-navigation > - allow-top-level-navigation-by-user-activation + UserGesture. > > This is not enforced by content/. So this is not a web feature. > This is implemented by chrome/ only. > > The reason is that Android Webview may do not want to apply these > restrictions. Android Webview do not support external protocol by > itself, but it let the Android app to listen and intercept the request. > We decided to let the Android app full power here, to avoid breaking > the existing users. > > Spec: > whatwg/html#7124 > > Mozilla position: > mozilla/standards-positions#581 > > Webkit position: > https://lists.webkit.org/pipermail/webkit-dev/2021-September/031988.html > > Chrome feature: > https://chromestatus.com/guide/edit/5680742077038592 > > Change-Id: I0c3f130d084e7a23555178f3a172efb3607e87b6 > Bug: 1148777, 1253379 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3162979 > Reviewed-by: Colin Blundell <blundell@chromium.org> > Reviewed-by: Roman Sorokin [CET] <rsorokin@chromium.org> > Reviewed-by: Devlin <rdevlin.cronin@chromium.org> > Reviewed-by: Dominick Ng <dominickn@chromium.org> > Reviewed-by: Richard Coles <torne@chromium.org> > Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org> > Cr-Commit-Position: refs/heads/main@{#926684} Bug: 1148777, 1253379, 1254729 Change-Id: I646705d2adc6375243caaa4b7ba4102dcd1b468c No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3196851 Auto-Submit: Owen Min <zmin@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Owen Min <zmin@chromium.org> Owners-Override: Owen Min <zmin@chromium.org> Cr-Commit-Position: refs/heads/main@{#926739}

annevk

This looks good to me. I'll let @domenic have a final pass when he's back. (And if you manage to create tooling for formatting that'd be great!)

source

Reland: ------- See diff: https://chromium-review.googlesource.com/c/chromium/src/+/3198263/1..19 On Linux, external protocols calls are delegated to the OS without additional security check. On Windows and Mac (possibly more), it needs to be allowed by the the PolicyBlocklistService explicitely, or it would go through a permission prompt, causing the test to fail. Revert: ------- https://chromium-review.googlesource.com/c/chromium/src/+/3196851 Due to failing test on Windows and Mac. Original commit: ---------------- Developers are surprised that sandboxed iframe can navigate the user toward an external protocol. The navigation in the sandbox is not blocked by sandbox normally, only top-level navigation and opening popups are blocked. So not blocking iframe navigations in general is working as intended. However sandboxed iframe navigation toward external protocol handler are navigating the user toward a different application. Somehow, this can be seen as a new popup or a new top-level navigation. This patch gates access to external protocol behind one of: - allow-popup - allow-top-level-navigation - allow-top-level-navigation-by-user-activation + UserGesture. This is not enforced by content/. So this is not a web feature. This is implemented by chrome/ only. The reason is that Android Webview may do not want to apply these restrictions. Android Webview do not support external protocol by itself, but it let the Android app to listen and intercept the request. We decided to let the Android app full power here, to avoid breaking the existing users. Spec: whatwg/html#7124 Mozilla position: mozilla/standards-positions#581 Webkit position: https://lists.webkit.org/pipermail/webkit-dev/2021-September/031988.html Chrome feature: https://chromestatus.com/guide/edit/5680742077038592 Bug: 1148777, 1253379 Change-Id: Iea92eb8ae6bf1da997dd1433aab4f93fecd879fc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3198263 Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org> Reviewed-by: Richard Coles <torne@chromium.org> Reviewed-by: Dominick Ng <dominickn@chromium.org> Reviewed-by: Devlin <rdevlin.cronin@chromium.org> Reviewed-by: Pavol Marko <pmarko@chromium.org> Reviewed-by: Colin Blundell <blundell@chromium.org> Cr-Commit-Position: refs/heads/main@{#929176}

domenic · 2021-10-12T20:45:39Z

source

+    <ul class=brief>
+     <li><p><var>sandboxFlags</var> contains the <code
+     data-x="attr-iframe-sandbox-allow-top-navigation-by-user-activation">allow-top-navigation-by-user-activation</code>
+     token and <var>hasTransientActivation</var> is true</p></li>


Nit: missing period.

However, a larger issue: I don't think these are the right sandboxing flags to consult. Shouldn't we consult sandboxFlags computed in step 15 of navigate? That also avoids issues where the sandboxing flags change between the start of the navigation, and the end of it. (Not sure exactly when that could happen, but I think it can... redirects, maybe.)

I agree, and that's what is implemented in Chrome. I will plumb it.

This required significant plumbing. This goes from navigate toward hand-off-to-external-software, but there are several paths.

Here are the call sites:

navigate -> process-a-navigate-URL-scheme navigate -> process-a-navigate-fetch navigate -> process-a-navigate-response process-a-navigate-fetch -> process-a-navigate-URL-scheme process-a-navigate-fetch -> process-a-navigate-response process-a-navigate-URL-scheme ->hand-off-to-external-software process-a-navigate-response -> hand-off-to-external-software read-multipart-x-mixed-replace -> process-a-navigate-response

visualized:

┌───────────────────────────────────┐┌──────────────────────────────┐ │navigate ││read-multipart-x-mixed-replace│ └┬─────────────┬───────────────────┬┘└──────────┬───────────────────┘ │┌────────────▽──────────────────┐│ │ ││process-a-navigate-fetch ││ │ │└────────────┬────────────────┬─┘│ │ ┌▽─────────────▽──────────────┐┌▽──▽────────────▽──────────┐ │process-a-navigate-URL-scheme││process-a-navigate-response│ └──────────────┬──────────────┘└┬──────────────────────────┘ ┌────▽────────────────▽──────────┐ │hand-off-to-external-software │ └────────────────────────────────┘

I plumbed sandboxFlags for every call. Please note an exception for:
read-multipart-x-mixed-replace -> process-a-navigate-response. The latter is already not clearly/implicitly defined by:

using the same setup as the navigate attempt that caused this section to be invoked in the first place.

So, I let it this way.

Thanks! This looks almost perfect, except we can eliminate the explicit sandboxFlags parameter to "process a navigate response" since it's already contained in the navigationParams parameter. We just need to pull it out and pass navigationParams's final sandboxing flag set to "hand-off-to-external-software".

Done: 4268069

source

ArthurSonzogni · 2021-10-13T14:23:57Z

Thanks @domenic!
I addressed your two comments.

It expects an additional network::mojom::WebSandboxFlags parameter now. Chromium change: https://source.chromium.org/chromium/chromium/src/+/038f0de5070fb6c4ccab88ca89aaffa4b41d8d1f commit 038f0de5070fb6c4ccab88ca89aaffa4b41d8d1f Author: Arthur Sonzogni <arthursonzogni@chromium.org> Date: Thu Oct 7 13:51:34 2021 +0000 Reland "Block external protocol handler with sandbox." Reland: ------- See diff: https://chromium-review.googlesource.com/c/chromium/src/+/3198263/1..19 On Linux, external protocols calls are delegated to the OS without additional security check. On Windows and Mac (possibly more), it needs to be allowed by the the PolicyBlocklistService explicitely, or it would go through a permission prompt, causing the test to fail. Revert: ------- https://chromium-review.googlesource.com/c/chromium/src/+/3196851 Due to failing test on Windows and Mac. Original commit: ---------------- Developers are surprised that sandboxed iframe can navigate the user toward an external protocol. The navigation in the sandbox is not blocked by sandbox normally, only top-level navigation and opening popups are blocked. So not blocking iframe navigations in general is working as intended. However sandboxed iframe navigation toward external protocol handler are navigating the user toward a different application. Somehow, this can be seen as a new popup or a new top-level navigation. This patch gates access to external protocol behind one of: - allow-popup - allow-top-level-navigation - allow-top-level-navigation-by-user-activation + UserGesture. This is not enforced by content/. So this is not a web feature. This is implemented by chrome/ only. The reason is that Android Webview may do not want to apply these restrictions. Android Webview do not support external protocol by itself, but it let the Android app to listen and intercept the request. We decided to let the Android app full power here, to avoid breaking the existing users. Spec: whatwg/html#7124 Mozilla position: mozilla/standards-positions#581 Webkit position: https://lists.webkit.org/pipermail/webkit-dev/2021-September/031988.html Chrome feature: https://chromestatus.com/guide/edit/5680742077038592 Bug: 1148777, 1253379

ArthurSonzogni · 2021-10-15T20:27:06Z

Thanks both of you for the reviews!

It expects an additional network::mojom::WebSandboxFlags parameter now. Chromium change: https://source.chromium.org/chromium/chromium/src/+/038f0de5070fb6c4ccab88ca89aaffa4b41d8d1f commit 038f0de5070fb6c4ccab88ca89aaffa4b41d8d1f Author: Arthur Sonzogni <arthursonzogni@chromium.org> Date: Thu Oct 7 13:51:34 2021 +0000 Reland "Block external protocol handler with sandbox." Reland: ------- See diff: https://chromium-review.googlesource.com/c/chromium/src/+/3198263/1..19 On Linux, external protocols calls are delegated to the OS without additional security check. On Windows and Mac (possibly more), it needs to be allowed by the the PolicyBlocklistService explicitely, or it would go through a permission prompt, causing the test to fail. Revert: ------- https://chromium-review.googlesource.com/c/chromium/src/+/3196851 Due to failing test on Windows and Mac. Original commit: ---------------- Developers are surprised that sandboxed iframe can navigate the user toward an external protocol. The navigation in the sandbox is not blocked by sandbox normally, only top-level navigation and opening popups are blocked. So not blocking iframe navigations in general is working as intended. However sandboxed iframe navigation toward external protocol handler are navigating the user toward a different application. Somehow, this can be seen as a new popup or a new top-level navigation. This patch gates access to external protocol behind one of: - allow-popup - allow-top-level-navigation - allow-top-level-navigation-by-user-activation + UserGesture. This is not enforced by content/. So this is not a web feature. This is implemented by chrome/ only. The reason is that Android Webview may do not want to apply these restrictions. Android Webview do not support external protocol by itself, but it let the Android app to listen and intercept the request. We decided to let the Android app full power here, to avoid breaking the existing users. Spec: whatwg/html#7124 Mozilla position: mozilla/standards-positions#581 Webkit position: https://lists.webkit.org/pipermail/webkit-dev/2021-September/031988.html Chrome feature: https://chromestatus.com/guide/edit/5680742077038592 Bug: 1148777, 1253379

cdumez · 2021-11-03T22:15:46Z

Sorry if I missed this but are there WPT tests for this? The original description mentions existing tests but I am not sure where they are.

domenic · 2021-11-03T22:20:08Z

The original description mentions that we can't really write WPTs for this:

How can I do it? Hand-off to external application is a at the boundary. Invoking external application or not is not observable from within the web platform.

For security reasons, web browsers started to block navigations toward custom protocols initiated from within a sandboxed iframe. They are allowed, only when normal navigations are already allowed in top-level frame and when opening new popups. See: whatwg#7124 And: whatwg#2191 (comment) So far so good, but it is hard for some website like https://teams.microsoft.com/ to handle this change. They would like not to block custom scheme, while continuing to block supported ones. An escape hatch could be to mint a new "allow-custom-protocol-navigation" sandbox flags. This would allow web browser to ship the initial security mitigation without breaking them. Bug: whatwg#7468

For security reasons, web browsers started to block navigations toward custom protocols initiated from within a sandboxed iframe. They are allowed, only when normal navigations are already allowed in top-level frame and when opening new popups. See #7124 and #2191 (comment) for that background. It is hard for some websites to handle this change. They would like to not block custom schemes, while continuing to block supported ones. This adds a new "allow-custom-protocol-navigation" value for the sandbox="" attribute, which such sites can use. Closes #7468.

This patch: - Implements the following HTML spec PR: whatwg/html#7654 - Add warning behind a flag. I plan to use them for two versions. - Delay Enterprise policy removal to M117 (~1 year) For security reasons, web browsers started to block navigations toward custom protocols initiated from within a sandboxed iframe. They are allowed, only when normal navigations are already allowed in top-level frame and when opening new popups. See: whatwg/html#7124 And: whatwg/html#2191 (comment) So far so good, but it is hard for some website like https://teams.microsoft.com/ to handle this change. They would like not to block custom scheme, while continuing to block supported ones. An escape hatch could be to mint a new `top-navigation-to-external-protocols` sandbox flags. This would allow web browser to ship the initial security mitigation without breaking them. Bug: whatwg/html#7468 Bug: https://crbug.com/1253379 Change-Id: If32169f5d30651b78a3251f0ec5e174a8a1a8101 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3483941 Reviewed-by: Mike West <mkwst@chromium.org> Reviewed-by: Vasilii Sukhanov <vasilii@chromium.org> Reviewed-by: Yutaka Hirano <yhirano@chromium.org> Reviewed-by: Pavol Marko <pmarko@chromium.org> Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org> Cr-Commit-Position: refs/heads/main@{#979138}

For security reasons, web browsers started to block navigations toward custom protocols initiated from within a sandboxed iframe. They are allowed, only when normal navigations are already allowed in top-level frame and when opening new popups. See whatwg#7124 and whatwg#2191 (comment) for that background. It is hard for some websites to handle this change. They would like to not block custom schemes, while continuing to block supported ones. This adds a new "allow-custom-protocol-navigation" value for the sandbox="" attribute, which such sites can use. Closes whatwg#7468.

Developers are surprised that sandboxed iframe can navigate the user toward an external protocol. The navigation in the sandbox is not blocked by sandbox normally, only top-level navigation and opening popups are blocked. So not blocking iframe navigations in general is working as intended. However sandboxed iframe navigation toward external protocol handler are navigating the user toward a different application. Somehow, this can be seen as a new popup or a new top-level navigation. This patch gates access to external protocol behind one of: - allow-popup - allow-top-level-navigation - allow-top-level-navigation-by-user-activation + UserGesture. This is not enforced by content/. So this is not a web feature. This is implemented by chrome/ only. The reason is that Android Webview may do not want to apply these restrictions. Android Webview do not support external protocol by itself, but it let the Android app to listen and intercept the request. We decided to let the Android app full power here, to avoid breaking the existing users. Spec: whatwg/html#7124 Mozilla position: mozilla/standards-positions#581 Webkit position: https://lists.webkit.org/pipermail/webkit-dev/2021-September/031988.html Chrome feature: https://chromestatus.com/guide/edit/5680742077038592 Change-Id: I0c3f130d084e7a23555178f3a172efb3607e87b6 Bug: 1148777, 1253379 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3162979 Reviewed-by: Colin Blundell <blundell@chromium.org> Reviewed-by: Roman Sorokin [CET] <rsorokin@chromium.org> Reviewed-by: Devlin <rdevlin.cronin@chromium.org> Reviewed-by: Dominick Ng <dominickn@chromium.org> Reviewed-by: Richard Coles <torne@chromium.org> Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org> Cr-Commit-Position: refs/heads/main@{#926684} NOKEYCHECK=True GitOrigin-RevId: ad1f7dbbaa99230cf8637fc035461466a3fc0237

This reverts commit ad1f7dbbaa99230cf8637fc035461466a3fc0237. Reason for revert: ExternalProtocolHandlerSandboxBrowserTest failed on Mac and Win7, more links can be found in crbug.com/1254729 Original change's description: > Block external protocol handler with sandbox. > > Developers are surprised that sandboxed iframe can navigate the user > toward an external protocol. > The navigation in the sandbox is not blocked by sandbox normally, only > top-level navigation and opening popups are blocked. So not blocking > iframe navigations in general is working as intended. However sandboxed > iframe navigation toward external protocol handler are navigating the > user toward a different application. Somehow, this can be seen as a new > popup or a new top-level navigation. > > This patch gates access to external protocol behind one of: > - allow-popup > - allow-top-level-navigation > - allow-top-level-navigation-by-user-activation + UserGesture. > > This is not enforced by content/. So this is not a web feature. > This is implemented by chrome/ only. > > The reason is that Android Webview may do not want to apply these > restrictions. Android Webview do not support external protocol by > itself, but it let the Android app to listen and intercept the request. > We decided to let the Android app full power here, to avoid breaking > the existing users. > > Spec: > whatwg/html#7124 > > Mozilla position: > mozilla/standards-positions#581 > > Webkit position: > https://lists.webkit.org/pipermail/webkit-dev/2021-September/031988.html > > Chrome feature: > https://chromestatus.com/guide/edit/5680742077038592 > > Change-Id: I0c3f130d084e7a23555178f3a172efb3607e87b6 > Bug: 1148777, 1253379 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3162979 > Reviewed-by: Colin Blundell <blundell@chromium.org> > Reviewed-by: Roman Sorokin [CET] <rsorokin@chromium.org> > Reviewed-by: Devlin <rdevlin.cronin@chromium.org> > Reviewed-by: Dominick Ng <dominickn@chromium.org> > Reviewed-by: Richard Coles <torne@chromium.org> > Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org> > Cr-Commit-Position: refs/heads/main@{#926684} Bug: 1148777, 1253379, 1254729 Change-Id: I646705d2adc6375243caaa4b7ba4102dcd1b468c No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3196851 Auto-Submit: Owen Min <zmin@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Owen Min <zmin@chromium.org> Owners-Override: Owen Min <zmin@chromium.org> Cr-Commit-Position: refs/heads/main@{#926739} NOKEYCHECK=True GitOrigin-RevId: 40bca4ef13bbf28a3802dce9fce3d35ad557d676

Reland: ------- See diff: https://chromium-review.googlesource.com/c/chromium/src/+/3198263/1..19 On Linux, external protocols calls are delegated to the OS without additional security check. On Windows and Mac (possibly more), it needs to be allowed by the the PolicyBlocklistService explicitely, or it would go through a permission prompt, causing the test to fail. Revert: ------- https://chromium-review.googlesource.com/c/chromium/src/+/3196851 Due to failing test on Windows and Mac. Original commit: ---------------- Developers are surprised that sandboxed iframe can navigate the user toward an external protocol. The navigation in the sandbox is not blocked by sandbox normally, only top-level navigation and opening popups are blocked. So not blocking iframe navigations in general is working as intended. However sandboxed iframe navigation toward external protocol handler are navigating the user toward a different application. Somehow, this can be seen as a new popup or a new top-level navigation. This patch gates access to external protocol behind one of: - allow-popup - allow-top-level-navigation - allow-top-level-navigation-by-user-activation + UserGesture. This is not enforced by content/. So this is not a web feature. This is implemented by chrome/ only. The reason is that Android Webview may do not want to apply these restrictions. Android Webview do not support external protocol by itself, but it let the Android app to listen and intercept the request. We decided to let the Android app full power here, to avoid breaking the existing users. Spec: whatwg/html#7124 Mozilla position: mozilla/standards-positions#581 Webkit position: https://lists.webkit.org/pipermail/webkit-dev/2021-September/031988.html Chrome feature: https://chromestatus.com/guide/edit/5680742077038592 Bug: 1148777, 1253379 Change-Id: Iea92eb8ae6bf1da997dd1433aab4f93fecd879fc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3198263 Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org> Reviewed-by: Richard Coles <torne@chromium.org> Reviewed-by: Dominick Ng <dominickn@chromium.org> Reviewed-by: Devlin <rdevlin.cronin@chromium.org> Reviewed-by: Pavol Marko <pmarko@chromium.org> Reviewed-by: Colin Blundell <blundell@chromium.org> Cr-Commit-Position: refs/heads/main@{#929176} NOKEYCHECK=True GitOrigin-RevId: 038f0de5070fb6c4ccab88ca89aaffa4b41d8d1f

This patch: - Implements the following HTML spec PR: whatwg/html#7654 - Add warning behind a flag. I plan to use them for two versions. - Delay Enterprise policy removal to M117 (~1 year) For security reasons, web browsers started to block navigations toward custom protocols initiated from within a sandboxed iframe. They are allowed, only when normal navigations are already allowed in top-level frame and when opening new popups. See: whatwg/html#7124 And: whatwg/html#2191 (comment) So far so good, but it is hard for some website like https://teams.microsoft.com/ to handle this change. They would like not to block custom scheme, while continuing to block supported ones. An escape hatch could be to mint a new `top-navigation-to-external-protocols` sandbox flags. This would allow web browser to ship the initial security mitigation without breaking them. Bug: whatwg/html#7468 Bug: https://crbug.com/1253379 Change-Id: If32169f5d30651b78a3251f0ec5e174a8a1a8101 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3483941 Reviewed-by: Mike West <mkwst@chromium.org> Reviewed-by: Vasilii Sukhanov <vasilii@chromium.org> Reviewed-by: Yutaka Hirano <yhirano@chromium.org> Reviewed-by: Pavol Marko <pmarko@chromium.org> Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org> Cr-Commit-Position: refs/heads/main@{#979138} NOKEYCHECK=True GitOrigin-RevId: 4ba3104f482c2d234db65b3b86a0ba1b364dfbf5

ArthurSonzogni mentioned this pull request Sep 27, 2021

Disable custom protocols in sandboxed iframe. mozilla/standards-positions#581

Closed

ArthurSonzogni added 2 commits September 27, 2021 18:56

Add myself to the author section.

1748a07

Empty commit to get another CQ run.

2e01096

ArthurSonzogni force-pushed the external-protocol branch from 7400f31 to 2e01096 Compare September 27, 2021 16:57

Fix "resource" being removed.

6ac77ce

annevk reviewed Sep 28, 2021

View reviewed changes

source Show resolved Hide resolved

source Show resolved Hide resolved

source Show resolved Hide resolved

Address annevk@ comments.

6193e45

ArthurSonzogni mentioned this pull request Sep 29, 2021

Disable custom protocols in sandboxed iframe #2191

Closed

annevk reviewed Oct 5, 2021

View reviewed changes

source Show resolved Hide resolved

Address Anne last comment.

d84c9cf

domenic reviewed Oct 12, 2021

View reviewed changes

ArthurSonzogni added 2 commits October 13, 2021 16:02

Address Dominic comments.

cc14855

Remove garbage previously added.

c33811f

ArthurSonzogni and others added 2 commits October 14, 2021 10:33

Address Domenic final comment.

4268069

Editorial tweaks, mostly oxford commas

48348be

domenic approved these changes Oct 15, 2021

View reviewed changes

domenic merged commit dbdc4bd into whatwg:main Oct 15, 2021

ArthurSonzogni deleted the external-protocol branch October 15, 2021 20:27

ArthurSonzogni mentioned this pull request Feb 23, 2022

allow-top-navigation-to-custom-protocols #7654

Merged

3 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Block external protocol handler with sandbox. #7124

Block external protocol handler with sandbox. #7124

ArthurSonzogni commented Sep 27, 2021 •

edited by pr-preview bot

Loading

ArthurSonzogni commented Sep 27, 2021

annevk left a comment

ArthurSonzogni commented Sep 28, 2021

annevk left a comment

domenic Oct 12, 2021

ArthurSonzogni Oct 13, 2021

ArthurSonzogni Oct 13, 2021 •

edited

Loading

domenic Oct 13, 2021

ArthurSonzogni Oct 14, 2021

ArthurSonzogni commented Oct 13, 2021

ArthurSonzogni commented Oct 15, 2021

cdumez commented Nov 3, 2021

domenic commented Nov 3, 2021

Block external protocol handler with sandbox. #7124

Block external protocol handler with sandbox. #7124

Conversation

ArthurSonzogni commented Sep 27, 2021 • edited by pr-preview bot Loading

ArthurSonzogni commented Sep 27, 2021

annevk left a comment

Choose a reason for hiding this comment

ArthurSonzogni commented Sep 28, 2021

annevk left a comment

Choose a reason for hiding this comment

domenic Oct 12, 2021

Choose a reason for hiding this comment

ArthurSonzogni Oct 13, 2021

Choose a reason for hiding this comment

ArthurSonzogni Oct 13, 2021 • edited Loading

Choose a reason for hiding this comment

domenic Oct 13, 2021

Choose a reason for hiding this comment

ArthurSonzogni Oct 14, 2021

Choose a reason for hiding this comment

ArthurSonzogni commented Oct 13, 2021

ArthurSonzogni commented Oct 15, 2021

cdumez commented Nov 3, 2021

domenic commented Nov 3, 2021

ArthurSonzogni commented Sep 27, 2021 •

edited by pr-preview bot

Loading

ArthurSonzogni Oct 13, 2021 •

edited

Loading