[whatwg] a rel=attachment

[Jonas Sicking]

2011/7/15 Ian Fette (イアンフェッティ) <ifette at google.com>:
> 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).

As stated, I don't have a strong preference here. I suspect ultimately
we'll end up wanting both a markup based and an API based solution
here.

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

Indeed, that is the interesting question.

I know that I would personally feel a lot more comfortable if the site
opted in to allowing downloads of the resource in question. But it's
quite possible that I'm overly paranoid.

Though one thing to keep in mind is sites that explicitly state that a
resource should *not* reach the users disk. This is today often done
using "Cache-Control: no-store". Seems scary to allow such content to
be saved based on a cross-site request.

/ Jonas