Intent to Ship: Block external protocol in sandboxed iframe.

[Arthur Sonzogni]

Contact emails

arthurs...@chromium.org

Explainer

https://github.com/whatwg/html/issues/2191

Specification

https://github.com/whatwg/html/pull/7124
https://github.com/whatwg/html/pull/7654

Design docs

https://docs.google.com/document/d/1hHjxQk1yLoC0ioBBYpIq4JJYAwj9sJfR5b62QcLt1eM/edit

Summary

Block sandboxed iframe from opening external applications. To enable it again, use one of the pre-existing flags: - allow-popups - allow-top-navigation - allow-top-navigation-with-user-activation Or the new dedicated one: - allow-top-navigation-to-custom-protocols

Blink component

Blink>SecurityFeature>IFrameSandbox

Search tags

sandbox, iframe, allow-top-navigation, allow-top-navigation-to-custom-protocols

TAG review

We think this is not needed. Handling external applications is at the boundary of the web platform. This is a rather minor security fix to break malicious ads.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

# Compatibility risk: This prevents sandboxed iframe to navigate users toward external applications. Goal is to fill a hole in the sandbox. We want to break existing malicious ads. This is an intended breakage. UMA: 0.015% of the pages are impacted. Positively or negatively. - https://chromestatus.com/metrics/feature/timeline/popularity/4058 UKM: - https://docs.google.com/document/d/118tI2B4Cwk0bX4cgWKvnWCbbu4sq6un-MGfT90o8Oi4 - https://docs.google.com/document/d/1s8bp61FK6VSpzbhy8oLW0R8vOFDdhXdrsYlCSnlvgFA We contacted several websites. Some confirmed they will be positively impacted. Microsoft Teams, the #1 requested adding "allow-top-navigation-to-custom-scheme" to opt-out from this feature individually. We believe the compatibility risk is low: - 0.015% impacted page is rather low - An easy opt-out sandbox flag: "allow-top-navigation-to-custom-scheme" + the pre-existing ones. - An Enterprise policy opt-out : https://chromeenterprise.google/policies/#SandboxExternalProtocolBlocked. - A Finch kill switch. - We plan to do 2 versions with a Devtool warning only. Then enforcing it on M103. - Most likely, most impacted website will be "positively impacted", as intended. As a last resort using one of the 4 sandbox flags must be enough for everyone.

# Interoperability risk Chrome, Firefox and Safari are going to implement it, or have already shipped it partially (Safari).

