Javascript File i/o

Thursday May 25th, 2000

Pete Collins from Alphanumerica and Mozilla developers have created a Javascript interface for doing file i/o in Mozilla, which will allow new Mozilla components like Alphanumerica's Crash Recovery system to function properly.

Patterned after the PHP filesystem functions, simple functions such as file read/write and directory create are supported. The code has not yet made it into the nightly build, but they expect it will get in soon.

Note from AN: There seems to be a misconception about Javascript File I/O being a security risk. It is important to clarify that this project is not opening any security holes in Mozilla. There is a difference between Javascript on the Internet and Javascript inside the application. Javascript is used inside Mozilla to create the functionality for the application. This is in contrast to any Javascript downloaded from the Internet that is used for functionality only inside a Web page. This project does not grant any access to Javascript found on the Internet. For more information about how Javascript is used inside Mozilla read more about XPCOM and XPConnect.

#31 My thoughts on this so far....

by SomeSmartAss

Thursday May 25th, 2000 11:04 PM

You are replying to this message

As I was the first, and most vocal in this debate, I think I should try and pull this together into what I *percieve* has been posted thus far on the matter.

a) This functionality will NOT be available from either the DOM level (*whew*), or from a web-based XUL page. If I understand correctly, XUL is actually dissabled unless run off the local machine (is this right?)

b) the functionality is there for fully installed XUL/XBM/XPConnect "packages" that will (presumably) warn you that you are downloading potentially dangerous material then and there. The traditional "skins" add-on will be little more than window dressing (no offense to Mac or *nix users intended)

c) once installed, these packages will not have the fine grained security model that current signed .jar's have in Netscape 4x.

If I am at all misguided in these assumptions, please let me know.

Now, I have not noticed any mention of how these packages will be delivered to the end user. (Although I haven't followed the links to the Mozilla documentation provided, which may mention this) Hopefully, they will require some sort of signed compression similar to what a secure .jar file does right now.

That said, I still see a problem with this current situation. These packages will now be analogous to an ActiveX on the IE side. Extremely powerful objects that a user chooses to download, or not, but which then have (virtually) unlimited control over the client's system once installed. They could be some harmless little extra; they could be a powerful & wonderful new application, or they could be something in between, possibly hiding a more evil intent within. With what I believe to be the current model, I cannot tell if some "add a 'cute animal of the week' button to my toolbar" package does only that, or does that and wipes out my hard drive sometime next month. All I know is it might be dangerous, or it might not. That's not good.

While I agree that this functionality is wonderful, and even needed, in some way, to truly allow Mozilla to become the application platform it has the potential to become. I still stress that these added features be weighed very carefully in context of what posible security risk they then open up. Even if the initial intent is benign, and useful (and a graceful Crash Recovery system is definately both) we must consider where this could lead, in the hands of either a misguided programmer, or clueless media pundit (or massive software giant bent on spreading FUD in order to promote thier own, flawed, products). I still contend that any functionality as powerful as this should require its own security alert. Yes, I agree that this may be leaning a tad too far towards the cautious side, but its a lean that I, as aa Netscape user, have grown to expect. And when it comes to web borne applications having access to my personal system, I'd vote for overly cautious rather than overly trusting any day.

And those of you who believe me to be some paranoid security freak, who doesn't *grok* it; may I remind you that I have been reading this page nearly since it's inception, and have often chosen to be a devil's advocate when faced with well intentioned proposals that, in my view, might require a bit more thinking through. I do have the utmost respect for the Mozilla team, and their coding efforts; but I also know that sometimes, the people closest to the problem don't alway notice it.

Besides, I don't call myself "SomeSmartAss" for nothing.