User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.152 Safari/537.22 Steps to reproduce: <a href="http://upload.wikimedia.org/wikipedia/commons/8/87/Google_Chrome_icon_%282011%29.png" download="filename.png">Click me!</a> http://jsbin.com/akawuq/2 Actual results: The image was opened regulary Expected results: It should have being downloaded like in Google Chrome
This is a necessary security measure. See the discussion in bug 676619. Note that the behavior is just fine per spec, for what that's worth....
In my opinion it doesn't make any sense to link it with the CORS Policy, because I don't see which security flaws the hackers could exploit with the HTML5 download attribute. Also, cross origin downloads are working perfectly in Google Chrome.
> because I don't see which security flaws the hackers could exploit with the HTML5 > download attribute. Please do read the discussion in bug 676619. > Also, cross origin downloads are working perfectly in Google Chrome. Yes, and we think they're adding security bugs by doing that.
I know this bug is labeled invalid and I know the devs don't want to address the issue further...but if anyone reads this I'd really like to know if there is some way *advanced* FF users can enable cross-origin downloads. I mean, c'mon, the case against allowing cross-origin downloads is built on the premise that users could unknowingly download a file from a site containing their own personal information (e.g., gmail.com) and save it using a misleading name (e.g. "30off.coupon.txt") AND THEN proceed to another malicious page where they directly go and upload that same file they just downloaded. I mean c'mon. Seriously?? Anyone who's gonna fall for that deserves to lose their personal information. I'm all for browser security, but I think a simple preference in about:config to enable cross-origin a@download is in order. Please consider. Thank you.
Solution make a ajax call, create a blob, objectURL and set that as download attribute - all set How is this any different?
The difference is the ajax call enforces same-origin or CORS opt-in. I suppose we could do something where @download is considered for cross-origin but CORS is then enforced...