[whatwg] <a download> feedback

[Ian Hickson]

On Sat, 25 Feb 2012, Glenn Maynard wrote:
> On Wed, Feb 15, 2012 at 6:19 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Fri, 22 Jul 2011, Glenn Maynard wrote:
> > > 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.)
> >
> > Well you're never _required_ to. The client can always use the 
> > server-provided name, even if it's "download.cgi" or something.
> 
> The point was that it's inconvenient for users to name downloaded files 
> by hand; it's something that should be done for them in the overwhelming 
> majority of cases.

I don't think we disagree on this point. That's why this feature allows 
the author to set the name, after all.


> > Correct. That's intentional. If a victim server doesn't explicitly say 
> > that the resource is an attachment, then we don't want to allow a 
> > hostile server to trick the user into downloading the file at all. 
> > It's not so much that the server can't specify the filename, so much 
> > as you can't say that the file should be downloaded in the first 
> > place. It should show a warning and let the user select the filename.
> 
> Why?  No new security issues have been suggested, as far as I recall, in 
> allowing links that trigger downloads cross-origin.

"Thank you for wanting to play SuperHotExampleGame! To play our super hot 
example game, you must first _download this license file_ and upload it to 
our license verification server:

   [ No file selected  (Browse) ]  ( Upload license file... )

...where "download this license file" points to a confidential file, e.g. 
the user's bank account home page with their bank account number or some 
confidential project page on an intranet site or some such.


> > > 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.
> >
> > Only if the image is cross-origin.
> 
> On nontrivial sites, download links are *usually* cross-origin (eg. 
> resources hosted on services like S3).

Why isn't C-D sufficient in these cases?

download="" is only really useful for intermediate authors who don't have 
sufficient control over their servers to set headers.


> > > 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.
> >
> > It's not repurposing, it's just using it for a case where before there 
> > would be a download but no given filename: now there can be a filename 
> > given in the markup.
> 
> It's repurposing Content-Disposition by using it to say "this resource opts
> into allowing cross-origin sites to specify filenames using @download".

No, it's using it to say "this resource is an attachment". It's just that 
things that aren't attachments can't be downloaded from another origin.


> It's strange, and doesn't allow specifying filenames for C-D: inline, which
> is also important.

That is supported also, as far as I can tell.


> If you really think that allowing sites to trigger downloads and set 
> filenames cross-origin has security issues, then use a separate header 
> like "Allow-Forced-Downloads" to make that statement; don't derive it 
> from C-D. (But I don't know what security problem that is.)

I don't see anything wrong with using C-D here. We're using it exactly for 
its defined purpose. We're just more lax for same-origin downloads.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'