A quick test across browsers would suggest others think it is a reasonable protection to include: both Internet Explorer 10 and Firefox 18 block (ignore) the download attempt in the sandboxed <iframe>. I couldn't find any documentation on either browser doing this, though, or if they have a sandbox flag to allow it.
-- James Ross [email protected] > From: [email protected] > Date: Fri, 15 Feb 2013 09:08:35 +0100 > To: [email protected] > Subject: Re: [whatwg] Sandboxed IFrames and downloads. > > Ping. Is this a terrible idea? :) > > -- > Mike West <[email protected]>, Developer Advocate > Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany > Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 > > > On Sat, Feb 2, 2013 at 7:11 PM, Mike West <[email protected]> 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). > > > > 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. > > > > WDYT? > > > > -- > > Mike West <[email protected]>, Developer Advocate > > Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany > > Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 > >
