Tuesday, December 2, 2008

Mozilla Developers Hate Saved HTML Manuals

My website, Cyclopath, is written in Flex, Adobe's development environment which produces apps that run in the Flash Player. Needless to say, I occasionally need to reference the Flex documentation, which is HTML. I can browse it either on Adobe's website (slow) or save their zip file and browse it off the hard disk (fast). Guess which I chose?

Anyway, recent versions of Firefox 3 break these docs, because they don't allow different files in the doc package to reference needed JavaScript (because it's in a higher directory), so all the helpful links like "Show Inherited Public Properties" don't work.

And here's the error message that shows up in the error console:
Error: uncaught exception: [Exception... "Security error" code: "1000" nsresult: "0x805303e8 (NS_ERROR_DOM_SECURITY_ERR)" location: "file:///export/scratch/reid/flex3.2.0/doc/langref/asdoc.js Line: 493"]
...impossible to Google. Bah.

Wandering around the Mozilla bug database a little (using, frankly, a lot of expertise that most people don't have) revealed that, in fact, this is by design.

You can turn off the behavior by going to about:config and setting the secret configuration variable security.fileuri.strict_origin_policy to false. Mozilla developers are not interested in making this more obvious and don't believe that anyone other than a web developer needs to change it, despite the large installed base of on-disk HTML user manuals for a variety of things.

I don't fully understand the security reasons for this change. I assume they're sound. But what an absurdly opaque failure mode.

Shame, Mozilla!
Posted by at 2:48 PM
Labels: , , , ,
Reactions: 

4 comments:

  1. There's an important reason why Firefox 3 doesn't allow these scripts to run by default: security. Downloaded scripts are run in a restricted “sandbox” environment that isolates them from the rest of the operating system, including folders outside the scope of the web page. Scripts are permitted access only to data in the current document or closely related documents. No other access is granted to the local file system, the memory space of other running programs. Containment of this kind is designed to prevent malfunctioning or malicious scripts from wreaking havoc in the user’s environment.

    By setting that preference to false like you did, you essentially give JavaScript full control to not just all your files on your hard drive (including any personal documents you might have stuffed with passwords, secrets, and what not), but also to do full directory listings, meaning it can "see" the directory structure and names of all files and folders on your hard disk. I am sure that there are plenty of evil examples out there that can show why allowing this is generally a bad idea.

    There is no reason for the browser (or the user) to trust the code such as that found on Web pages, so JavaScript is executed in Firefox 3 as if it were hostile.

    Mozilla is just doing what it can to protect you, and that's the reason why they aren't eager to tell the world how to disable this security. They provided the pref for valid use cases like yours, though. That said, please be aware that you've also enabled access for any other local script you might have or download in the future.
    ReplyDelete
  2. David,

    As I mentioned, I believe the security problem is real, though I appreciate your explanation -- nothing I saw in the Mozilla docs for the config variables, in a Google search, or in the Bugzilla had anything remotely as coherent; thanks, now I understand the problem.

    However, as I mentioned, by beef is not with the attempt to fix this security problem -- it's that Mozilla completely ignored this use case, and (judging from the bug reports I looked at) developers are hostile to any sort of nuance on the matter.

    The basic issues are:

    (a) the sandbox is badly defined for file:/// URLs. The Flex docs consist of thousands of files. It's ridiculous to put them all in the same directory, it's silly to duplicate the JavaScript files into each necessary subdirectory, and there's an installed base of HTML docs that can't be changed for whatever reason.

    (b) the problem is completely opaque. Give me an error message that I can Google. Don't hide the information because I'm too dumb to deal with it properly.

    Why do I need to specify this global on/off switch (which in fact is less expressive than the preference item it replaced)? Why can't I define the size of the file:/// sandbox rather than relying on Firefox to choose it (badly)?
    ReplyDelete
  3. I'm not sure which bug reports you are referring to so I can't comment on whether or not the Mozilla developers are hostile. That said, about the basic issues:

    a) This seems like a special case with the Adobe documentation. I'm not sure what the default security policy is for other browsers like Internet Explorer. It would be nice if you could specify something like "allow JS files to be executed inside C:/mySandbox". I'm guessing it's possible to create an extension that does exactly that, but I wouldn't know where to start myself. Have you checked the NoScripts addon? It's apparently very robust and supports whitelisting of trusted websites (including, I'm assuming, local websites).

    b) I agree that the error message should be more descriptive and user facing. Firefox 3 could probably do a better job of explaining what it's doing and why.
    ReplyDelete
  4. A workable solution for me is to deploy the AS3_Reference file structure to a web server on my localhost.
    ReplyDelete

Subscribe to: Post Comments (Atom)