Javascript File i/oThursday May 25th, 2000Pete 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. How is this built into the security model? The page linked to to stated; "This interface allows even casual programmers full access to local file handling routines." That little statement alone gave me the willies. Please tell me the by "local" they meant "machine from which the page originated" Or is this for use withing the Mozilla framework, and not at the page level? I'm just thinking about all those nasty VBScript viruses (virii?) that I have, up until reading this post, smuggly dismissed as an IE only problem. This package requires access to components, which is not available to anything downloaded from the web. Only local scripts, in the chrome area, have automatic access to this feature. Signed scripts may also be able to access it. Cool. Now, is there still a per-script, privledge based, security check (the way Netscape currently handles potentially dangerous javascript calls), so that malevolent skin designers don't start doing evil nasty stuff to once their skin is installed. Again, I'm just worried about the posibility of something being given free reign to my hard drive, simply because its in my "skins directory" or some such. If the answer is that the scripts only have access to the chrome area, and no further; what will stop a skin from a) filling my hard-drive with millions of tiny, one byte, files (ala an old "Tribble" virus I once wrot^h^h^h^h heard about) b) somehow planting, and running an executable that doesn't have said restrictions (i.e. a "byte-code string" hidden within the skin that gets written to file, then renamed "iAmEvil.exe" and executed. This, if my memory of the aforementioned PHP I/O calls is correct, combined with some intense bitwise operations, is technically possible, albeit quite tricky) You have to remember that not just anything ends up in the chrome directory. It has to be placed there manually. The only problem is, a virus/trojan horse/worm that arrives via another vector (traditional binary/disk infection, or VBScript on some poor sucker who uses Outlook) could edit the user's chrome, and use that as an additional means of propagation or vandalism. <<You have to remember that not just anything ends up in the chrome directory. It has to be placed there manually. >> Unless I'm completely out-to-lunch here (a very real possibility), an Auto-install procedure for chrome/skins/perdy-stuff is in the works. At which point, that statement becomes moot. Granted, I would assume that procedure would require some sort of manual OK before being installed, it still allows for unknown/unwanted I/O access after being installed, if the I/O access ability is granted to any XUL chrome, without asking the end user first. >Only local scripts, in the chrome area, >have automatic access to this feature. Hmm, and how does Mozilla's skinnability fit in? I mean, no way, the ordinary user will read the scripts when he/she wants to use another chrome. >Signed scripts may also be able to >access it. Signed scripts?? And all those people using Netscape because they hate IE's Active-X and VBscript junk.. Most ordinary users I know press "yes" on every "Warning! Are you sure?" screen they get, integrating file I/O is IMO definately NOT a good idea. This sounds VERY frightening. I am not sure I like this at all. Now I'm beginning to wonder if Mozilla will end up having more security holes than IE. <<Most ordinary users I know press "yes" on every "Warning! Are you sure?" screen they get,>> Then they're idiots and deserve to get their hard-drives reformatted. I have no problem with signed scripts being given said access. They already have pretty much the same sort of access right now. It's called "Smart Update" Most Netscape users I know don't mind granting access to their hard-drive, provided they're properly warned about it before hand, and have the choice of rejecting it. What I am worried about is a script given carte-blanche simply because it's in a "Safe Zone" (read, my chromes directory). THAT is what Netscape users hate about that VBScript junk. << Then they're idiots and deserve to get their hard-drives reformatted. >> That they end up with reformatted hard-drives would be a good lesson for them, yes. But what if someone wants to use those idiots to perform a distributed DoS attack instead of formatting their drivers? Mozilla framework only. It uses nsIFile via xpconnect. You will *not* be able to use this from the DOM level. pete How is this handled by XUL files loaded off the web? (like the "try it now" links that the old chromeZone had) do they then have I/O access to the originating server? or can they then write to the client filesystem? If so, would that require client approval (security warnings and such) I'd like to know this too. This is a potentially serious security risk. Just saying "it's okay, since you have to actively click a button to cause it" doesn't cut the mustard. People had to click "ILOVEYOU" too, and look how much damage & chaos that sucker caused. "Nobody ever went broke underestimating the intelligence of the American people." (wish I could remember who I'm quoting) ...that is, please give me a break from this kind of alarmist bollocks that I hear every time file I/O is even mentioned. For Mozilla to even start to become a useful applications platform, there needs to be an easy method to script file I/O without delving into the binary code. creating an easier to use structure for accessing existing functionality is all this is about. the current method of doing file i/o is complicated and requires a level of programming proficiency that a lot of people don't have. the javascript methods help more people write cool new features and applications out of mozilla -- something that is a good thing. I don't think I'm being alarmist here. I have no problem with my browser accessing my hard-drive, and specifically THIS browser. I just want to be told about it first. (it's not the type of thing I *expect* a browser to do, on a regular basis) You're right, opening up this functionality will create a whole new venue of opertunities for Mozilla to become a true WebOS Platform. But with that new oppertunity, come new risks. I want to know if I (as end user) will at least be given the ability to stop the potential for abuse. If I say yes, then It's my tough luck if something nasty happens. My understanding of this is that it's primarily intended for core-level XUL programming, and having a whole slew of alert boxes telling you when something is happening is going to be a disaster. Folks cheerfully download and install binaries from any old web site; in effect, this is exactly the same deal, where if the XUL content is located on the persons hard drive I don't expect to alarm that person by informing them of every damn system call I make; microsoft, or any other program vendor does not routinely do this for good reason; I don't expect to have to do this for a genuine Moz app. If I send out a modal OK/Cancel alert every time I write to the disk, it looks like there's something inherently risky about the whole thing... yes, of course advisable on a remote chrome or any other XUL component directly run from a web site, but nihilistic on a local chrome. <<microsoft, or any other program vendor does not routinely do this for good reason;>> Yaa, because they don't quite understand the paradime of deploying web-enabled applications. I'm not saying that I want a pop-up EVERY TIME it does file I/O. I just want it to ask permissision at the begining of the session. I'd even be happy if it gave me a check box to "Never show this warning again" The assumption that just because I installed it, I'm ok with everything it does is bunk. Browsers shouldn't, by definition, be doing file I/O outside of cashing, and setting of preferences/cookies. Skins shouldn't even be doing that. They're eye-candy. The fact that we potentially can turn Mozilla into a Wordprossesor if we want, shouldn't be at the expense of granting file I/O access to anyone that creates a skin. What you are requesting is fine-grained security control. Advanced users may find it useful, and the NS4.x (and Mozilla presumably) security model provides such control for signed scripts applets. However, scripts in the chrome area can do anything the browser program itself can do (I think it is called UniversalBrowserAccess in the fine-grained security model.) Presumably the scary dialog will state this as being High Risk and also say that files could be modified etc. Unfortunately, at the moment, there is no fine fine-grained security model for XPConnect. There may never be one, because XPConnect is so broad and easily extensible. All access to XPConnect is considered as high risk, i.e., UniversalBrowserAccess. There is no low risk access to XPConnect or XUL, which is why the term "skins", <em>as used in the mozilla codebase</em>, does not allow for customizable button functionality. You can change the color of a button using skins, but not its function. In short, if you don't want to install high risk stuff, you will never be able to customize button functionality using Mozilla, and there is no easy way around it. skins, as defined by mozilla, are just css files. it is not possible to call javascript for a style sheet so there is no security concern here. people don't need to worry about malicious skins. it is only full applications that use css and js that could potentially be a problem. You can bind in XBL files into your skin, which can call arbitrary js functions. Now, whether or not those js calls can interface with XPConnect, I don't know. I think there's endless confusion about the term "skins" in this discussion. Let me list some (conflicting) types of definitions: Type 1. Colloquial usage: Skin affects the browser appearance, but is otherwise believed to be safe (may affect number, arrangement and function of buttons/menus as well) Type 2. Mozilla codebase: chrome:/.../skin directory is allowed to contain only *.css and image files. Truly safe, I believe (I don't think you can use XBL in CSS; that would be non-standard) Type 3. Developer/ChromeZone usage: A bundle of XUL/XBL/JS/CSS files which modifies the browser appearance. Definitely not safe, because XUL/JS in chrome is *all powerful*. It may be better to use the term "application" to describe type 3 stuff, to be installed with a scary dialog. Safe "skins" of type 1 are what the end-user community wants, but won't get from Mozilla. You can't allow a safe skin to change the function of a button, because it could be changed to something malicious. Only the appearance of buttons can be safely changed, and that leaves only type 2 skins as the safe alternative, and can be installed without a scary dialog, or even no dialog at all. Your type one def and type 2 defs sound the same. However, in what you're calling Type 2, the "skin" can include XBL files, too, through the behavior property which is part of CSS3: http://www.w3.org/TR/1999/WD-becss-19990804 XBL files do not necessarily alter behavior through new javascript code, but they can alter structure, which in turn can incidentally alter behavior. *But* XBL can also contain arbitrary code in its method tags. Therefore, there needs to be some way to distinguish XBL with the code from XBL without code, I would think, because XBL is allowed in skins (you can define a behavior in CSS: menubar { behavior: url("URLREFHERE"); } IE already supports this in its HTML components, apparently. If you look in the current Mozilla skin, you'll see XBL is bound in for the back and forward buttons. I guess I didn't say it clearly. Type 1 allows for button functions and number to be different. People assume this can be done in a "safe" way, but that's not true with the current set-up of Mozilla. I didn't realize that Mozilla was using CSS3 already! Thanks for the info. Does this mean there are no truly safe skins possible? I am not a security expert, but I do worry about browser security. As far as I know, Mozilla is as "secure" as NS4.x. Of course, there will always be new Javascript vulnerabilities discovered. Mozilla does have a powerful new feature, XPConnect, which is not present in NS4.x. The file I/O package uses XPConnect. By default, scripts in web pages cannot access XPConnect. Only scripts living in the chrome directory on your local hard disk can access XPConnect. In other respects, I would presume the Mozilla security model is the same as, or very similar to, the NS4.x security model (same origin policy, codebase principal, signed scripts etc.) Placing files in the chrome directory usually requires user intervention, such as clicking an Install button in a scary looking dialog. One would have to allow this because otherwise you would never be able to upgrade your browser, or install optional components. Skins are strictly defined as CSS + image files (no Javascript). Skins may be installed without user intervention, I think. The zip files in the chrome zone, although called "skins", are technically "packages", which are allowed to contain Javascript. They do require user intervention to install. Hope this clarifies things a bit! First off, I'm pretty sure Skins can contain JavaScript (especially for custom button functionality) Second, I am aware that installing a skin will require a certain level of user intervention, I would be shocked to find out otherwise. (in fact, I argued pretty vehimently against NOT warning the user of UI changes) My contention here, is whether this skin will further warn me that it is doing File I/O calls or not. The concept of a skin (at least to me) is mostly to make my browser look pretty (or at least different); that concept doesn't include the ability to create, modify & destroy files on my hard-drive after the initial install. Yes, I understand that XUL, and XPConnect, allow for more than just skinnability, and I'm not contesting the fact that improved FIle I/O will even further extend the possibility of app creation through Mozilla. I just want to be told that its doing File I/O. The assumtion that that just because the user installed a "skin", they should blindly allow it acces to there local system. #29 Re: Still a few questions from me (suprise supriseby WillyWonka Thursday May 25th, 2000 5:50 PM "First off, I'm pretty sure Skins can contain JavaScript (especially for custom button functionality)" A custom button would require xul and js to make it work. That is known as a package I believe. A skin is just a .css file. So if you use skins (only css files), you have nothing to worry about. If you install a package (I believe you have to run XPInstall... see the install for ChatZilla) then yes, there is the possability for virus' and other nasty things. But you do get an install dialog coming up when that happens. This is definitely incendiary. I am a diehard Netscape fan, but I only follow Mozilla on the edges. If Alphanumerica or ANYONE starts doing ANYTHING like that, we need a FAQ sheet on it instantly. The sheer concept of opening that to developers gives me the creeps. I got a little worried about cookies when I first learned about them, until I learned in detail how restricted they are. The restrictions on this need to be clearly spelled out before I'd trust it. see svn's post above. Essentially it's just a javascript wrapper onto already existing xpconnect functionality, for easier use *inside the chrome*, not for webpage use. I'm disapointed. I once though Mozilla/zine readers were a little bit smarter.... First off.. all you who have posted.. "this gives me the creeps".. "what about security"... etc. I have lost MAJOR respect for. 1.- Look who's coding this.. and what is it? a lousy-ass game? NO.. the next best thing that has happened to the internet. One of the toughest applications to write (a browser) is being written before our eyes. These guys are stupid, they are of the best programers out there and you think they would frick around and compromise our security. THEY ARE NOT STUPID. 2.- Netscape basically created the web a can receive full credit for javascript! And yet you doubt, and think they will not take security into consideration?? I feel you are loosing your faith people, lighten up.. if there is a problem, we have the code.. THIS IS NOT MICR*SOFT!!! =) (thank God) Cheers if anything it's probably better that there are people who are paranoid, in order to keep security in the forefront. Remember that Micro$oft also has the best programmers out there, and also make a browser (techically 2), yet security to Micro$oft is practically a joke. it's actually sort of ironic, that everyone is scared about the entire love bug thing, but no one seems to question why it's so easy to do that sort of thing using Micro$oft products 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. A bit more thinking through? IIRC, this library is just a wrapper around the I/O services provided by Mozilla, providing some people with additional convenience when accessing the disk. There's nothing here that you can't already do with nsIFile and friends, all through script. Yes, nothing you can't do with nsIFile and (I quote) "expertise in C or C++" Again, I have no problem with this functionality, I am simply worried about the effects of bringing that functionality up to the level of "casual programer" access. Exactly Ben. This is for mozilla application programmers only. As more or less an organized convenience to the current existing methodologies of doing file I/O from application script. I just read the project web page posted by Alphanumerica just now. I see now where the fear of God has stemmed from. "This interface allows even casual programmers full access to local file handling routines." This actually scared me as well after reading it. When you are programming any client application, the programmer *always* has full access to everything. This statement is misleading in the sense that it made it appear that we all of a sudden opened up file I/O in Mozilla. The wording will be changed today. pete Would a malicious skin have access to attaching a .zip of itself to outgoing email/news letters? While mozilla does not yet have world browser dominance, when it does, any feature, that can be abused will be abused - as VBS in Outlook. Features are nice, but security is better. And this feature have to be given some due consideration, of how it will affect what people might use mozilla for in the future. I was wrong (although I apreciate petejc acknoledging how I *could* have been misled) Now I get it. They're not adding file I/O access to JavaScript, per ce, they're making it easier for Mozilla coders (not us mear mortal end user/skin designers) to access the exsisting function calls, without having to dig out their C++ coders bible. Still, in an effort to better understand this easier access to existing functionality, may ask a few more uniformed questions. I get that this is *only* part of the inner workings of Mozilla, but as I see it, things like Chatzilla will be able to gain access, right?. (no biggie here, you essentially installing a new app, that happens to tie into Mozilla, you get what you deserve for not taking due dilegence in reading security warnings) Now, sinse JS is diabled in Skins, what about the posibility of mini-add ons? Would we, for example, be able to add a custom button to the toolbar? (i.e. my lame "cute animal of the week" example) that has limited JS funtionality (say, normal DOM access) without full access to the "mozilla coder toolsets"? I'm also wondering if there is a way we can access XUL files (including skins) straight off the web? Or will these things have to be downloaded/installed first? Maaan, you stop playing with nightly builds for a while..... 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] Stuart. "Things like chatzilla" are actually first-class applications, in a sense. Mozilla doesn't (or at least, eventually won't) make any distinction between chatzilla and the browser itself. Just like you can now have a "navigator only install", you'll be able to have a "mail only", "chatzilla only", "xmlterm only"... install. Of course all of these will first have to install xptoolkit, nglayout and the other fundamental stuff that they all rely on, but you won't have to install anything which corresponds to a "browser" as such. To that extent, chatzilla and co *have* to have access to the filesystem. Imagine if another component - mail for example - couldn't access the filesystem. It wouldn't be much of a mail program if it couldn't store your mails anywhere! Stuart. Look. All I know is that the link I originally read stated that "Casual Progammers" now had acsess to I/O functionaltiy through JavaScript. That simple statement, without any real qualifying information, sounded quite scary. Yes, I know that I can install any number of potentially harmfull applications via the web; but I always figured Netscape's (and, by proxy, Mozilla's) security model protected me from having dangerous crap running within its sphere of influence. This anouncement initially (and potentially still) sounded like it flew in the face of this trust. I reacted to this somewhat misleading news as any semi-knowledgable indevidual would... with a fair amount of concern. The words "File I/O" and "JavaScript" in the same sentance should raise an eyebrow (or more). I've as much as admited that I was wrong in my assumtions, and I realy don't think my original post was all that inflamitory, especially given my initial perception. Don't sit there and try and label me as some flame spawning ignoramous. If you read my posts, and their replies (especially those from svn and petejc) you'll see that I rationally voiced my concerns, and recieved *fairly* adiquate answers to them. Anyways, this is what open source is all about; everyone having their say. Just because you dismiss me as clueless, doesn't mean my comments are *necesarily* useless. Even if one of the people involved desides to re-examine how this might affect the security model of Mozilla, I've done my part. Sure, you can add extra buttons, etc. You need to create a new package, place overlays for existing components (e.g. navigator) in there and craft a manifest.rdf file that describes how it interacts (adds on) to some other package. Then package it up in a zippy and people can install it via XPInstall like the chatzilla link. |