On Mon, Jul 18, 2011 at 8:58 AM, Alexey Proskuryakov <a...@webkit.org> wrote: > > 17.07.2011, в 21:05, Adam Barth написал(а): > >> In summary, using CORS for this purpose is costly (both to >> implementors and to authors), and I don't think it solves a real >> security problem. > > > Agreed. This feature basically gives authors two abilities: (1) force > downloading of resources that would be displayed inline otherwise, and (2) > rename them on the fly. Neither is what a site operator adding CORS headers > e.g. for WebGL textures would think they're allowing. > > A different scenario which I don't think has been discussed in this thread is > bypassing a hosting service security settings. Consider a highly reputable > hosting that doesn't let you upload executable files (or maybe just scans > those for malware if uploaded). With @download, one could bypass that, and > make users download or even run an .EXE file by following an innocuous link > to a well known domain. This kind of download could be same origin or cross > origin. > > Perhaps an author who has not been given permission to change server HTTP > responses is not trusted enough to change them via HTML either.
Any site that want to allow downloads without risking sharing data can simply add "content-disposition: attached" headers. So no risk of leaking too much data required. / Jonas
