[whatwg] Priority between <a download> and content-disposition

[Boris Zbarsky]

On 5/8/13 6:53 AM, Gordon P. Hemsley wrote:
> It's not clear to me which of the two factors you take issue with.

The question of which filename takes priority.

> I interpret that first sentence to mean that the file should be
> downloaded (disposition type = attachment) rather than displayed

Yes.

> The second sentence very clearly suggests
> that "A.txt" would be the filename presented to the user by default in
> the save dialog.

No, it suggests that A.txt is what the page author recommends.

If, at the same time, B.txt is what the server author recommends, what 
should happen?

>> There is if you allow cross-origin @download.
>>
>> There is if you allow untrusted markup on your server and don't sanitize
>> away @download (should it be sanitized away?  Unclear).
>
> I'm still not seeing what the problem is. All this does is make the
> browser treat the link as if the user followed it and then went File >
> Save Page As....

No, because in that case the browser will definitely use the 
Content-Disposition filename, not the one from @download.

> What are the security concerns, cross-origin or otherwise?

One concern is being able to do this:

   <a download="known-location.pdf"
      href="http://some-bank/statement.pdf">

cross-site and combining it with something that lets you read 
known-location.pdf (e.g. a file://-specific privacy hole that only 
applies to some filenames, or an <input type=file> that the user has 
already filled in).

Another concern is if you upload a file to an image-sharing site, but it 
happens to be a Windows executable.  Then you link to it with:

   <a download="something.exe" href="http://image-sharing-site/whatever">

and wait for the user to download and double-click.  This relies on the 
user thinking the file came from image-sharing-site so must be an image. 
  UAs may do mitigations here by changing the suggested filename, of course.

Generally, allowing this sort of thing opens up several new phishing nd 
social engineering attack vectors, and it's not clear that we want that.

> Well, what I should have said is, there is no content sniffing beyond
> what is already done for regular page saves. (The UI can show the MIME
> type or format of the file in the download box, as it would for any
> file it doesn't handle natively.)

It can, and users routinely ignore that.

> Ah, I admit, I'm a bit biased towards Mac in that regard. It's been a
> while since I used Windows. But I'd be surprised to find out that the
> browser (Firefox, in the case I have in mind) changes the extension in
> the suggested filename (e.g. "example.php" for an HTML file) on
> Windows but not on Mac

It sure used to in some cases, partially in concert with the Windows 
filepicker.  See the (scant) documention for lpstrDefExt at 
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646839%28v=vs.85%29.aspx 
and I suggest actually doing some experimentation across the different 
save variants (save image, save link as, save page as, click on 
something with content-disposition:attacment) on several OSes to see the 
behavior.  There is certainly a good bit of code in the various 
file-saving codepaths in Firefox that attempts to ensure extensions 
match MIME types, to forbid saving things with certain extensions, etc.

Also note that Chrome will change extensions on at least @download 
filenames to match the MIME type; I haven't experimented in detail with 
its behavior for other cases.  And I haven't experimented much with 
other browsers in this area, though I expect all have some interesting 
behavior.

-Boris