User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.0.9) Gecko/20061206 Firefox/1.5.0.9 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.0.9) Gecko/20061206 Firefox/1.5.0.9 window.loacation seems treating argument not as opaque string but something as to resolve: at least it's trying to resolve data() URL. As reported by user Jeff at comp.lang.javascript (see the URL) an assignment like window.location = 'data:plain/text,Test'; leads to FileSave dialog with cryptic default file name "d2zmrxtf" which alone suggests a unexpected exploit of window.location property. P.S. I'm not the founder, I'm just pointing your attention to the post. Reproducible: Always Steps to Reproduce: 1. 2. 3.

I confirm that the observed phenomenon is in effect for the Internet zone as well. See the attached HTML page in action at http://jsnet.sourceforge.net/tmp/367231.html

What is this exploiting? This looks like mostly-proper use of the data: protocol to me, not a bug. There is a problem with your webpage that it uses plain/text instead of text/plain. So instead of displaying the data, we try to save it to disk.

Thanks for bringing this post to our attention. This is how the data: scheme is supposed to work, the only odd behavioral issue is that since it wasn't loaded from a particular path from which we could take a file name, and because it's not an HTML document where we could use the <title>, we pick a unique temporary name. This is not a security problem. Because it's confusing you could make the case for an enhancement request that we should prompt the user for a filename when we don't have one rather than pick something random.

(In reply to comment #3) > Thanks for bringing this post to our attention. This is how the data: scheme is > supposed to work, the only odd behavioral issue is that since it wasn't loaded > from a particular path from which we could take a file name, and because it's > not an HTML document where we could use the <title>, we pick a unique > temporary name. Thank you for clarification about the file name and sorry for troubles then. My primary impression was that this approach does allow to escape the regular sandbox and given the popularity of news:comp.lang.javascript I just wanted to report it as quick as possible. Further tests show that the sandbox is still imposed by the page from where the navigation occurs, so there is not obvious vilnerability in here.

I too am running into this issue. I want to forward an hCalendar microformat appointment from Firefox to PalmDesktop. I use: <a href="data:text/x-vcalendar,_escaped VEVENT comes here_"/> However, as reported previously, Firefox picks up not only a random file name. Beside the filename, there's another issue: Firefox does not add an extension to the filename (how could it when it does know what the user intends?). This leads to the appointment being ignored by PalmDesktop. Suggestion: add "name" or "filename" parameter to the data: URI scheme (as per older RFC1806 or former Content-Disposition header field). Example: <a href="data:text/x-vcalendar;filename='event.vcs',..."/>

Comment 5 seems like a good strategy to me. Short of that, and easier, is to attempt to infer an extension from the MIME type; possibly having a short hard-coded list, or, better, using the OS MIME-typing mechanism.

When saving a inline file (NOT image), Firefox (3.0.6/Win32) generates temporary file name with the correct extension (by mimetype), but it also appends the ".part" extension, so the saved file has confusing name "filename.ext.part" instead of expected "filename.ext". This shoud be also corrected.

Comment #6 is from 04.2007 and #7 - 02.2009. Is there any progress with that issue? I'm trying to use such a functionality when generating m3u file from a page. The strange thing is that if i save the generated with a random name file it is in format <random-name>.m3u.part, but if i choose to open it, instead of directly saving it, file name is in format <random-name>.m3u.part.m3u.

Not entirely sure where this should go, but data: URI support is Core... somewhere.

Comment 5 is tracked in bug 532230, even if it is listed as a Mac OS issue.

Until this gets fixed it is impossible to perform client side file processing and export. Chrome has added a download attribute to a tags that handles the naming of the file. http://html5-demos.appspot.com/static/a.download.html

> Chrome has added a download attribute to a tags that handles the naming of > the file. http://html5-demos.appspot.com/static/a.download.html See bug 676619

5 years old issue...

Changing the data: URL scheme to add a filename would imply non-complaince with RFC 2397. The only way to include the filename in the URI would be to hack the "mediatype" value by adding non-standard parameters. This may have an imapct on the browser interpretation of conten-length that would need to be assessed. The best solution I can find is to use the download attribute of <a> tag. This is being solved in bug 676619 and should be implemented in Firefox 20.

(In reply to Kris from comment #15) > Changing the data: URL scheme to add a filename would imply non-complaince > with RFC 2397. The only way to include the filename in the URI would be to > hack the "mediatype" value by adding non-standard parameters. Since the mediatype has an explicit provision for _custom_ attribute=value pairs (see the referenced RFC2045, page 12), using it for signaling a preferred filename wouldn't be a hack nor a non-compliance with the RFC. In the worst cast it could be considered a mere extension of the RFC. Also, IMHO, using the "download attribute of <a> tag" would be ugly for data programmatically generated by js code.