[whatwg] a rel=attachment

2011/7/15 Jonas Sicking <jonas at sicking.cc>

> 2011/7/14 Ian Fette (????????) <ifette at google.com>:
> > Many websites wish to offer a file for download, even though it could
> > potentially be viewed inline (take images, PDFs, or word documents as an
> > example). Traditionally the only way to achieve this is to set a
> > content-disposition header. *However, sometimes it is not possible for
> the
> > page author to have control over the response headers sent by the
> > server.*(A related example is offline apps, which may wish to provide
> > the user with
> > a way to "download" a file stored locally using the filesystem API but
> again
> > can't set any headers.) It would be nice to provide the page author with
> a
> > client side mechanism to trigger a download.
> >
> > After mulling this over with some application developers who are trying
> to
> > use this functionality, it seems like adding a "rel" attribute to the <a>
> > tag would be a straightforward, minimally invasive way to address this
> use
> > case. <a rel=attachment href=blah.pdf> would indicate that the browser
> > should treat this link as if the response came with a
> content-disposition:
> > attachment header, and offer to download/save the file for the user.
>
> We've discussed a different solution to the same problem at mozilla.
> The solution we discussed was allowing FileSaver to in addition to
> taking a blob argument, allow it to take a url argument.
>
> One concern which was brought up was the ability to cause the user to
> download a file from a third party site. I.e. this would allow
> evil.com to trick the user into downloading an email from the users
> webmail, or download a page from their bank which contains all their
> banking information. It might be easier to then trick the user into
> re-uploading the saved file to evil.com since from a user's
> perspective, it looked like the file came from evil.com
>
> Another possible attack goes something like:
> 1. evil.com tricks the user into downloading sensitive data from bank.com
> 2. evil.com then asks the user to download a html from evil.com and
> open the newly downloaded file
> 3. the html file contains script which reads the contents from the
> file downloaded from bank.com and sends it back to evil.com
>
> Step 1 and 2 require the user to answer "yes" to a dialog displayed by
> the browser. However it's well known that users very often hit
> whichever button they suspect will make the dialog go away, rather
> than actually read the contents of the dialog.
> Step 3 again requires the user to answer "yes" to a dialog displayed
> by the browser in at least some browsers. Same caveat applies though.
>
> One very simple remedy to this would be to require CORS opt-in for
> cross-site downloads. For same-site downloads no special opt-in would
> be required of course.
>
> It's also possible that it would be ok to do this without any opt-ins
> since there are a good number of actions that the user has to take in
> all these scenarios. Definitely something that I'd be ok with
> discussing with our security team.
>
> Tentatively I would feel safer with the CORS option though. And again,
> for same-site downloads this isn't a problem at all, but I suspect
> that in many cases the file to be downloaded is hosted on a separate
> server.
>
> Oh, and I don't have strong opinions at this time on if rel=attachment
> or FileSaver or both should be the way to trigger this functionality.
>
> / Jonas
>

I agree FileSaver is useful and has its place, but I don't think it negates
the need for something like rel=attachment or download=filename. For one,
FileSaver currently operates on blobs and as you mention would have to be
modified to handle URLs or streams more generally. Second, it would force
developers to use javascript links and/or set up click listeners and so
forth, which could be annoying for users (losing the ability to copy the URL
etc).

I don't understand why we would add CORS as a requirement for this. You can
already link to things from another origin, the fact that they may be
downloaded rather than displayed and then the user somehow tricked to upload
them seems like a rather remote concern...  if I now want to link to a
StarCraft 2 patch and give the browser a hint that it's a download (so that
maybe in the future the browser might be able to have more intelligent UI
when I hover over it, or at least not pop up a new window that just then
spawns a download) requiring CORS seems quite overkill, especially if the
response would have triggered a download anyways.

I guess the interesting question is "If the response would not have
otherwise triggered a download, and the request is cross-origin, should that
require CORS" and personally I would say no, this is still a remote enough
concern that I would not worry about it.

-Ian

Received on Friday, 15 July 2011 11:58:35 UTC