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.

#43 Re: OOOOOOOHHHHHH, Nevermind.

by sab39

Friday May 26th, 2000 2:33 PM

You are replying to this message

1) A skin is not XUL. It's CSS. It is also completely sandboxed, so it can't touch *anything* except the UI. And even *then*, the user will be warned that his/her current skin is about to be switched.

2) Anything that includes the XUL/Javascript functionality which is the scary insecure thing, is a "package", not a skin. It is essentially the installation of a new mozilla "application", like ChatZilla. As such, the user will get a BigScaryWarning[TM] that the thing they are about to install can do anything to their system.

3) Yes, you can install them off the web. You can also download an "exe" from the web and run it, just as easily (even in NS4). The dialog for installing a package will be at least as scary as the dialog that you get when running an exe file from an untrusted location.

4) Package signing also applies to all of this, so you can have *more* security than with an unknown exe - at least you can verify that it is from who you think it is from (so long as you trust the company that sets up your default browser certificates).

5) At the risk of sounding rude - I'd like to echo the sentiments of a previous poster. The people writing this stuff *aren't stupid*.

[rant mode on] That's not to say that there won't be obscure security holes like the recent expired SSL certificate issue in NS4.7, but they do have the common sense to realize that if you give something access to a user's computer, of *course* you ask the user first. Of *course* security issues have been a top priority since skinning was first discussed - that's why there's a distinction between a skin and a package, and that's why skins can't do anything. I suggest you research this stuff from the publically available documents and by following the newsgroups, as I have - constructive criticism is good, but only if it's *informed* constructive criticism. Assume that if something's obvious, it has probably been dealt with; if you're still concerned, research it by looking for pre-existing posts on the newsgroups and for documents on the website. Maybe post a question like "Where can I find information on how security issues in XUL and skins are handled" so that you have some starting points for your own research. And if, after researching, you have reason to think the issue has *not* been addressed, file a bug! Flamewars here don't get things fixed. [rant mode off]