Intent to Implement and Ship: Prevent downloads in sandboxed iframes without user activation

[yao...@chromium.org]

Contact emails

yao...@chromium.org

Design doc/Spec

Design doc: https://docs.google.com/document/d/1XfLQd9IbJBPAE4IAOvu4EubUaLuICJrDlrmz0Ya_mqQ

Spec discussion: https://github.com/whatwg/html/issues/3236

Spec review: https://github.com/whatwg/html/pull/4293

Summary

Prevent downloads in sandboxed iframes without user activation

Motivation

Content providers should be able to restrict whether drive-by-downloads can be initiated for content in iframes, to prevent malicious or abusive downloads. Thus, we plan to prevent downloads in sandboxed iframes that lack a user gesture, and this restriction could be lifted via an 'allow-downloads-without-user-activation' keyword, if present in the sandbox attribute list.

Risks

Compatibility

According to HTML & JavaScript usage, for downloads in sandbox without user gesture (NavigationDownloadInSandboxWithoutUserGesture + HTMLAnchorElementDownloadInSandboxWithoutUserGesture) account for about 0.002% page loads so the compatibility risk is small. Besides, the “allow-downloads-without-user-activation” attribute is always an simple solution to any breakage.

Interoperability

No official signals from other browsers. But the web platform test is supposed to alert other browsers.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

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

Web platform test (.tentative) will be added.

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5706745674465280

Requesting approval to ship?

Yes

[Rick Byers]

This seems like an important security mitigation to me. The spec issue/PR seems relatively uncontroversial and likely to land. There's likely no good way to evaluate how much of the 0.002% of page views impacted are things the user wanted vs. didn't want - but given that this applies only to sandboxed iframes which are generally never core to the user experience, it's a pretty decent bet that this is almost all malicious. As always, please keep an ear out for any reports of legitimate use cases being broken, and feel free to circle back on this thread (or blink-api-owners-discuss@) with additional data if you want advice on how to deal with such breakage.

LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6bec4321-f495-45e1-9106-e001ad3193cf%40chromium.org.

[Daniel Bratell]

LGTM2

Usage is a little high, but as Rick, I also think that it's mostly unintended downloads.

/Daniel

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/CAFUtAY-8NW-4OuQ9RfUhCeDjueksmzL1b7u8AkizxuOLebQaPw%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[yao...@chromium.org]

Daniel:

Actually after a brief scan of the sites, most downloads are intended. It's often the case that clicking on a download button is triggering a top navigation, and then a download occurs automatically in the new page inside a sandboxed iframe. Despite of this, we feel it should be an enforcement by default in sandbox as downloads can bring security vulnerabilities to the system, even though currently we don't see much abusive cases.

The plan to deal with those breakages is to notify the sites, possibly by contacting them and/or giving a console warning about upcoming deprecation. This UKM query gives a picture of current usage by sites and the aggregated percentage - it indicates that at this point 253 origins would be affected by this intervention. Top 3 origins account for ~50% usages, top 50 account for ~90%, and top 100 account for ~95%.

--

Yao

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-8NW-4OuQ9RfUhCeDjueksmzL1b7u8AkizxuOLebQaPw%40mail.gmail.com.

[Chris Harrelson]

LGTM to implement. Since research shows that the downloads are mostly intended, could you please deprecate for one release and notify the top sites found by your query?

If the above plan sounds good, please document which milestone you'd like to deprecate on so we can state it on chromestatus and in blog posts.

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/CAFUtAY-8NW-4OuQ9RfUhCeDjueksmzL1b7u8AkizxuOLebQaPw%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

--

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/aeb3f545-3b9e-4457-945a-3b5ae11e6ca6%40chromium.org.

[Daniel Bratell]

Given that data, I'm changing my "lgtm to remove" to "lgtm to deprecate". yaoxia, I'm happy you took a look at the data.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8_WNu8%3DfieS_iRfa7SmxCWLD_%2BohztpM0jYNEZYBRpmw%40mail.gmail.com.

[yao...@chromium.org]

Thanks all for the reviews. We plan to deprecate this in M73 and if things goes well remove it in M74. The chrome status entry is updated.

Just to make sure: doe this mean I had 3 LGTM to deprecate?

[Rick Byers]

On Fri, Jan 25, 2019 at 1:26 PM <yao...@chromium.org> wrote:

Thanks all for the reviews. We plan to deprecate this in M73 and if things goes well remove it in M74. The chrome status entry is updated.

Just to make sure: doe this mean I had 3 LGTM to deprecate?

That's what it sounds like to me.

