[whatwg] Forcing a download

[Glenn Maynard]

On Fri, Jul 22, 2011 at 2:58 AM, Ian Hickson <ian at hixie.ch> wrote:
> As Ian says above, if the user is savvy enough to
> right-click, the user is likely not going to find it difficult to give the
> file a name either.

(But again, just because I'm able to do something by hand doesn't mean that
I should be required to.)

> Is there any reason to use CORS here at all? It seems like the simpler
> solution would be the following:
>   - if the received resource has a Content-Disposition: attachment header
>     that specifies a filename, use that.
>   - otherwise, if the received resource has a Content-Disposition header
>     that specifies a filename, and the resource is same-origin, use that
>     filename.
>   - otherwise, if the received resource is same-origin and the
>     download="" attribute specifies a filename, use that.
>   - otherwise, if the received resource has a Content-Disposition:
>     attachment header and the download="" attribute specifies a filename,
>     use the filename from the attribute.
>   - otherwise, if the received resource is same-origin then derive a
>     filename from the resource.
>   - otherwise, either abort or alert the user that a file is being
>     downloaded from a different origin and prompt for a filename.

This doesn't allow cross-origin files to be linked to as both attachment and
inline resources.  Your suggested workaround for the PDF case is to have two
links, but in order to do that cross-origin you'd need to add
"Content-Disposition: attachment" on the file, so that wouldn't work: they'd
both become download links.

Similarly, sites show an image inline and have a separate link to download
it.  For that link to use @download, C-D: attachment would have to be
applied to the images, which is clearly unwanted.

This breaks every case where I've wanted this functionality in the past.  It
doesn't make sense for @download to only work on files which are already
marked as such by Content-Disposition.

If you really want cross-origin @download to be opt-in, then use a separate
header for it ("Allow-Forced-Downloads: *"); don't repurpose C-D like this.

>> So, if a hosting service doesn't want to allow executable files, it
>> won't show files as executable from their own download pages, which is
>> what should matter as far as that site's trust is concerned.  People
>> using this mechanism to serve executable files from external links may
>> be annoying, but it shouldn't cause trust issues.
>
> This implies the hosting service has to prevent pages from including
> download="" attributes pointing to itself, of course.

My point was the opposite; they don't need to do that.  They're not
providing the trojan-as-JPG from their own download pages, and if an
external site links to a file and changes the extension to .EXE, then it's
the external site that users should blame, not the download site.

(That's what I believe will happen, anyhow, since that's the site in the
address bar when the user clicks the link, which I expect is what users
examine, not eg. the small "from:" text in Firefox's save-or-open dialog.  I
think that's sensible, because I don't think it's reasonable to expect users
to make security decisions involving multiple sites; it's hard enough to get
them to look at the address bar before entering a password.)

-- 
Glenn Maynard