[whatwg] <a download> feedback

[Glenn Maynard]

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.

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.

> 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.
>
> You'd have to have two different URLs, one for inline embedding, and one
> for downloading, just as you do today without download="". This is
> intentional. You shouldn't be able to force a download cross-origin.
>

Why not?

> 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).

> 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.
>
> It works on same-origin files also, regardless of their C-D state.


Every time I've wanted to do this, it was cross-origin.

> 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".
It's strange, and doesn't allow specifying filenames for C-D: inline, which
is also important.

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.)

We're not trying to figure out who's to blame, we're trying to prevent
> there from being anyone to blame in the first place.
>

Anyone can already have links that go straight to a download, with
Content-Disposition: attachment.  The only issue that was raised here, as
far as I recall, is the possibility that if such a link contains malicious
content, this *might* make it appear that the blame for that content is on
an innocent third-party.  There are no *new* security issues, only the
potential for the blame for an existing one to be on the wrong party, and I
think that's a solvable UI problem.

I don't understand the relevance of rel=attachment (what is it?).
>

The "rel=attachment" proposal is to treat the link as if it has a
"Content-Disposition: attachment" header.  Specifying the default filename
would be a separate attribute (and would apply to manual save-as downloads
as well).

-- 
Glenn Maynard