Looking at the UKM results myself, I'm still skeptical that it reflects much legitimate usage. But we can discuss that off-thread and come back with a request to remove when there's more clarity around what the data is telling us.   

[Chris Harrelson]

On Fri, Jan 25, 2019 at 10:34 AM Rick Byers <rby...@chromium.org> wrote:

On Fri, Jan 25, 2019 at 1:26 PM <yao...@chromium.org> wrote:

Thanks all for the reviews. We plan to deprecate this in M73 and if things goes well remove it in M74. The chrome status entry is updated.

Just to make sure: doe this mean I had 3 LGTM to deprecate?

That's what it sounds like to me.

However: we do have a policy that deprecations must come with a target milestone for removal. I suggest M73 for deprecation and M74 for removal, or if we just missed 73, M73 for deprecation and M74 for removal.

 

Looking at the UKM results myself, I'm still skeptical that it reflects much legitimate usage. But we can discuss that off-thread and come back with a request to remove when there's more clarity around what the data is telling us.   

--

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/CAFUtAY-t2GRgTa-u8Cr9nMgf1m6SaaTSh90s%3DsGUn9U_1qJJqw%40mail.gmail.com.

[Chris Harrelson]

On Fri, Jan 25, 2019 at 10:42 AM Chris Harrelson <chri...@chromium.org> wrote:

On Fri, Jan 25, 2019 at 10:34 AM Rick Byers <rby...@chromium.org> wrote:

On Fri, Jan 25, 2019 at 1:26 PM <yao...@chromium.org> wrote:

Thanks all for the reviews. We plan to deprecate this in M73 and if things goes well remove it in M74. The chrome status entry is updated.

Just to make sure: doe this mean I had 3 LGTM to deprecate?

That's what it sounds like to me.

However: we do have a policy that deprecations must come with a target milestone for removal. I suggest M73 for deprecation and M74 for removal, or if we just missed 73, M73 for deprecation and M74 for removal.

It was pointed out to me that the M74 removal was already noted, and also that my statement above repeats itself. Oops - Friday blues?

Happy deprecating. ;)

[yao...@chromium.org]

I'm re-targeting the removal to M76. One reason is that the impact at this point is 0.002% page loads which is a little big and we hope to wait for developer to adapt to the change and bring the UseCounter down. Another reason is for navigation resulted download, we are expanding the intervention scope to not only "download in a frame", but "download initiated from / occurs in a frame", which includes a few more cases (like top-navigation in a "allow-top-navigation" sandbox) although the additional impact is expected to be small. The UseCounter will also reflect the impact in the new scope. Therefore, re-target the removal to M76.

On Friday, January 25, 2019 at 4:15:30 PM UTC-5, Chris Harrelson wrote:

On Fri, Jan 25, 2019 at 10:42 AM Chris Harrelson <chri...@chromium.org> wrote:

On Fri, Jan 25, 2019 at 10:34 AM Rick Byers <rby...@chromium.org> wrote:

On Fri, Jan 25, 2019 at 1:26 PM <yao...@chromium.org> wrote:

Thanks all for the reviews. We plan to deprecate this in M73 and if things goes well remove it in M74. The chrome status entry is updated.

Just to make sure: doe this mean I had 3 LGTM to deprecate?

That's what it sounds like to me.

However: we do have a policy that deprecations must come with a target milestone for removal. I suggest M73 for deprecation and M74 for removal, or if we just missed 73, M73 for deprecation and M74 for removal.

It was pointed out to me that the M74 removal was already noted, and also that my statement above repeats itself. Oops - Friday blues?

Happy deprecating. ;)

 

Looking at the UKM results myself, I'm still skeptical that it reflects much legitimate usage. But we can discuss that off-thread and come back with a request to remove when there's more clarity around what the data is telling us.   

--
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+unsubscribe@chromium.org.

[yao...@google.com]

Hi blink owners,

I’ve been looking at the common usages of “drive-by download in sandbox” and put them in a doc. It indicates that out of the top 80% site usages, we would consider 80% of them as unintended by the site/user, and we hope to see those sites never “fix” it. Given this, the compat risk should be far below the current number 0.0018%. Would it be okay now to enable the intervention in M76?

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

[Philip Jägenstedt]

Thanks for that analysis, Yao!

This case seems like the most interesting one: "Site embedding another site that converts (or artificially delays) / downloads files. The converting process takes longer than the UserActivation lifespan 5 seconds."

Given the workaround with allow-downloads-without-user-activation and the high ratio of unwanted downloads, shipping this makes sense to me.

