thanks for the report, does this only happen on Android?

Could you clarify the part in the spec that Chrome is not complying with?

wth
> does this only happen on Android?

It happens on Chrome for ordinary PCs as well.
But it does matter only on Android as far as I know.
That's because the security model of PC and Android is different.

asanka
> Could you clarify the part in the spec that Chrome is not complying with?

----
https://www.w3.org/TR/html51/links.html#downloading-resources

In cross-origin situations, the download attribute has to be combined with the Content-Disposition HTTP header, specifically with the attachment disposition type, to avoid the user being warned of possibly nefarious activity. (This is to protect users from being made to download sensitive personal or confidential information without their full understanding.)
----

I think it says download attribute should not work in cross-origin 
situation unless the resource comes with Content-Disposition.
Am I misunderstanding something?

BTW, Firefox does download only same-origin contents.

#3: The spec doesn't require that cross origin downloads be disallowed. The part of the spec you quoted requires that the Content-Disposition header be authoritative specially in cross-origin situations. The recommended manner in which the @download attribute and Content-Disposition header are to be used is described in detail in the next section.

Chrome ignores the filename specified in a @download attribute for cross origin downloads in accordance with https://www.w3.org/TR/html51/links.html#downloading-resources . If there's no Content-Disposition header present, then we eventually reach step 12 in the spec regarding filename determination:

  "12. Act in a user-agent-defined manner to safeguard the user from a potentially hostile cross-origin download. If the download is not to be aborted, then let filename be set to the user’s preferred file name or to a file name selected by the user agent, and jump to the step labeled sanitize below."

Here, Chrome chooses not to abort the download. Instead it proceeds to derive a filename based on the URL of the downloaded resource and, if applicable, the Content-Type of the response.

Chrome could opt to block cross origin downloads initiated by @download where the server response doesn't specify a Content-Disposition of attachment.

However, 
  1) The attack in question doesn't result in the attacking page or origin gaining access to the downloaded resource directly. Instead there needs to be a complicit app that reads the downloaded resource off the SD card.

  2) The information disclosure could happen regardless if the server response included a Content-Disposition of attachment, or if the Content-Type is not supported by the renderer (in the latter case, the attacking site could navigate an iframe to the URL and trigger a download).

Given these, I don't think disallowing cross origin downloads initiated only via @download is justified by this attack alone. I'll, of course, defer to security folks on whether this is a reasonable conclusion.

I agree with asanka's conclusions in #4 especially that the information disclosure could just happen via an iframe so this doesn't sound like any additional risk above and beyond that.

Sorry for being late. Ok, I was wrong in regard to the spec interpretation.

However, one point I think should be clarified is how attackers can use iframes to force downloading cross-origin contents of text/html or application/json or whatever on Chrome?

Is it really possible without "Content-Disposition: attachment"?

#7. No. An attacker can't use a simple iframe navigation to force downloading of a document which is not served with a "Content-Disposition: attachment" and which is served with a supported content type. What #4 2) states is that had either condition failed (i.e. the Content-Disposition requires a download or if the content was not supported), then the browser would handle the request as a download. While there are additional constraints, the issue of some site being able to download a cookie authenticated resources via an HTTP GET and placing it in the user's downloads folder (whereever that may be), isn't an issue unique to @download.

Thank you very much for elaborating. I got the point.

But I still think that @download increases the attacker's chance significantly. An installed Android app is able to get any cookie authenticated resource with @download (only if HTTP GET is accepted and the URL is predictable).

Let me give an example. A Google's page, https://myaccount.google.com/privacy?pli=1 serves an HTML containing the user's personal information. Is it really desirable to allow all installed Android applications to gain access to this type of information? The attack is possible only when the malicious app uses @download.

When we consider contents served with "Content-Disposition: attachment" or unsupported Content-Type, the best solution would be that browser asks if the user wishes to download the content or not before the browser saves the content in sdcard (i.e. behaves like Internet Explorer).

Anyway, if here is not the right place to discuss this issue, I would bring it to somewhere else (HTML5 spec ML?). Do you have any ideas?

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot