There’s been an interesting security adjustment in Firefox 3 that’ll have some, potential, ramifications in some (file://-hosted) web pages. Specifically how local files are referenced and accessed, in parent directories, has changed.
For example, previously you could create an HTML page and have it request a file in a parent directory, like so:
<html>
<head>
<title>Local File</title>
<script>
var xhr = new XMLHttpRequest();
xhr.open("GET", "../some/file.txt", true);
// ... handle the response ...
xhr.send(null);
</script>
</head>
<body></body>
</html>
However that is no longer possible (just to emphasize: This is no longer possible only on locally downloaded web pages, running in file://…) as an HTML page can no longer access files in parent directories. This includes both ../ relative URLs and file://… absolute URLs.
There’s a detailed discussion in the bug ticket concerning this change. Primarily it boils down to the fact that:
Users frequently download HTML pages for a variety of reasons, HTML pages have full access to the hard drive and the ability to do cross-domain communication, this combination leads to an unsuspecting mess where malicious pages can actively try to steal user information.
This change is two-fold: It’s possibly frustrating (there’s bound to be some HTML page somewhere that uses XMLHttpRequest to local in local information, located above the current directory) and unavoidable (having this security concern left in place would lead to undesired situations, if they haven’t already).
Generally speaking I don’t think this change will affect many people – but it’s just something that you should be aware of, when planning your sites for Firefox 3.
UPDATE: In the original post I interpreted the Bugzilla bug as being that ALL attempts to access parent-directory files were blocked when, in fact, only items bound by the same-origin policy are (like XMLHttpRequest). This should affect significantly few pages but it’s good to be aware of.
Torsten (May 21, 2008 at 1:41 am)
oh no!
what about some applications/websites on cd or dvd? sometimes clients want an offline-version of their websites. now we have another hassle in the browserwar.
»Oh sorry Mr. Client, you cant’t use Firefox for the Offline-Version. Please use your Internet Explorer … Yeah, i know, what i said before … IE is evil and so on. But not this time.«
Kilian Valkhof (May 21, 2008 at 2:21 am)
While I fully understand the reasoning behind this, I fear this might make web development with local files harder than needed. Does this apply to non-html files like .js and .css files as well?
I hope that, for us web developers, there is a setting in about:config to turn this off when needed.
[H] (May 21, 2008 at 2:25 am)
On Mac OS X they should continue to work but make use of the same mechanism Safari uses to flag apps that are downloaded. Some extended attribute I think.
Damien (May 21, 2008 at 3:04 am)
A possible solution is to set up a portable version of xampp on the cd (or usb pen) with a batch file \ exe – that runs that followed by either a portable version of FF or Opera.
Would look a lot sweeter as well
=0)
Dan Veditz (May 21, 2008 at 3:07 am)
Your example works just fine in Firefox 3. The restriction is not on loading files but on enforcing the “same-origin” policy. Since XmlHTTPRequest is restricted by the same-origin policy this does potentially block some XHR loads, but normal components of a web page (images, scripts, stylesheets) aren’t affected in any way.
For developers using the local disk as a poor-man’s web server there’s a magic pref that reverts to the Firefox 2 behavior if set to false: security.fileuri.strict_origin_policy.
Ara Pehlivanian (May 21, 2008 at 4:53 am)
This will be annoying for when I throw together a quick test page while commuting on the train. Now I’ll have to throw it into a local web server for it to work. :-)
Jaffer Haider (May 21, 2008 at 6:43 am)
Wonder how the TiddlyWiki people will react to this. Will this effect their application in any way? (local file writing/reading of backups etc)
Rory Fitzpatrick (May 21, 2008 at 7:52 am)
Does this also affect CSS rules? I usually reference background images using ‘../images/image.png’ in an external stylesheet, it would be incredibly annoying if that breaks!
John Resig (May 21, 2008 at 8:04 am)
UPDATE: In the original post I interpreted the Bugzilla bug as being that ALL attempts to access parent-directory files were blocked when, in fact, only items bound by the same-origin policy are (like XMLHttpRequest). This should affect significantly few pages but it’s good to be aware of.
Please read Dan’s comment, above, for the full details.
Leons Petrazickis (May 21, 2008 at 8:07 am)
One project I know of uses this approach:
. – CSS, JS, and Flash here
./EN_US – HTML localizations here
The HTML files include CSS, JS, and other resouces from a parent directory. Am I correct in understanding that this architecture is explicitly incompatible with the change?
kL (May 21, 2008 at 8:11 am)
I hope it only affects XHR and iframes, not images and CSS.
Anyway, the jail could be a bit smarter, eg. allow one or two levels up, don’t allow system directories or going level up on desktop or ~ directory.
Leons Petrazickis (May 21, 2008 at 8:19 am)
Ah, never mind.
Torsten (May 21, 2008 at 8:30 am)
puh …
Jason (May 21, 2008 at 8:50 am)
This is not a bad thing, yes it’s very convenient to serve a page from file:// but it’s also no hassle setting up lighttpd.
Rodrigo Cardoso (May 21, 2008 at 3:19 pm)
oh no :(
Fraser Smith (May 22, 2008 at 10:39 am)
This is truly irritating. I use MonkeyGTD (a tiddlywiki variant) that runs entirely locally from an html file. Every time I start FF3RC1, I’m prompted and I have to allow MGTD to save. Fine, I can choose to remember my choice but that doesn’s stay remembered across sessions.
If there isn’t someway to disable this, I’ll be switching back to FF2 or even Safari.
Boris (May 23, 2008 at 12:54 am)
Fraser, is that app using expanded privileges? The fact that those don’t get saved properly for file:// now is a known issue that got triaged as not blocking Firefox 3… It should hopefully get fixed in a branch updated.
Boris (May 23, 2008 at 12:54 am)
Fraser, https://bugzilla.mozilla.org/show_bug.cgi?id=427051 is the bug in question.
Ivo (May 23, 2008 at 10:30 am)
This is the end of my full client-side JS app :(
I’m retrieving a JSON(P) version of my http://www.editgrid.com spreadsheet, but this fails with FF3. So now I have to use a serverside proxy,
Why should FF3 behave different in this case than other browsers?
Joe D'Andrea (May 27, 2008 at 9:38 pm)
Hmm … I can’t even get this much to work using jQuery 1.2.6 on Firefox 2.0.0.14 (MacOS):
$(function() {
$.get(‘http://www.google.com/’,
function() {
$(‘#ok’).text(‘PASS’);
});
});
… where FAIL appears in the body. The callback is never reached.
Of course, I was previously using the Firefox 3 beta. So I checked about:config for security.fileuri.strict_origin_policy but then remembered I’m not using a file URI (fetching from a web server on localhost) … plus it’s not set in FF anyway.
Perhaps I’m missing something else though. Clues welcome/appreciated!
Joe D'Andrea (May 27, 2008 at 9:57 pm)
Weighing in with my previous comment over on #jquery (irc) … I’m told this is apparently par for the course.
However, I noticed that testing on Safari passes, and that’s when I thought it might be a Firefox-only issue.
Joe D'Andrea (May 28, 2008 at 7:29 am)
Made the mental leap (LOL). a) Safari passes for LOCALLY loaded JavaScript (sheesh, read the entire comment thread, Joe), and b) fortunately for my case, it’s JSON to the rescue. (No cookies involved, and the data in question is already public access.)
As for FF3, per Dan’s comment, there’s always security.fileuri.strict_origin_policy=false. Yay.
Mark (May 29, 2008 at 11:49 pm)
I just turned security.fileuri.strict_origin_policy to false, and it still doesn’t work.