[whatwg] <a download> feedback
ian at hixie.ch
Thu Jun 7 15:42:10 PDT 2012
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg