[whatwg] <a download> feedback

[Ian Hickson]

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.


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

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.


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


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


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


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


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

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.


On Fri, 22 Jul 2011, Alexey Proskuryakov wrote:
> > On Tue, 19 Jul 2011, Alexey Proskuryakov wrote:
> >>
> >> I think that this attribute could be quite confusing, and it will 
> >> likely become more confusing with time, as more platforms arise that 
> >> have creative ways of presenting data to users.
> > 
> > Could you elaborate on what confusion you are expecting here?
> 
> Having rel=attachment and download be named so differently implies that 
> the functionality is different. For example, I'm sure that many people 
> will waste time trying to see what they can do with @download on an 
> iPhone that they couldn't do before with Content-Disposition.

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

I agree that people will waste time trying to work out whether iPhone 
supports download="", but the simplest solution to that (other than, you 
know, supporting it) would be just to document that it doesn't do 
anything, just like Content-Disposition.


> That said, as long as we don't need to honor a file extension provided 
> in @download when it doesn't match Content-Type, it may not matter very 
> much if a page gets the chance to modify the base part of the name.

Indeed the spec strongly suggests not preserving the extension. (It even 
suggests preventing the filenames from having extensions used by 
executables in all cases, regardless of the server's intent. It also 
points out that this is a bit extreme.)


On Fri, 22 Jul 2011, Jonas Sicking wrote:
> 
> The "otherwise, either abort or alert the user that a file is being
> downloaded from a different origin and prompt for a filename" step
> seems to allow to *very* different browser behaviors, resulting in a
> site working in one browser, but not in another.

Yes. Then again, as ap points out above, we're already past that point -- 
there are platforms where you can't download files at all.


> I'm still trying to find a date when we can do a security review about
> this in mozilla though. It still does seem very strange to me that a
> bank site which sends "cache-control: no-store" for a resource in
> order to prevent it from being temporarily stored on the users hard
> drive, can still end up being *permanently* stored on a users hard
> drive. All that's needed is for the user to click a 'yes' button on a
> download dialog while watching a seemingly harmless site.

As the spec is written, a site that sends "Cache-Control: no-store" and 
doesn't send "Content-Disposition: attachment" cannot be forced by a third 
party to have the resource treated as a download. Same-origin, of course, 
it can; but then same-origin it could set "Content-Disposition: 
attachment" today and we'd be in the same situation. So I don't think it 
introduces any new problems.


On Sat, 23 Jul 2011, Julian Reschke wrote:
> 
> What HTML should say is "filename information as defined in RFC 6266" 
> (be less specific) or actually mention both "filename" and "filename*" 
> (the latter allowing interoperable non-ASCII character).

Done.

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