Before this ships, can https://github.com/whatwg/html/pull/4293 be moved along? In order to get it actually merged some support from another vendor would be needed. Have you solicited feedback from the relevant implementers?

Note that it is possible and somewhat common to ship without support from other vendors, but then the risk is higher that the PR just sits open and nobody ever notices. Filing bugs for Gecko and WebKit would ensure that someone sees the request and triages it at least.

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/33882da5-bfae-4289-ba90-681c634797a7%40chromium.org.

[Yao Xiao]

Hi Blink owners,

I'm considering making the sandbox restriction stronger by changing it from "disallowing download without gesture" to just "disallowing download", and the sandbox token will also be updated from "allow-downloads-without-user-activation" to "allow-downloads".

The reason is that it's a simpler and more clear-cut policy and is more aligned with our picture of the final state for iframe sandbox. As for compat risk, making the change would bring ~35% more breakage which is not too bad giving that the impact would still fall into the "small impact" category.

Latest metrics show that the impact is 0.0044% vs 0.0059% on M77 Stable (higher than it was on M76 Stable -- 0.002%), and it's estimated that only half of them are legitimate use cases. We can invest in more time and effort to bring the number down. But for our targeting, I'm leaning towards "disallowing all downloads in sandbox" for the reason above.

Please let me know if the LGTMs still hold for the new proposed scope. Thanks!

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Chris Harrelson]

Those numbers sound fine, but in what state is the spec work? Has there been discussion about the new API shape? It appears you already updated the PR, right?

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/33882da5-bfae-4289-ba90-681c634797a7%40chromium.org.

--

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/bbe8b4fa-6cb6-4bfd-ac7f-e00a8d7d7a1a%40chromium.org.

[Yao Xiao]

Chris: There were some discussions with Daniel from Mozilla, on&off the Github thread. In our last conversation Daniel said he is fine with the usage numbers but didn't explicitly say which scope he prefers more. But given that he initially questioned "why not blocking all sandboxed download disregard of user gesture", I would assume he would prefer the new scope more. I'm confirming with him again and still waiting for his response.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/33882da5-bfae-4289-ba90-681c634797a7%40chromium.org.

--
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+unsubscribe@chromium.org.

[Chris Harrelson]

Ok great. My LGTM still stands once you've given the community a chance to re-review the new spec. Given what you said about earlier feedback from Mozilla,

I'd say committing https://github.com/whatwg/html/pull/4293 would suffice.

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/33882da5-bfae-4289-ba90-681c634797a7%40chromium.org.

--
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/bbe8b4fa-6cb6-4bfd-ac7f-e00a8d7d7a1a%40chromium.org.

--

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/f1548f59-b9e9-44d5-8fda-d824b7b63137%40chromium.org.

[Yao Xiao]

Hi blink owners,

Please let me know if the LGTMs still stand given this situation:

Firefox was not sure that adding the "allow-downloads" opt-in is useful (their claims in whatwg/html). I asked for more clarification as I was also confusing about their claims, but we got no responses thereafter. The PR was already approved - Domenic's position was we can ship this in Chrome first, and if it's web compatible we can get another implementer's interest and land the spec change.

For the intervention: the current proposed spec is to block download in sandbox by default and give an "allow-downloads" opt-in. We foresee little compat risks given the low usage and the opt-in, and in the future we could also add "allow-downloads-with-user-activation" if we feel the current option gives out too much power.

Can we ship it now under a lack of responsiveness from Firefox?

Thanks!

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/33882da5-bfae-4289-ba90-681c634797a7%40chromium.org.

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bbe8b4fa-6cb6-4bfd-ac7f-e00a8d7d7a1a%40chromium.org.

--
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+unsubscribe@chromium.org.

[Yoav Weiss]

I wasn't one of the original LGTMs, but LGTM to ship from my perspective.

If we'd later see that usage is extremely low as Anne suspects, we could always remove the opt-in.

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/33882da5-bfae-4289-ba90-681c634797a7%40chromium.org.

--
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/bbe8b4fa-6cb6-4bfd-ac7f-e00a8d7d7a1a%40chromium.org.

--
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/f1548f59-b9e9-44d5-8fda-d824b7b63137%40chromium.org.

--

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/75d9c33b-c388-4a08-aaa2-f51cbb3a9f1d%40chromium.org.

[Chris Harrelson]

+1. Feel free to consider our approval still standing.

[HARSH YADAV]

I have a query  , if i have a application where i want to download the pdf automatically without user gesture inside i-frame ,  does it still prevent download in this case also ??