W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2013

Re: [whatwg] Sandboxed IFrames and downloads.

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 7 Aug 2013 23:27:02 +0000 (UTC)
To: Mike West <mkwst@google.com>
Message-ID: <alpine.DEB.2.00.1308072312420.9685@ps20323.dreamhostps.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

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:23 UTC