Gecko: Worth prototyping (https://github.com/mozilla/standards-positions/issues/581) https://github.com/whatwg/html/pull/7654#:~:text=overall%20this%20seems%20good%20though%20and%20we%20might%20pick%20this%20up%20soonish%20in%20firefox

WebKit: Shipped/Shipping (https://lists.webkit.org/pipermail/webkit-dev/2021-September/031988.html)

Safari already shipped it the initial version without the new "allow-top-navigation-to-custom-protocols" opt-out flag. WebKit had to introduce a quirk to keep Microsoft Teams working. Safari will replace the quirk with the standardized flag. https://github.com/whatwg/html/pull/7654#issuecomment-1048951254

Web developers: Strongly positive (https://github.com/whatwg/html/issues/2191)

Amazon & multiple independent security researcher have filled feature request:

- https://crbug.com/1148777

- https://crbug.com/1250415

- https://github.com/whatwg/html/issues/2191

Other signals:

Ergonomics

N/A

Activation

N/A

Security

This is a web-platform security fix.

Debuggability

The following Devtool console error message is shown:

Warning: After Chrome M103, navigation toward external protocol will be blocked by sandbox, if it doesn't contain any of: 'allow-top-navigation-to-custom-protocols', 'allow-top-navigation-by-user-activation', 'allow-top-navigation', or 'allow-popups'. See https://chromestatus.com/feature/5680742077038592 and https://chromeenterprise.google/policies/#SandboxExternalProtocolBlocked

Enforced:

Navigation to external protocol blocked by sandbox, because it doesn't contain any of: 'allow-top-navigation-to-custom-protocols', 'allow-top-navigation-by-user-activation', 'allow-top-navigation', or 'allow-popups'. See https://chromestatus.com/feature/5680742077038592 and https://chromeenterprise.google/policies/#SandboxExternalProtocolBlocked

Is this feature fully tested by web-platform-tests?

No

This is at the boundary of the web platform (external apps). This is not observable from within a document. So WPT are not possible. There are browser_tests instead

Flag name

SandboxExternalProtocolBlocked

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1253379

Launch bug

https://crbug.com/1260288

Estimated milestones

DevTrial on desktop

96

DevTrial on android

96

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5680742077038592

Links to previous Intent discussions

Ready for Trial: https://groups.google.com/a/chromium.org/g/blink-dev/c/yF9j_5gxLgo

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

LGTM1

On Mon, Mar 7, 2022 at 10:45 AM Arthur Sonzogni <arthurs...@chromium.org> wrote:

Contact emails

arthurs...@chromium.org

Explainer

https://github.com/whatwg/html/issues/2191

Specification

https://github.com/whatwg/html/pull/7124
https://github.com/whatwg/html/pull/7654

Design docs

https://docs.google.com/document/d/1hHjxQk1yLoC0ioBBYpIq4JJYAwj9sJfR5b62QcLt1eM/edit

Summary

Block sandboxed iframe from opening external applications. To enable it again, use one of the pre-existing flags: - allow-popups - allow-top-navigation - allow-top-navigation-with-user-activation Or the new dedicated one: - allow-top-navigation-to-custom-protocols

Blink component

Blink>SecurityFeature>IFrameSandbox

Search tags

sandbox, iframe, allow-top-navigation, allow-top-navigation-to-custom-protocols

TAG review

We think this is not needed. Handling external applications is at the boundary of the web platform. This is a rather minor security fix to break malicious ads.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

# Compatibility risk: This prevents sandboxed iframe to navigate users toward external applications. Goal is to fill a hole in the sandbox. We want to break existing malicious ads. This is an intended breakage. UMA: 0.015% of the pages are impacted. Positively or negatively. - https://chromestatus.com/metrics/feature/timeline/popularity/4058 UKM: - https://docs.google.com/document/d/118tI2B4Cwk0bX4cgWKvnWCbbu4sq6un-MGfT90o8Oi4 - https://docs.google.com/document/d/1s8bp61FK6VSpzbhy8oLW0R8vOFDdhXdrsYlCSnlvgFA

(Those are unfortunately Google-only docs, which I doubt we can share more broadly as is)

 

We contacted several websites. Some confirmed they will be positively impacted. 

Microsoft Teams, the #1 requested adding "allow-top-navigation-to-custom-scheme" to opt-out from this feature individually.

It's reassuring to hear they'd be willing to use an opt-out.

Have you reached out to others on that list? It seems like tackling the top ~3 would significantly reduce the risk.

We believe the compatibility risk is low: - 0.015% impacted page is rather low - An easy opt-out sandbox flag: "allow-top-navigation-to-custom-scheme" + the pre-existing ones. - An Enterprise policy opt-out : https://chromeenterprise.google/policies/#SandboxExternalProtocolBlocked. - A Finch kill switch. - We plan to do 2 versions with a Devtool warning only. Then enforcing it on M103.

Please make sure you use CountDeprecation, to get deprecation reports sent automatically. (unless there are particular technical reasons that make this more complex than it should be. If that's the case, let's discuss more)

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH7Q68V6A8bV-gVowsth70U3kOP7a-N2aZ39LG9R9ry3Q0eYcA%40mail.gmail.com.

[Arthur Sonzogni]

We contacted several websites. Some confirmed they will be positively impacted. 

Microsoft Teams, the #1 requested adding "allow-top-navigation-to-custom-scheme" to opt-out from this feature individually.

It's reassuring to hear they'd be willing to use an opt-out.

Have you reached out to others on that list? It seems like tackling the top ~3 would significantly reduce the risk.

I confirm I sent an email for every website we see: the top 8 on Windows and a few others on Android. I asked them to confirm reception.

 

Please make sure you use CountDeprecation, to get deprecation reports sent automatically. (unless there are particular technical reasons that make this more complex than it should be. If that's the case, let's discuss more)

This can't only be used in blink unfortunately. This is about navigation, and happens when we are out of handlers, before calling external applications. I can't make use of CountDeprecation here. It is not impossible to create new IPCs and get it plumbed to the renderer process, but that's probably more complex than what it deserves.

[Yoav Weiss]

That's probably true when considering only this particular intent, but might be worthwhile to create the infra to enable this as this seems to be a recurrent pattern.

 

[Mike Taylor]

On 3/7/22 8:45 AM, Yoav Weiss wrote:

On Mon, Mar 7, 2022 at 2:35 PM Arthur Sonzogni <arthurs...@chromium.org> wrote:

We contacted several websites. Some confirmed they will be positively impacted. 

Microsoft Teams, the #1 requested adding "allow-top-navigation-to-custom-scheme" to opt-out from this feature individually.

It's reassuring to hear they'd be willing to use an opt-out.

Have you reached out to others on that list? It seems like tackling the top ~3 would significantly reduce the risk.

I confirm I sent an email for every website we see: the top 8 on Windows and a few others on Android. I asked them to confirm reception.

Thanks - looking at the list, some of them seem to have obvious "open a native app" use-cases, like Microsoft Teams. Others... not so obvious.

If the primary motivation is to break malicious ads, would it make sense to further require a secure context for the sandboxed iframe? (Maybe this question is nonsense, I'm not a security expert). Do we know what the breakdown is between http/non-secure and https/secure for iframes causing these kinds of external app navigations?

 

Please make sure you use CountDeprecation, to get deprecation reports sent automatically. (unless there are particular technical reasons that make this more complex than it should be. If that's the case, let's discuss more)

This can't only be used in blink unfortunately. This is about navigation, and happens when we are out of handlers, before calling external applications. I can't make use of CountDeprecation here. It is not impossible to create new IPCs and get it plumbed to the renderer process, but that's probably more complex than what it deserves.

That's probably true when considering only this particular intent, but might be worthwhile to create the infra to enable this as this seems to be a recurrent pattern.

Agree it sounds like a useful tool to have down the road. I can't speak for Yoav, but can we at least get a bug on file with enough context for someone else to pick up?

thanks,
Mike

[Arthur Sonzogni]

On Monday, March 7, 2022 at 3:47:11 PM UTC+1 Mike Taylor wrote:

On 3/7/22 8:45 AM, Yoav Weiss wrote:

On Mon, Mar 7, 2022 at 2:35 PM Arthur Sonzogni <arthurs...@chromium.org> wrote:

We contacted several websites. Some confirmed they will be positively impacted. 

Microsoft Teams, the #1 requested adding "allow-top-navigation-to-custom-scheme" to opt-out from this feature individually.

It's reassuring to hear they'd be willing to use an opt-out.

Have you reached out to others on that list? It seems like tackling the top ~3 would significantly reduce the risk.

I confirm I sent an email for every website we see: the top 8 on Windows and a few others on Android. I asked them to confirm reception.

Thanks - looking at the list, some of them seem to have obvious "open a native app" use-cases, like Microsoft Teams. Others... not so obvious.

If the primary motivation is to break malicious ads, would it make sense to further require a secure context for the sandboxed iframe? (Maybe this question is nonsense, I'm not a security expert). Do we know what the breakdown is between http/non-secure and https/secure for iframes causing these kinds of external app navigations?

Yes, this is probably worth doing. However, this would be a different topic, spec & impacted users. I think this would be more of an additional project, and ideally we would do both if possible.

There are no metrics about security/non-secure context that I am aware of.

Please make sure you use CountDeprecation, to get deprecation reports sent automatically. (unless there are particular technical reasons that make this more complex than it should be. If that's the case, let's discuss more)

This can't only be used in blink unfortunately. This is about navigation, and happens when we are out of handlers, before calling external applications. I can't make use of CountDeprecation here. It is not impossible to create new IPCs and get it plumbed to the renderer process, but that's probably more complex than what it deserves.

That's probably true when considering only this particular intent, but might be worthwhile to create the infra to enable this as this seems to be a recurrent pattern.

Agree it sounds like a useful tool to have down the road. I can't speak for Yoav, but can we at least get a bug on file with enough context for someone else to pick up?

That's the reasonable thing to do. Here is the bug:

https://bugs.chromium.org/p/chromium/issues/detail?id=1303603

[Mike Taylor]

On 3/7/22 10:37 AM, Arthur Sonzogni wrote:

On Monday, March 7, 2022 at 3:47:11 PM UTC+1 Mike Taylor wrote:

On 3/7/22 8:45 AM, Yoav Weiss wrote:

On Mon, Mar 7, 2022 at 2:35 PM Arthur Sonzogni <arthurs...@chromium.org> wrote:

We contacted several websites. Some confirmed they will be positively impacted. 

Microsoft Teams, the #1 requested adding "allow-top-navigation-to-custom-scheme" to opt-out from this feature individually.

It's reassuring to hear they'd be willing to use an opt-out.

Have you reached out to others on that list? It seems like tackling the top ~3 would significantly reduce the risk.

I confirm I sent an email for every website we see: the top 8 on Windows and a few others on Android. I asked them to confirm reception.

Thanks - looking at the list, some of them seem to have obvious "open a native app" use-cases, like Microsoft Teams. Others... not so obvious.

If the primary motivation is to break malicious ads, would it make sense to further require a secure context for the sandboxed iframe? (Maybe this question is nonsense, I'm not a security expert). Do we know what the breakdown is between http/non-secure and https/secure for iframes causing these kinds of external app navigations?

Yes, this is probably worth doing. However, this would be a different topic, spec & impacted users. I think this would be more of an additional project, and ideally we would do both if possible.

There are no metrics about security/non-secure context that I am aware of.

OK, thanks for confirming (not trying to blow up your scope in this intent, I promise).

Please make sure you use CountDeprecation, to get deprecation reports sent automatically. (unless there are particular technical reasons that make this more complex than it should be. If that's the case, let's discuss more)

This can't only be used in blink unfortunately. This is about navigation, and happens when we are out of handlers, before calling external applications. I can't make use of CountDeprecation here. It is not impossible to create new IPCs and get it plumbed to the renderer process, but that's probably more complex than what it deserves.

That's probably true when considering only this particular intent, but might be worthwhile to create the infra to enable this as this seems to be a recurrent pattern.

Agree it sounds like a useful tool to have down the road. I can't speak for Yoav, but can we at least get a bug on file with enough context for someone else to pick up?

That's the reasonable thing to do. Here is the bug:

https://bugs.chromium.org/p/chromium/issues/detail?id=1303603

Thanks, LGTM2.

[Chris Harrelson]

LGTM3

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/82e3afc3-05c0-087b-61a8-98161d1cc98c%40chromium.org.