- From: Darin Fisher <darin@chromium.org>
- Date: Thu, 14 Jul 2011 13:58:32 -0700
On Thu, Jul 14, 2011 at 1:53 PM, Glenn Maynard <glenn at zewt.org> wrote: > 2011/7/14 Darin Fisher <darin at chromium.org> > >> I know that there is also a proposal to add a FileSaver API. I like that >> as well, _but_ it is very nice to be able to simply decorate an anchor tag. >> In many cases, that will be a lot simpler for developers than using >> JavaScript to construct a FileSaver. I think it makes sense to implement >> both. >> > > FileSaver is useful in its own right, but it's not a great fit for this. > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031398.html > > That reminds me of something download=filename can't do: assign a filename > while leaving it inline, so "save as" and other operations can have a > specified filename. That would require two separate properties. One case > I've come across is <img>, where I want to display an image, but provide a > different filename for save-as. Separating the filename would allow this to > be applied generically both links and inline resources: <img > src=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg filename=picture.jpg>. > > In that case, rel=enclosure would probably make sense. > Yeah, that makes a lot of sense. I'm fine with using rel=enclosure too. > > On the other thread, Michal Zalewski raised a concern about giving >> client-side JS the power to name files. >> > > That subthread just seemed to be asking whether browsers should implement > Content-Disposition, which didn't seem relevant--they already have, for > years. > > Separately, there was a security question raised about the ability to serve > a file off of a third-party site with a different filename than was > intended. For example, uploading a file which is both an executable trojan > and a valid JPEG to an image hosting site, and linking to it externally, > overriding its filename to .EXE. The question there isn't about being able > to serve executables--you can always do that--but being able to serve > executables that appear to be from the image hosting site. Arguably, it > could 1: cause users to trust the file because it appears to be from a site > they recognize, or 2: cause the site to be blamed for the trojan. > > I mention it so people don't have to scour the previous threads for it, but > I think it's uncompelling. It just seems like something UI designers would > need to take into consideration. (In my opinion, the trust and blame for > saving a file to disk should be applied to the host *linking* the file, and > not from the site hosting the file, which makes the above irrelevant.) > > Agreed. I suspect that users will associate a download with whatever host they see in the location bar. -Darin
Received on Thursday, 14 July 2011 13:58:32 UTC