- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 7 Aug 2013 23:27:02 +0000 (UTC)
- To: Mike West <mkwst@google.com>
- Cc: whatwg@whatwg.org
On Sat, 2 Feb 2013, Mike West wrote: > > 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). Note that this is an implementation choice. A browser could display an inline user interface (e.g. a button in the page, similar to network error pages) or floating user interface (e.g. a dialog, infobar, or download bar) offering the file for download, rather than forcing the download. > 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. I don't really understand why even without a sandbox attribute, a page should be allowed to force a download. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 7 August 2013 23:27:26 UTC