Re: [whatwg] a download feedback
On Sat, 25 Feb 2012, Glenn Maynard wrote: On Wed, Feb 15, 2012 at 6:19 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 22 Jul 2011, Glenn Maynard wrote: On Fri, Jul 22, 2011 at 2:58 AM, Ian Hickson i...@hixie.ch wrote: As Ian says above, if the user is savvy enough to right-click, the user is likely not going to find it difficult to give the file a name either. (But again, just because I'm able to do something by hand doesn't mean that I should be required to.) Well you're never _required_ to. The client can always use the server-provided name, even if it's download.cgi or something. The point was that it's inconvenient for users to name downloaded files by hand; it's something that should be done for them in the overwhelming majority of cases. I don't think we disagree on this point. That's why this feature allows the author to set the name, after all. Correct. That's intentional. If a victim server doesn't explicitly say that the resource is an attachment, then we don't want to allow a hostile server to trick the user into downloading the file at all. It's not so much that the server can't specify the filename, so much as you can't say that the file should be downloaded in the first place. It should show a warning and let the user select the filename. Why? No new security issues have been suggested, as far as I recall, in allowing links that trigger downloads cross-origin. Thank you for wanting to play SuperHotExampleGame! To play our super hot example game, you must first _download this license file_ and upload it to our license verification server: [ No file selected (Browse) ] ( Upload license file... ) ...where download this license file points to a confidential file, e.g. the user's bank account home page with their bank account number or some confidential project page on an intranet site or some such. Similarly, sites show an image inline and have a separate link to download it. For that link to use @download, C-D: attachment would have to be applied to the images, which is clearly unwanted. Only if the image is cross-origin. On nontrivial sites, download links are *usually* cross-origin (eg. resources hosted on services like S3). Why isn't C-D sufficient in these cases? download= is only really useful for intermediate authors who don't have sufficient control over their servers to set headers. If you really want cross-origin @download to be opt-in, then use a separate header for it (Allow-Forced-Downloads: *); don't repurpose C-D like this. It's not repurposing, it's just using it for a case where before there would be a download but no given filename: now there can be a filename given in the markup. It's repurposing Content-Disposition by using it to say this resource opts into allowing cross-origin sites to specify filenames using @download. No, it's using it to say this resource is an attachment. It's just that things that aren't attachments can't be downloaded from another origin. It's strange, and doesn't allow specifying filenames for C-D: inline, which is also important. That is supported also, as far as I can tell. If you really think that allowing sites to trigger downloads and set filenames cross-origin has security issues, then use a separate header like Allow-Forced-Downloads to make that statement; don't derive it from C-D. (But I don't know what security problem that is.) I don't see anything wrong with using C-D here. We're using it exactly for its defined purpose. We're just more lax for same-origin downloads. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] a download feedback
On Sat, Mar 3, 2012 at 6:53 PM, Peter Kasting pkast...@google.com wrote: On Sat, Mar 3, 2012 at 4:27 PM, Bjartur Thorlacius svartma...@gmail.comwrote: In special, a href=http://www.google.com/**url?sa=tamp;rct=jamp;q=l%C3%** B6gbergamp;source=webamp;cd=**2amp;ved=0CCwQFjABamp;url=** http%3A%2F%2Fwww.thingvellir.**is%2Fsaga%2Flogberg%2Famp;ei=** F69ST6T3OM6XOqGOnZEKamp;usg=**AFQjCNEPLku9Nm5bsA12_** oY9mV1gPH3Aegamp;cad=rjahttp://www.google.com/url?sa=trct=jq=l%C3%B6gbergsource=webcd=2ved=0CCwQFjABurl=http%3A%2F%2Fwww.thingvellir.is%2Fsaga%2Flogberg%2Fei=F69ST6T3OM6XOqGOnZEKusg=AFQjCNEPLku9Nm5bsA12_oY9mV1gPH3Aegcad=rja ... does not link to http://www.thingvellir.is/**saga/logberg/http://www.thingvellir.is/saga/logberg/. Google could fix this by linking directly. That, however, would allow for opting out of tracking by simply not running scripts. This is an unrelated issue, which a ping was designed to address. Not if Google doesn't want it to be possible to opt out of click tracking (which they might not, since it would reduce the information available to their search engine). But yes, that's a separate issue from what I was trying to demonstrate. (It's true that ping is another solution for this, but only for this very specific use case.) -- Glenn Maynard
Re: [whatwg] a download feedback
Another use case: fixing Google's search results. They're currently annoyingly broken: save link as on a result link in Firefox offers a useless default filename of url.htm. The filename attribute would fix this: set the Content-Disposition filename without affecting the disposition type attachment vs. inline). For example: a href=/url?data=... filename=product manual.pdf. That would simply set a default Content-Disposition: filename field. Setting Content-Disposition: attachment should be an attribute orthogonal to the filename, eg. a download. The attachment vs. inline mode is an orthogonal concept to the default filename, and the download=filename design loses that orthogonality, which I believe is a serious flaw. This is also an example of why having separate view vs. download links is bad. Google search results shouldn't need separate download links to be able to set the filename, leaving save-as on the main result links broken. It should work properly with a single link. -- Glenn Maynard
Re: [whatwg] a download feedback
Þann lau 3.mar 2012 21:30, skrifaði Glenn Maynard: Another use case: fixing Google's search results. They're currently annoyingly broken: [snip] Yes, Google is broken. But no, Save As is not the only thing that it breaks. In special, a href=http://www.google.com/url?sa=tamp;rct=jamp;q=l%C3%B6gbergamp;source=webamp;cd=2amp;ved=0CCwQFjABamp;url=http%3A%2F%2Fwww.thingvellir.is%2Fsaga%2Flogberg%2Famp;ei=F69ST6T3OM6XOqGOnZEKamp;usg=AFQjCNEPLku9Nm5bsA12_oY9mV1gPH3Aegamp;cad=rja; ... does not link to http://www.thingvellir.is/saga/logberg/. Google could fix this by linking directly. That, however, would allow for opting out of tracking by simply not running scripts.
Re: [whatwg] a download feedback
On Sat, Mar 3, 2012 at 4:27 PM, Bjartur Thorlacius svartma...@gmail.comwrote: In special, a href=http://www.google.com/**url?sa=tamp;rct=jamp;q=l%C3%** B6gbergamp;source=webamp;cd=**2amp;ved=0CCwQFjABamp;url=** http%3A%2F%2Fwww.thingvellir.**is%2Fsaga%2Flogberg%2Famp;ei=** F69ST6T3OM6XOqGOnZEKamp;usg=**AFQjCNEPLku9Nm5bsA12_** oY9mV1gPH3Aegamp;cad=rjahttp://www.google.com/url?sa=trct=jq=l%C3%B6gbergsource=webcd=2ved=0CCwQFjABurl=http%3A%2F%2Fwww.thingvellir.is%2Fsaga%2Flogberg%2Fei=F69ST6T3OM6XOqGOnZEKusg=AFQjCNEPLku9Nm5bsA12_oY9mV1gPH3Aegcad=rja ... does not link to http://www.thingvellir.is/**saga/logberg/http://www.thingvellir.is/saga/logberg/. Google could fix this by linking directly. That, however, would allow for opting out of tracking by simply not running scripts. This is an unrelated issue, which a ping was designed to address. PK
Re: [whatwg] a download feedback
On Wed, Feb 15, 2012 at 6:19 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 22 Jul 2011, Glenn Maynard wrote: On Fri, Jul 22, 2011 at 2:58 AM, Ian Hickson i...@hixie.ch wrote: As Ian says above, if the user is savvy enough to right-click, the user is likely not going to find it difficult to give the file a name either. (But again, just because I'm able to do something by hand doesn't mean that I should be required to.) Well you're never _required_ to. The client can always use the server-provided name, even if it's download.cgi or something. The point was that it's inconvenient for users to name downloaded files by hand; it's something that should be done for them in the overwhelming majority of cases. Correct. That's intentional. If a victim server doesn't explicitly say that the resource is an attachment, then we don't want to allow a hostile server to trick the user into downloading the file at all. It's not so much that the server can't specify the filename, so much as you can't say that the file should be downloaded in the first place. It should show a warning and let the user select the filename. Why? No new security issues have been suggested, as far as I recall, in allowing links that trigger downloads cross-origin. Your suggested workaround for the PDF case is to have two links, but in order to do that cross-origin you'd need to add Content-Disposition: attachment on the file, so that wouldn't work: they'd both become download links. You'd have to have two different URLs, one for inline embedding, and one for downloading, just as you do today without download=. This is intentional. You shouldn't be able to force a download cross-origin. Why not? Similarly, sites show an image inline and have a separate link to download it. For that link to use @download, C-D: attachment would have to be applied to the images, which is clearly unwanted. Only if the image is cross-origin. On nontrivial sites, download links are *usually* cross-origin (eg. resources hosted on services like S3). This breaks every case where I've wanted this functionality in the past. It doesn't make sense for @download to only work on files which are already marked as such by Content-Disposition. It works on same-origin files also, regardless of their C-D state. Every time I've wanted to do this, it was cross-origin. If you really want cross-origin @download to be opt-in, then use a separate header for it (Allow-Forced-Downloads: *); don't repurpose C-D like this. It's not repurposing, it's just using it for a case where before there would be a download but no given filename: now there can be a filename given in the markup. It's repurposing Content-Disposition by using it to say this resource opts into allowing cross-origin sites to specify filenames using @download. It's strange, and doesn't allow specifying filenames for C-D: inline, which is also important. If you really think that allowing sites to trigger downloads and set filenames cross-origin has security issues, then use a separate header like Allow-Forced-Downloads to make that statement; don't derive it from C-D. (But I don't know what security problem that is.) We're not trying to figure out who's to blame, we're trying to prevent there from being anyone to blame in the first place. Anyone can already have links that go straight to a download, with Content-Disposition: attachment. The only issue that was raised here, as far as I recall, is the possibility that if such a link contains malicious content, this *might* make it appear that the blame for that content is on an innocent third-party. There are no *new* security issues, only the potential for the blame for an existing one to be on the wrong party, and I think that's a solvable UI problem. I don't understand the relevance of rel=attachment (what is it?). The rel=attachment proposal is to treat the link as if it has a Content-Disposition: attachment header. Specifying the default filename would be a separate attribute (and would apply to manual save-as downloads as well). -- Glenn Maynard
