whatwg / html

HTML Standard
https://html.spec.whatwg.org/multipage/
Other
8.11k stars 2.67k forks source link

Consider allowing downloads by user interaction within a sandboxed iframe #5513

Open jashkenas opened 4 years ago

jashkenas commented 4 years ago

Previously: https://github.com/whatwg/html/issues/3236

As of early March, the HTML Standard has been updated to disallow browser downloads within sandboxed iframes by default, but with the ability to re-enable full iframe download capability, with no restrictions, by setting the allow-downloads flag on the sandbox attribute.

This puts us (Observable) — and other websites that allow users to write JavaScript within sandboxed iframes — in a bit of a pickle, because we would like to allow our authors to craft dynamic, JavaScript-driven downloads, but we don’t want to make it possible for them to write drive-by downloads that trigger merely by virtue of a visitor loading the webpage. Without a safe way to allow sandboxed iframes to offer downloads, we’ll have to resort to limiting workarounds, like postMessage()-ing a Blob up to the parent frame for download from there.

In other words, we would like to allow downloads only by user interaction, using the same mechanism in place to guard access to potentially abusable web APIs. User interaction is already used to restrict a sandbox directive with allow-top-navigation-by-user-activation. My hope is that allow-downloads-by-user-activation might be considered as well. It seems like was the original plan for #3236, until October.

Here are some use cases to motivate the feature:

Finally, here’s an example of the type of drive-by download we’d like to prevent with allow-downloads-by-user-activation. The author uses a simulated .click() on a link to force the download of a small SVG file: https://observablehq.com/@msurguy/untitled/3

Thanks in advance for (re)considering!

Paladin commented 4 years ago

I'll add another use case: We have a free application we'll give you in return for getting your email. Unabashed lead generation, yes, but it gives you something of value in return for your info, and does nothing unless you click.

True it's not vital to this use case. But in these days of third party javascript libraries, I'd far prefer it allow only the download you click on. That will build an extra firewall as one more hurdle for malice to clear if one of the third-party library providers has, um, an accident. I'm after anything I can do to stop someone stuffing something into potential customers systems.

sanederchik commented 4 years ago

I'll add another use case too.

Each custom visual made in Power BI is included in an iframe with a allow-scripts flag. Before the update, you could make a fancy interface of whatever you like and place a download button which worked well for loading images, documents and data in different formats. I have several custom visuals where this feature of downloading is really crucial in the company I work.

Now it is impossible because MS Team refused to include a allow-downloads flag. So all these custom visuals have become much less functional, some of them even useless at all.

I am sure if there were an option when using iframe without allow-downloads flag to prompt for user agreement to download, it would be much better and would solve my new problem.

photopea commented 4 years ago

It looks like we invented sandboxed iframes, but gradually, we are turning them into regular iframes.

I am using regular iframes everywhere and it works great. If you are afraid that the page inside a frame will be "evil", don't use it into your page.

AzureTutorialTech commented 4 years ago

We had some power BI custom visuals, which used to export the visual data in custom format than the default way provided by Microsoft. They were functioning great, but now because of this restriction all of our visuals became useless. As @sanederchik suggested, showing a prompt to the user when a sandboxed iframe downloads a file would be a great idea.