Consider blocking downloads from a sandboxed <iframe>.

[mikewest]

Blast from the past: https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Feb/0010.html that came to mind because someone filed another feature request for it against Chrome (duped against crbug #539938).

It's currently possible to force a download by serving a file with a
"Content-Disposition: attachment; filename=..." header. Notably, this
mechanism can be used to download a file with minimal user interaction by
including the resource to be downloaded in an IFrame. This holds even for
sandboxed IFrames, as demonstrated by
http://lcamtuf.coredump.cx/sandboxed.html (clicking that link will download
a file, fair warning).

It seems consistent with the general thought behind the sandbox attribute
that it should control downloads as well as the bits it already locks down.
I'd propose adjusting the spec to include a sandboxed downloads flag,
which, when present, would block all downloads from inside the frame (or,
perhaps only require user confirmation?). This restriction could be lifted
via an 'allow-downloads' keyword, if present in the sandbox attribute's
token list.

Would folks in @whatwg/security be on board with this kind of change?

[mikewest]

(And also folks who should probably be in that group, like @dveditz, @johnwilander, @patrickkettner, @bzbarsky, @ckerschb, @arturjanc, @dbates-wk)

[annevk]

(I've invited those in your list that were not already invited to join the team. For anyone curious, the way we use teams is documented here: https://github.com/whatwg/meta/blob/master/GITHUB-TEAMS.md.)

[bzbarsky]

Seems plausible to me, especially if we can get some telemetry on how often this is used in practice right now. I expect not too much.

[devd]

I am worried about breaking existing clients during the transition. But maybe the telemetry can say how often its being used. I also think we could mitigate this risk by saying "allow downloads only if allow-top-navigation or allow-popups is set". If someone's setting those two flags, not allowing downloads seems weird. I dislike how the list of keywords for sandbox keeps growing.

[lubin2010]

Yes, I agree that we need to collect some telemetry first.

"allow downloads only if allow-top-navigation or allow-popups is set"

@devd One concern is that malicious ads (in sandbox usually with 'allow-popups' to allow new pages to be opened) are automatically downloading say, APKs on user device, and it would not be able to block such behaviors.

[devd]

I forget the spec ... does the popup inherit the sandbox? If not, can't the popup allow the download?

[bzbarsky]

I forget the spec ... does the popup inherit the sandbox?

Yes, unless you set allow-popups-to-escape-sandbox.

[mikewest]

I also think we could mitigate this risk by saying "allow downloads only if allow-top-navigation or allow-popups is set".

1. I'd prefer this be controlled by a clear and distinct mechanism. allow-downloads is simpler to explain and to use.
2. It's not clear to me why "can download" should imply "can navigate". I just want to construct a blob from some data I have lying around and hand it to the user for safekeeping, it seems better to do so without also giving that context the ability to navigate (e.g. just sandbox="allow-download")

[lubin2010]

I forget the spec ... does the popup inherit the sandbox? If not, can't the popup allow the download?

As @bzbarsky said, the popup inherits the sandbox unless you set allow-popups-to-escape-sandbox. But auto popup would be blocked by popup blockers that most browsers have, while auto download won't. So popups are guarded by user gestures (interactions), but not downloads.

[xyaoinum]

Hi folks, I’m looking to spec out the details and add that to Chrome. Here’s my proposal:

We are targeting to prevent only downloads that doesn’t involve a user gesture, which include synthetic <a download> link clicks, as well as navigations to non-web-renderable content without user gesture. And the click or navigation occurs in a sandboxed browsing context with download flag. “allow-downloads” can be used to turn off this restriction.

This implies: Alt-Click, Drag-And-Drop, Context Menu triggered download won’t be blocked. Top-level-navigation to a download won’t be blocked.

The reason to allow top level navigation to a download is: 1) it’s a clear mechanism to spec out, as this is implied by the fact that top navigation doesn't inherit the sandbox; on the other hand, popup to a download will be blocked as it inherit the sandbox. 2) sandbox already disallow top-level-navigation, and if the client opt in, it makes sense to trust it regardless whether it results in a download or not.

I'm happy to see what people are thinking.

[johnwilander]

We use “-by-user-activation” when that’s a requirement for the capability. Should we say “allow-download-without-user-activation” here?

[xyaoinum]

We use “-by-user-activation” when that’s a requirement for the capability. Should we say “allow-download-without-user-activation” here?

sounds reasonable to me

[domenic]

Hmm, aren't all sanbbox allow-X flags implicitly "without user activation"? Is there a reason to be more explicit with this one?

[xyaoinum]

Hmm, aren't all sandbox allow-X flags implicitly "without user activation"? Is there a reason to be more explicit with this one?

I looked at the spec, the only flags involving the notion of user activation is:

• "top-level navigation without user activation flag", suppressed by "allow-top-navigation" keyword.
• "top-level navigation with user activation flag", suppressed by either "allow-top-navigation" or "allow-top-navigation-by-user-activation" keyword.

If we single out the 1st one, the "allow" keyword is implicitly "without user activation", but looking them together it's not necessarily so. But it does suggest another option which is to use 2 flags and keywords in the same way as "top-level navigation" does.

