This is actually described in the HTML living spec:
If the algorithm reaches this step, then a download was begun from a different origin than the resource being downloaded, and the origin did not mark the file as suitable for downloading, and the download was not initiated by the user. This could be because a download attribute was used to trigger the download, or because the resource in question is not of a type that the user agent supports.
This could be dangerous, because, for instance, a hostile server could be trying to get a user to unknowingly download private information and then re-upload it to the hostile server, by tricking the user into thinking the data is from the hostile server.
The scenario, described here is:
- You are on my
onlineexcel.attacker.com website that allows to make Excel files
- You click a link in there, stating like "download your excel sheet". This is actually a link that downloads your facebook profile, say
<a href="https://facebook/myprofile/" download="your-sheet-from-onlineexcel.xlsx">
- Later on, you wish to restore your excel sheet/load it online, so you click the upload button of my è onlineexcel.attacker.com
, say` and you select the file that you thought was from onlineexcel.attacker.com (because it was a link in there)
- You actually have uploaded your FB profile to my website
So the hazard here is that user do not know whether link is downloaded from the same origin or not.
That's why spec advises:
Thus, it is in the user's interests that the user be somehow notified that the resource in question comes from quite a different source, and to prevent confusion, any suggested file name from the potentially hostile interface origin should be ignored.
But I suppose that since this is a bit difficult to properly tell to Mom-like users, then browsers preferred to block such downloads.