[whatwg] a rel=attachment

[Jonas Sicking]

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