Here are some options and my thoughts:

1. "downloads without user activation flag", suppressed by "allow-downloads" keyword.
   -- Simple. Conform to existing practice if we can assume "allow" is implicitly "without user activation", which is questionable.
2. "downloads without user activation flag", suppressed by "allow-downloads-without-user-activation" keyword.
   -- More clear on what it controls. But by just looking at the keyword without seeing the restriction, it tends to imply it still won't allow download with user activation, although restriction is only on "without activation".
3. "downloads without user activation flag", suppressed by "allow-downloads" keyword.
   "downloads with user activation flag", suppressed by either "allow-downloads" or allow-downloads-by-user-activation"" keyword.
   -- Most flexible. Conform to existing practice. At the cost of growing flags / keywords by 2, and more breakage to the web compared with 1) and 2).

I personally is in favor of 1) for simplicity, but all options make sense to me. Happy to know what other people think.

[domenic]

I meant all the others. I.e. we say allow-scripts, not allow-scripts-without-user-activation. Etc. We don't involve the concept of user activation (even in the flag name) except in the one case of top navigation, where we have both and need to contrast the two.

[xyaoinum]

I meant all the others. I.e. we say allow-scripts, not allow-scripts-without-user-activation. Etc. We don't involve the concept of user activation (even in the flag name) except in the one case of top navigation, where we have both and need to contrast the two.

My proposal of the restriction was targeting at just to prevent download without user activation (the definition of that is either the navigation-to-download is without user activation, or <a download> click is synthetic), and this restriction is different from all the others. Of course this is also debatable - maybe we can prevent download irrespective of user activation. In that case, "allow-downloads" makes total sense.

[domenic]

Oh, I see. Sorry, I completely missed that key point from your original post... somehow. In that case I think including -without-user-activation makes perfect sense, and I apologize for wasting time on the back and forth.

[sirdarckcat]

Drive-by comment: would the sandboxed window have a way to know that the download failed?

[xyaoinum]

Drive-by comment: would the sandboxed window have a way to know that the download failed?

I'm thinking giving devtool messages, similar to what Chrome currently does when blocking the top-navigation, popups, etc.

[xyaoinum]

cc @ehsan : I'm interested to see if FireFox is interested in implementing, so that the spec change review can be moved forward. Unconfirmed bug on Firefox.

[annevk]

@xyaoinum if we think it's reasonable to disable this retroactively, why do we need allow-download-without-user-activation? Are there web developers asking for that capability?

[xyaoinum]

@xyaoinum if we think it's reasonable to disable this retroactively, why do we need allow-download-without-user-activation? Are there web developers asking for that capability?

The opt-in feature was originally proposed for compat concern (i.e. was not explicitly asked by any web developer). But from Chrome's statistics collected later, we do have seen both legitimate & abusive cases:

Legitimate:
-- Site sandbox embedding a 3rd party site that converts (or artificially delays) & downloads files. Even though it's triggered by a click, the converting process takes longer than user gesture expiration time (currently 5s in Chrome).
-- Site triggering download by embedding it in a dynamically created sandboxed iframe which is 1st party. The reason to do this is perhaps to limit its privilege.

Abusive:
-- Some URL shortening service: before user go to the destination URL, the transition page is sandbox embedding an advertiser site, and some of those do automatic download. It's hard to deterministically see a download as the advert selection is sort of random.

The "drive-by download in sandbox" behavior is seen on 0.002% page loads, and it's estimated that about 70% of those are abusive cases. Therefore, I think the best thing to do is to intervene by default, and give options to lift the restriction.

[xyaoinum]

ping @annevk and @dveditz again.

[annevk]

@xyaoinum I think the thing I'm missing is justification for the new value to opt out of the restriction. @dveditz asked about this above and I don't think there was an answer unless I overlooked it.

[xyaoinum]

@annevk : There are both legit cases and abusive cases right now - roughly half and half. To restrict by default would help with abusive cases like automatic download from advertisement. And I can imagine some embedders want to just allow download while restricting other behaviors. e.g. embedded video converter sites .

[annevk]

I guess I'd like to see something stronger. How many embedders would adopt this new value?

[xyaoinum]

@annevk : We reached to a few sites (15+) on the top of the list and only developers from AOL and Google responded. And they both have adopted / are ready to adopt the change.

I think many embedders haven't adopted the new value only because they're not aware of the change, as I see no reason they wouldn't adopt if download is expected to be a legitimate use case on the embedded site. And the cost of adopting is also trivial.

I feel standardizing this is a step forward to make more developers aware of it.

[xyaoinum]

@annevk / @dveditz : Want to confirm if this aligns with your thoughts: Compared to allow-downloads, were you saying you would be in favor of allow-downloads-with-gesture or "no allow- token at all"? And what kind of justification do you need to answer "How many embedders would adopt this new value"?

I think we could do the latter options and let those intervened download to be resumable through a browser UI as a last resort to the breakages (repeated below for reference).

~0.002% page loads are having those legitimate download without gesture in sandbox:

• Trigger after a count-down timer so that the prior gesture is lost.
• Sites tend to instantiate download inside sandboxed iframe just to play ultra safe (e.g. the untrusted cross-origin link / buggy same-origin link could turn into a navigation rather than a download, but at least the sandbox could prevent it from doing unintended things further). The iframe can be dynamically created or in a pop-up page, so that the prior gesture is lost.

[xyaoinum]

friendly ping @annevk and @dveditz . Please let me know if you prefer other options over the proposed option - to block all downloads in sandbox and to use "allow-downloads" to opt-out.

Or, as Domenic pointed out in the latest spec review, if you don't have strong objection but are just uncertain about how embedders would react, maybe it's reasonable for Chrome trying to ship the restriction, and if it's web-compatible we can then proceed with the spec change?

[jkarlin]

FWIW, I'm in favor of starting with allow-downloads which makes the frame like any other frame today, as that covers the use cases that we've come across. I'm happy to add allow-downloads-with-gesture down the road if start wanting it.

[jashkenas]

Hi folks 👋,

(With all due apologies for posting on a closed ticket), over at Observable, we run a platform that allows our notebook authors to write arbitrary JavaScript within sandboxed iframes, and folks that use Chrome Canary are beginning to be affected by this change. I imagine that the JSBins and Codepens and their friends and family will begin running into this soon as well.

In general, we want to give our users as much of the power of the web platform as possible (in a sandboxed iframe), while maintaining the basic security rules that make normal web pages less dangerous. Not allowing drive-by downloads is definitely one of them!

Because the allow-downloads flag is all or nothing as specified, we either are forced to give our notebook authors the ability to write drive-by downloads, or we cannot allow them to offer downloads within the notebook at all — and we have to provide alternative APIs to trigger a download by other mechanisms, such as postMessage()-ing a Blob up to the parent frame.

Any interest in giving allow-downloads-by-user-activation a second chance?

[jkarlin]

Thanks for the report and question. Are you confident that the required user gesture would cover the use cases your users have? Could you describe some example use cases?

[jashkenas]

Thanks for the report and question. Are you confident that the required user gesture would cover the use cases your users have? Could you describe some example use cases?

Happy to.

In general, we would like to allow our users to create notebooks that allow readers to download computed content — images, CSV files, JSON, generated SVGs, and so on. We currently provide a DOM.download() function in the standard library, which wraps up the pattern of taking a JS Blob, and connecting it to an HTML button for download.

Here’s a coronavirus tracking graphic that allows readers to download the source data that backs it as a TSV formatted text file: https://observablehq.com/@elaval/coronavirus-worldwide-evolution

Here’s an npm package dependency visualizer notebook that allows you to download the resulting graphviz image as either an SVG or PNG file: https://observablehq.com/@mbostock/package-dependencies

Here’s a fancy exploration of building buckyball models out of toilet paper tube strips, which includes an interactive simulation, which you can manipulate and then download the currently configured graph as a JSON file: https://observablehq.com/@rreusser/toiletpaperfullerenes-and-charmin-nanotubes

Here’s a "chart-o-matic", where you can edit the textarea to generate a different bubble map, and then download the resulting image as a PNG or SVG: https://observablehq.com/@mbostock/bubble-o-matic

We would like to allow authors to create download links, buttons and interactions in their sandboxed iframes, without also allowing malicious drive-by downloads, triggered immediately upon loading a notebook. Here’s an example of a notebook where an author is using a simulated "click" event to force a download of a small SVG: https://observablehq.com/@msurguy/untitled/3 We’d like to use something like allow-downloads-by-user-activation to prevent this.

[annevk]

Since this is closed, it would be better if this moved into a new dedicated issue for that feature.

[jashkenas]

@annevk Is that something you’d like me to do? Or is it better if WhatWG contributors open new tickets for previously debated issues?

[annevk]

@jashkenas since you have the novel use case it'd be great if you could do it. When there's new information it's always cool to open a new issue.

[jashkenas]

Discussion moved to: #5513

[photopea]

Guys, I am the author of www.Photopea.com . It is a photo editor, which is used by about 8 million people per month.

There are several hundreds of schools, who use it at their website in <iframe>. This way, Photopea checks the URL of the parent frame and hides ads in the editor (they can not use my main version at www.Photopea.com because of ads).

Since the latest Chrome release, Photopea in iframe can not save files to the computer. I am receiving about 4 emails per hour from teachers about the saving not working.

What attributes should teachers give to the iframe to allow the downloads? sandbox="allow-downloads" does not seem to help. I made a demo here: https://jsfiddle.net/vaqtb4oe/

So far, I am recommending them to use Firefox, but many of them use Chromebooks, where Google has a "monopoly" on browsers.

[xyaoinum]

@photopea The "allow-downloads" is the right token. However, for your demo, the download would fail because the embedding site jsfiddle.net embeds your demo page in their sandboxed iframe. jsfiddle.net will need to update their sandbox attributes first if they intend to allow download in its subframes. My guess is the schools' website has sandboxed your www.Photopea.com site, so they will need to fix their sandbox first.

If you have more questions, please file a bug to https://bugs.chromium.org/p/chromium as this is a Chrome specific issue.