Follow Slashdot stories on Twitter


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 internet speed test! ×
Mozilla The Internet Releases Protozilla 155

An anonymous reader wrote in to tell us about Protozilla's release. "Protozilla enables Mozilla to execute any CGI program on the local disk directly, without passing it through an HTTP server." Its a strange little idea that could definitely simplify development.
This discussion has been archived. No new comments can be posted. releases Protozila

Comments Filter:
  • err, When can we expect this as a mature product? Why will I want to use it??
    I am puzzled, aren't the developers aware that there are slightly more pressing matters to tie up than think up "tricks". I do not want to be appear harsh but I have come to think of this mozilla group as being a bunch of developers who imagine membership of the club is an end in itself. The only products released or discussed are tools to enable rapid development. Something they seem singularly unable of doing themselves. (gulp, I suspect I may be bitten for these thoughts)
  • Actually it's exactly the opposite: It's moving back towards lots of small tools which do one job well. This is about allowing new protocols to be implemented as small external applications, rather than throwing everything into the Mozilla code.

  • Good isn't it. Just as virtually every other app on the Linux desktop is converging onto either the KDE or GNOME widget sets, Mozilla intoduces a new proprietary way to do things, totally seperate to anything else.

    Now that's what I call forward thinking (NOT).

    Hopefully Konqueror will continue to evolve to the point where Mozilla is irrelevant; and Galleon will do the same for the GNOME camp. Both projects have Email/Groupware clients that are superior to the "extra" bundled Mozilla features anyway.

    Ok, so this is old news, and my bitching won't re-write history. But I've not voiced my thoughts about this in the internet before .. and now I feel much better for it :-)


  • It's rather annoying that so many people simply doesn't get how open source works: People work on what they care about. If someone wants to work on this, and not the core browser, they will. It's not as if that takes developers away from the browser - if they'd wanted to work on that, they would have.

    It's time people realize that it makes no sense whining about the work other people do for free to provide software they want or need, and expect those people to work on something that matters less for them.

  • Read again. What he wrote was "that are extending the traditional "web browser" into something we cannot even fully comprehend yet." It's not the individual projects. It's the sum of the environment and interactions and way of working with it that the new projects are creating that we can't fully comprehend yet - The same way that most of us didn't comprehend what the web would become when we were using early browsers in the web's infancy, even though the technology is essentially the same.
  • Is just browsed through the white paper, and I'd say that just using this to run CGI in development is quite narrow-minded review of it's possibilities. Of cource I've might misunderstood something.

    I've looked into Jini lately and that seems to be quite interesting. I just wondered, could this be a way to use Jini based services on net via browers. There aren't probably any yet, but plugging Jini -services to brower might by a killer. Jini might be one good technique for doing 2nd generation Internet services.. Services that are dynamic, not-flashy-html-www stuff which makes it real hard to actually USE the information on the net for anything else except human browsing.. Well this might be quite far feched, but I'd say that anyone who has thought these things might have some clue about what I'm talking about..
  • It's for use for the client side of those protocols. If Mozilla dies, it takes down the user interface to those protocols - what does it matter if it brings down the connection too?

    And if that matters, it's trivial to split the connection management into a separate daemon.

  • > I'm annoyed by all the people that just whine;
    > help out with something god damnit!

    Why should we? Quite frankly you deserve a good roasting for taking what should have been an MS killer, then sitting on it and fiddling with the engine; adding bigger wheels, better spoilers, windscreen wipers, go faster stripes and fluffy dice ... while MS went tearing off round the race track tweaking as they went.

    When you eventually ship V1.0, you'll deliver a product that will be the Open Source equivelant of MS Word. i.e. 10% of the features will be used 90% of the time. But that won't matter, because so many people will have settled on IE, or will be getting by with Konqueror, Gallion, or Opera that Mozilla will make little more than a plop, never mind a splash.

    If this all sounds harsh, then it's meant to be, because I'm annoyed, and because I have a right to be. If I'd know it was going to take this long 2 years ago I'd have invested the time to learn C++ and chipped in .. if not to Mozilla, then one of the others. But like everyone else I believed in the dream and now that dream has been dashed! So don't you lecture us because we're pissed. It's your own fault for not having the clarity of vision and the discipline to get the job done without throwing the kitchen sink at it.

  • I think this is more for being able to run stuff like freenet, or view man pages and stuff. It just let's you use any protocol you want. You could view you files of NFS files eisly in the browser, or even run ls and get the output on the browser edisly, this isn't bloat either beacause it all 100% modular.

  • Doesn't it strike you that Mozilla is actually competing with the KDE & GNOME projects here? Tell me why this is a good thing?

  • by DVega ( 211997 ) on Sunday January 28, 2001 @12:57PM (#474836)
    Mozilla .7 was still to bloated to run at home, after installing the jvm. Personally I think that the jvm that they are using sucks butt. It launches about 30 threads that just take up all my memory. Why????

    There is a bug reported about JavaPlugin been loaded at statup. (bug 26516 []). And there are people working on it.

    There are people working on startup performance.

    • Bug 18277 [] - Need to lazily load the OJI DLL
    • Bug 27510 [] - Too much read from disk on startup
    • Bug 29063 [] - Excessive stat calls
    • Bug 29249 [] - 49 dlls loaded on startup: 50% of startup time

    And there are many reports about performance in general that are beeing addressed (Performance problems [])

    I hope someday Mozilla will be the Browser of our dreams. We can all help this to happen by reporting bugs, correcting them, or promoting Mozilla project.

  • "please just concentrate on shipping a browser that is fast and reliable".

    They are ! If you'd read the article you would've seen it was being developed by mozdev, not by the Mozilla team.

    As MKB says, I'm surprised I have to explain this. ;-)

  • I booted a good portion of this idea around in late 1993. The biggest advantage was removing the need for authentication followed closely by ease of installation. As others have noted, its much easier to drop a binary or script in the right place rather than either re-configuring or outright installing a web server.

    Anyhow, you can read all about it at [].

  • Sounds like a step in the right direction.

    Years ago, netscape had "all" the protocols:
    ftp,http,gopher,and mail.

    Now we have many streaming and file sharing protocols which are cludged into netscape somehow.

    If mozilla fixed this and had protocol plugins, life would be great.
  • > Can you say "format c:"?

    localcgi:/dos/format?c%3A [localcgi]

  • For those afraid of the security issues associated with running CGI scripts locally -- this is a development tool only.

    Does it have to be only for development? Assuming it can be done safely, imagine using local CGI scripts as an alternative to local shell scripts. This becomes particularly relevant for your casual users, epsecially as a means of establishing Linux as an OS for the computer novice. Imagine J. Random User being able to use Mozilla as their program launcher -- everyone and their mothers've already learned how to more or less use web browsers.

    And using the web browser as an interface is certainly not a new idea. Even before IE sprung up (and the infamous "The web browser is part of the OS" statement along with it), we had software packages like SATAN [] doing this back in early '95. And if we look at the web browser abstractly, as a mechanism that allows files to be selected, retrieved, and viewed, its origins can be traced back to products like Norton Commander.

  • > if *you* can't ``rm -rf *" & lose more than a few files, then neither can the enabled protocol

    I think that is actually the whole point. If you can rm -rf so can any mischievous web page author over whose sorry ass^H^H^Hpage you might stumble. And that's a bad thing. This kind of security is about securing the client against the server, not the other way round. Thus "securing ports" or whatever is entirely irrelevant here. The only port to secure would be outgoing 80. And if you do that, you basically shut down any browsing...

  • This browser wouldn't "voom" if I put 4,000 volts through it. Don't believe me? Read this. [].
  • sounds like a security nightmare waiting to happen.



  • Quote:> ... it looks like a glorified version of yet another client-side scripting tool like JavaScript. Do we really need this? No, it looks like another waste of time.
  • I wonder... I've always wanted to be able to distribute client software that just needed a cdrom and not a website. This might just be able to fill that need...

  • It's as unsafe as any software, anyting can delete your files. Just be careful where you get your plugins from(or all your free software).
  • Sounds just like ActiveX. Is there any code signing involved? How do I know if I trust the CGI script that is being downloaded? If this were actually implemeted by public websites, what is the process for securing the CGI code during transfer?

    Seems that people that don't like ActiveX shouldn't be to happy with this new feature. But it has worked well in IE for 3 years.
  • I'm not sure I completely understand this, but does this mean that mozilla could be used as a FreeNet front end, with only a few lines of code? Or even be used to as front end to napster with a bunch of code?
  • by maggard ( 5579 ) <> on Sunday January 28, 2001 @09:26AM (#474850) Homepage Journal
    Er - It's been availiable in MS Internet Explorer for the Mac for a coupla years...

    Generally it's used to point ftp to a real FTP client (Interarchie being popular) and afs to an AFS client (Apple File Sharing.) However it can be used for about anything, including hooks to scripting languages (AppleScript, Python, TCL) using the built in Open Scripting support.

    Open Source is great but it didn't come up with this one first.

  • that is to make up for the fact that windows doesn't have a reall web server (yes, yes, I know that apache can run on windoze).
  • I was doing a bunch of cgi crap on saturday night and I was grumpy because I was going to be gone for a few days and I wasn't going to get to work on my ideas until tuesday. But as I was checking my mail and Slashdot before I left, what do I see but this wonderful thing that allows me to do my cgi on the road! I just don't want to really run a web server off of my laptop.
  • In addition to the usual scripting languages, Protozilla can also execute Javascript CGI programs.
    So can ScriptEase []. (And ASP, for that matter...)

    Zontar The Mindless,

  • Easily done already. Invent a filetype (.lnc) which contains informatian about a program to launch and then have a helper app that interprets the file and launches programs appropriately.

    Of course, it's a security nightmare as you couldn't tell where the file had come from. Perhaps the files could use some form of authentication. Hmm. Yes, for example, NT users could "sign" launching controls then, on a company based intranet, they could launch programs as required from any networked machine. In unix, it could be used to launch programs running suid the creater of the launch control.


  • Just as virtually every other app on the Linux desktop is converging onto either the KDE or GNOME widget sets, Mozilla intoduces a new proprietary way to do things, totally seperate to anything else.
    For those of you playing along at home: Mozilla uses its own widget set -- just like MSIE 5+ does -- because of the demands of HTML4+ and CSS. Microsoft had to add internal widgets not pulled from the OS in moving from IE4 to IE 5 for the same reason. Think about form widgets + CSS-P.

    Zontar The Mindless,

  • Invent a filetype (.lnc) which contains informatian about a program to launch and then have a helper app that interprets the file and launches programs appropriately.

    True, although the impression I got was that this framework would provide a nice helper app to do the magic for us. Furthermore, a CGI-based scheme would allow for easily porting apps from intranet use to local use and vice-versa. Finally, something that delves in to the realm of figuring out when to properly execute content that's trusted is something that I, personally, would feel less than comfortable writing. I would much prefer a system with some peer review.

  • I would think this might be a script kiddies dream. Couldn't it be used to exploit local variables?
    Ryan Wilhelm
  • (Slashdot moderators: To prove it is "official", the contents of this posting can also be accessed from the Protozilla web page,, in the What's New section. Please moderate it up.)

    To clear up some misconceptions, here's a response to some of the comments on Protozilla:

    -Protozilla is not an "official" project. It is hosted at, as evident from the URL. (It is not the intent of Protozilla to delay the development of a viable Mozilla-based browser, which is proceeding at its own pace.)

    -"Client-side CGI" is just one of Protozilla's features, and by no means the most important. As the name susggests, Protozilla is about implementing new protocols easily in Mozilla.

    -Can the "client-side CGI" be used to maliciously access your local files etc.?

    Protozilla is carefully designed to prevent this. The client-side CGI feature may only be used to execute files residing within the user's profile directory, which should be inaccessible to malicious web scripts. Furthermore, the request to execute the file is a special "restricted" URL which can only be loaded by the user typing it in in a special URL box (or from a privileged script). Unprivileged scripts downloaded from the web cannot load this URL. Nor can the URL be loaded by a "dumb" user clicking a malicious link on a web page. (Only executables which are specifically designated as implementing "public" protocols will be accessible to web page scripts through general-purpose URLs.)

    However, any new functionality does open up the possibility of exploits and Protozilla is far from being fully tested/audited. So use it with care!

    -Some posters on slashdot pointed out "prior art". These are useful to put Protozilla in context. Here are the links:

    Pluggable protocol handlers in IE ( ggable/overview/overview.asp)
    Asynchronous pluggable protocols enable developers to create pluggable protocol handlers, MIME filters, and namespace handlers that work with Microsoft Internet Explorer 4.0 and later and a URL moniker.

    W3M ( ml)
    A lot of browsers try to do everything in one program - W3M does exactly the opposite by calling external programs whenever possible. To make this easier it contains a "local CGI" mechanism that is capable of running CGI scripts locally without the help of a web server.

    Jellybean (
    Jellybean is a Perl Object Server with an HTTP interface, based upon an idea by Jon Udell.

    MMM (
    local CGIs [...] providing cheap and sophisticated MMM interfaces for applications.

  • No probs - just making the point that you can already do this on a domestic desktop.

  • People work on what they want to work on. I don't see you working on Mozilla's "pressing matters", so if someone else wants to not either, I don't see how you can complain.

    Lots of people (particularly Netscape people) are already working on Mozilla's "pressing matters", and they are making huge strides.

    And as others have pointed out, this isn't even an official project.
  • have it execute rm -rf /home/user or deltree -y c:\
  • by dervish121 ( 245708 ) on Sunday January 28, 2001 @08:35AM (#474862)
    Lynx has done this for a long time (though you have to reference the script as LYNXCGI, iirc; I used it a few years ago to write a script to browse manpages through lynx). It's pretty useful if you want to use cgi scripts and junk for local documentation, but don't want the overhead of running a full web-browser.
  • Somehow, I dont think that this will be any different from any normal piece of software. I dont think that it will allow pages/javascript on the net to run local applications... the user has to call the application to run (at least I think so)
  • Given Java Servlets and Sun's JSP taglibs, who needs PHP?

    PHP is a fossil, a relic of the late-90's

    As is C++ (flamebait!!)

  • Web server.
  • I believe it was meant to be some sort of memorial. Come on... show just a *bit* of respect for the brave men and women who died on that mission. Even in the faceless world of /. people should have a few shreds of respect for the dead.
  • Hmmm...

    Do you program at all?

    PHP is a language.

    "CGI" is NOT a language.

    PHP on many virtual hosting environments is running in CGI mode.

    Please put a bit more thought into the next post before a knee-jerk post like this. "PHP is great, CGI is bad!". It's not even apples v. oranges, because at least both of those are fruits.

  • Er, you dont get it i'm afraid - this isnt the equivalent of javascript (a client side script). There isnt any point trying to get web site viewers to run cgi's in their browser when thats what the server is for. This is for testing scripts.
    Having said that I still question the value of this for testing, as someone else pointed out it if it doesnt mirror the server you are going to use then you still might have to make changes when you upload it.
    I run apache with PHP,SSI,CGI support on my p133 40MB linux box and it works great so i'm not sure of the value of protozilla (especially given the resource requirements of mozilla!)
  • What if someone gets the code and modifies it so that it can somehow execute cgi on someone else's machine? I am not sure this is possible, but this sounds a little like embedding an http server in a web browser.

    What I'd like to see the mozilla team is to invent a browser that does not suck up all my system resources. I just want a browser. A simple browser that runs on UNIX / Linux. That handles html 4.0 as well as Java and JavaScript and can do netscape plugins, like real audio, mp3, midi, flash and wave files.

    Mozilla .7 was still to bloated to run at home, after installing the jvm. Personally I think that the jvm that they are using sucks butt. It launches about 30 threads that just take up all my memory. Why????

    I don't want a lot, I just want it all!
    Flame away, I have a hose!

  • Maybe MS will include it in the next version of their browser. One could only hope?

    Your wish [] might come true...

  • by Nemesys ( 6004 )
    CGI, under UNIX, is the best method of allowing
    secure dynamic content creation in the case of
    multiple users. mod_perl, mod_php, etc, do not
    permit security boundaries between the users.
  • Even if it's technically correct, I've seen about 20 posts here already saying things like 'CGI sucks - PHP rules!' (I'm a huge PHP fan btw, this is not a PHP slam).

    Although the mozilla people mention using it to test CGI programs locally, that seems probably the worst use of this technology. MUCH more interesting would be to tie in existing code (perl, javascript, etc) into one cohesive app, and run it *locally* with the mozilla app as the interface. No need for a net connection at all - you could write apps in Perl and distribute them to be used with a standalone Mozilla machine. Yes it could be done now if you're also shipping a webserver, but this is less to install and maintain.

    Think standalone kiosks for starters. I was given a demo of a standalone kiosk system over a year ago (never got off the ground). The machine it came with was an NT box with VB Scripts, SQL server and some other stuff - huge $$$. Yes, you could replicate all of this with Apache/Mysql, etc. This just seems to make it even easier. Rather than treating the browser as just a client, it becomes more integrated - it becomes the app itself. Also, by using this IPC stuff, my Perl scripts can do one thing, my javascripts can do something else, and the mozilla frontend would tie it together (that's my impression, anyway).

    I personally am becoming disenchanted with the whole mozilla thing - yes all this stuff is cool, but I think we all just wanted a decent browser about a year ago. Yes, keep developing and adding on, but a small, quick browser (with a netscape 4.7 compatibility toggle switch!) would have helped stave off the decline of this browser technology.

  • by Nemesys ( 6004 )
    mod_php and mod_perl by definition do not use the CGI interface. It is true that perl and PHP may be run as CGIs, but that is utterly different from mod_*, which involves running them with the privileges and address-space of the webserver.
  • I stand corrected! :)
  • ... and Windows comes with Personal Web Server, which gives you an (admittedly poor) ASP & database facility. Useful for testing when poor decisions from previous staff lumber you with ASP :(

  • There was an amiga mozilla project [], but it looks like it's died for lack of developers....


  • > If you can rm -rf so can any mischievous web page author over whose sorry
    > ass^H^H^Hpage you might stumble. And that's a bad thing. This kind of security is about securing the client against the server, not the
    > other way round.

    Hence my statement, ``Although it would be even safer if anything that ran in this wise ran in rsh as `nobody'." On one hand, a malicious application could no nothing more than writhe around in /tmp. On the other, if I wanted to use this ability to read email, Usenet, etc. thru a Protozilla helper-app, I would be thwarted because by sudoing to ``nobody", the helper-app could not write to my directory.

    All of this are just some random thoughts about this ``new feature". After all, it's Sunday, & I should have better things to concern myself on this day of rest than computers.

    Yet I hope that the folks responsible for this ``new feature" weigh the plusses & minuses carefully: if they can't make it work without emasculating it due to security concerns, then don't bother diddling with this.

    The reason is this: there's this company up in Redmond, WA that is eager to deliver us all of this k-rad k3wl software, but because security puts a crimp in all of their 3l33t featurez, they don't consider security. It crimps their style. And as a resutl knowledgeable computer users hate them.


  • Now that I've read about the ability to support additional protocols/urls, I'm revising and extending my remarks:

    Ok, it's somewhat cool, but how about making Linux Netscape take less memory, and not crash every twenty pages before adding these new features? :-)
  • So, why would we want to do this? Wouldn't it make it easier to develop on the server, where you can control the environment? Isn't the PC dead?
  • A web browser that can execute CGI's all by itself. That's soo cool! We have little web-based apps that are very usefull to our sales staff but they can't get to them on their laptops when they are away. We've been thinking of installing web servers on each machine but then you have to worry about installing it, setting it up, security, all that garbage.

    Being able to do it right inside the web browser is a great idea. Now, lets just hope it isn't as buggy as JavaScript!

  • It's a trap, designed to look like something at RedHat. It actually resolves to
  • Most web sites are Java-based

    It is foolish to write a site that depends on java. That mistake is right up there with using Microsoft tools that only display properly on Microsoft browsers. (Unless you're Microsoft, of course. For them it's good marketing.)

    One big reason is that a significant fraction of the potential audience browses with java and javascript disabled due to concern over security flaws. (Given that there's a netscape hole that lets a hostile site set up a server on YOUR machine to publish every file you can read, AND notify the hostile site that this is up and running, it's a reasonable concern. B-) )

    So if you want a web site to reach the max audience, either forget java or provide a non-java alternate functionality.

    CGI runs on the server, so you only depend on the client browser's ability to display.
  • CGI means.. Common Gateway INTERFACE. To many dumbasses out there think CGI is a C program or a perl script or whatnot.. It isn't a program, its an INTERFACE. All web languages use CGI, java, mod_perl, mod_python, everything. When you put text in a textbox, and hit submit, thats normally CGI. (unless the form uses mail, or whatnot).

    Now personally, is this Mozilla idea a good one? Probably not, only a serious developer would need this, and a serious developer already has a webserver on their LAN. And if you are worried about being on the road, make the web server accessible via SSL and some type of login method. If you don't wanna do that, put apache on your web server. On my pentium 75 laptop, with 16 megs of ram, it only takes .021 seconds for php to server a page that says, "Hello World". :)

    Ohh wait, are you complaining that a web server is too hard to setup with ssl?

    cd /usr/ports/www/apache13-ssl;make install
    cd /usr/ports/www/mod_php;make install

    damn, that was too much effort.
  • by hwaara ( 226026 ) <hwaaraNO&SPAMgmail,com> on Sunday January 28, 2001 @09:58AM (#474884)
    This Protozilla project is in no context official! It's a Mozdev project, therefor it doesn't have anything to do with! So, why is the topic " releases Protozilla"?
  • Note that this is not an "officially blessed" release. This is a release by a third party, on the mozdev web site.
  • Also don't forget, in order for the script to run, there must either be a compiler (as in perl) or the executable must be compiled for that platform. I.e., this idea sucks, and I beg someone to convince me otherwise.
  • by Morgaine ( 4316 ) on Sunday January 28, 2001 @03:44PM (#474887)
    For the greatest flexibility, the central star-point of a communications I/O multiplexer has to be the operating system, not a windows manager as in W95 (partly) nor an application as in Protozilla.

    We're seeing the same old and discredited mistakes of yesteryear repeated here. Yes, this makes Mozilla vastly more powerful, and it is easy to see how its developers would appreciate such a facility for experimental purposes, but for the end user it is the wrong approach. Architecturally, it is the wrong design, and pragmatically it's the wrong thing to do as well: when Mozilla crashes, you do not want a pile of network services to go down with it.

    Yes, I know it's advertised primarily as a hook for experimentation in protocols, but if any real service is ever delivered over it then we all lose.
  • by Eil ( 82413 ) on Sunday January 28, 2001 @03:48PM (#474888) Homepage Journal

    I think this represents one of the few flaws in the Open Source philosophy. Because developers are working on their own time, they work on whatever suits their fancy. More often than not, this involves some great new feature that's completely unnecessary, but rates high on the "cool-factor". So the things that really need to get done are delayed.

    Netscape's programmers are paid to work on Mozilla. I would guess about 80-90% of the Mozilla development team is Netscape employees. So in other words, yes, Mozilla is open source but it is most definitely not a volunteer project. And I can tell you've never visited the bugzilla site, because bugs that interfere with functionality (crashing on startup, etc) always get highest priority and are usually the ones to get fixed first.

    I agree with you in that the bloat is excessive, but it's really beyond anyone's control at this point. I can only hope that they continue with the bug fixes long after 1.0 and make it the best damn browser suite they can.

    Based on the history of the project, I believe it can be done.
  • While many readers have taken pains to point out that this is really a mozdev project, and others have opined that this is great or just a yawn, we may have missed the overall point here..

    Since mozilla's architechture is open and documentated, we are begininng to see more and more projects (been to mozdev lately?) that are extending the traditional "web browser" into something we cannot even fully comprehend yet.

    Mozilla itself may not be ready for prime time, but the *concept* of a stable base on which to build other nifty tools is.. well.. like LINUX itself.

    Way to go mozilla team. Hopefully next year, we wont have to have these "its too bloated" and "no its not, its our savior" arguments anymore - we can just sit and surf like we should.

    "We should not enthrone ignorance simply because there is so much of it."

  • While this is true, how should Protozila know which parser to start? And if it would start the right one, let's say PHP, how would it emulate the differences between the "pure" CGI version of running PHP and the mod_perl one?
  • Please make browser that works ! (and dont add another uselless feature)
  • more fluff. Shame that this project has* still* not released what it promised.

  • I think the original poster meant 'server side java', but even then, I'd still question that claim about 'most' sites. My guess is that more sites are powered by 'asp/vbscipt' on the server than java on the server.

  • by blaker612 ( 124510 ) on Sunday January 28, 2001 @10:07AM (#474894) didn't release this, it was someone's project at MozDev. You clearly know this, since you linked to
  • I understand that this could be a nice feature and all, but a finished, functional, and [Ff]ree browser would be even nicer. Note that Netscape = 4.x is not functional (I've had to write cross-browser Javascript, and lemme tell you, NS is _not_ standards-compliant in any way, shape, or form). Opera is shaping up to be a very nice browser, but it's not free (as in beer), so I can't expect people viewing my websites to use it. So basically, if one of my clients wants to do something really cutting edge with their website, right now I have to tell them, "Fine, but that functionality is only going to work in IE 4 or 5, or Opera 5". I hate doing this, because I despise Microsoft. I keep checking back at Mozilla's site, waiting for the damn thing to get out of beta. But everytime I hear about Mozilla, it's "Mozilla added this great new feature...but they're still in beta."

    I think this represents one of the few flaws in the Open Source philosophy. Because developers are working on their own time, they work on whatever suits their fancy. More often than not, this involves some great new feature that's completely unnecessary, but rates high on the "cool-factor". So the things that really need to get done are delayed.

    This happens in a lot of volunteer organizations. In one organization that I belong to, we rotate cooking a meal before the meeting. We can generally find someone to cook, but it's very difficult to get people to clean. Why? Because cooking is a kind of "glory" job; if you do it right, you'll get compliments and thanks. Cleaning, on the other hand, is just as necessary, but people that do the cleaning aren't noticed or thanked.

    So, in closing, I'd like to thank all of the under-appreciated people who make Mozilla a _browser_. And I'd like to tell all of the people who are busy bloating the hell out of it before it even gets out of beta to STOP killing a great product. If you really want to help, work on the rendering code, or the Javascript interpreter. Heck, just use the browser and submit bug reports so that they're found and fixed faster. Just stop killing on of the few alternative browsers that are available.
  • I had actually thought of this before. Only, the reason I wanted it was to be able to make an HTML inerface to programs on my own computer. I made a skinnable app for windows once, that used HTML image maps as it's skins. I think this kind of things would be really useful and flexible as a program's interface.
  • handle any existing protocols (like finger)

    Actually, in mozilla, that's built in. Try [finger]

  • Developing Protzilla

    An anonymous reader wrote in to tell us about Protozilla's first alpha release. "Protozilla enables Mozilla to execute any CGI program on the local disk directly, without passing it through an HTTP server. It also allows stateless interprocess communication, the use of external programs as protocol handlers (telnet, ping, etc.), and the use of local-only pseudo-URLs (similar to about:)." This is a project by independent developers unconnected to the Mozilla browser effort that adds a lot of neat functionality.
  • Thanks for the clarification, but using a Java SecurityManager in a Servlet container would allow me to not only segment users with different security privileges, but considerably finer-grain privileges than those provided by UNIX security.

    And as much as everyone rags on Java speed, Servlets are far and away faster than CGI.

  • Protozilla is NOT a new idea. Just look at how w3m gets things done! [] w3m uses a local CGI to do bookmarks and other things. This setup is nice because the browser executable is very small, and all the peripheral functionality is implemented in separate executables.
    • CGI, under UNIX, is the best method of allowing secure dynamic content creation in the case of multiple users. mod_perl, mod_php, etc, do not permit security boundaries between the users.
    I don't understand this. As far as I know, CGI scripts all run as the same user the web server is running as. Why is that more secure than PHP? More specifically, how can you claim that this puts some kind of "security boundaries between users."

    I suppose you could run the HTTPd as root and use the HTTP Basic Authentication info to su, but then you're running your web server as root, which is considerably less secure than running it as an unprivileged user.

  • Someone correct the 'informative' moderation on parent post. mod_perl, mod_php etc are not run via CGI. They are quite similar to things that use the fastcgi interface, however. The important difference is that with cgi, every request is dealt with by launching a new process, whereas under fastcgi or mod_* the program doesn't exit, it's still running when the next request is made.

    So the parent is misinformative.

  • That's pure rubbish. There are lots of other interfaces between code and the HTTP protocol and HTML return results. For example, the Java Servlet API provides an interface that is not the same as CGI but exposes pretty much the same set of functionality to Java apps. I don't know whether FastCGI and other "interfaces" expose the same API and are simply different at the implementation level, but I would imagine they provide a different interface at least to some extent because CGI implies separate processes spawned for each HTTP request/response, whereas most alternatives to CGI don't use one process per request.

    If you want to see what CGI really means and what is CGI and what is not CGI, please refer to the CGI spec []. CGI refers to an interface that requires a set of environment variables to be set, passes in POST and PUT information via stdin, and returns HTTP response results on stdout.

    This allows almost any language to be used to write CGI programs (C, perl, tcl, bash, whatever you want). But it doesn't imply that every interface to the HTTP protocol is CGI.

    • it can run ASP, do all sorts of database stuff, etc, locally without needing a real web server.
    But... but... if you're doing ASP programming, you're already not running a real web server!

    (Unless you're running Halcyon's Java-based ASP engine under Apache Tomcat, but that's just the first step on a road to madness.)

  • by chromatic ( 9471 ) on Sunday January 28, 2001 @10:24AM (#474922) Homepage

    Jon Udell [] had a similar idea at least two years ago (see his book, Practical Internet Groupware).

    There are plenty of programs out there that can work well with just an HTML+JavaScript interface, especially if you have a small database (even a DB_File!) on your machine, and an interpreter for a scripting language like Perl or Python.

    I'm curious to see whether it does anything more than Jellybean [] can... there's something compelling about a tiny local web server with the power of mod_perl and a simple interface that lets you build persistent, network aware applications that can replicate data between clients. With XPCOM, it's certainly possible to write a nicer interface than one that only has HTML Form widgets and some onClick handlers.


  • Uh, not all of them are. First of all CGI implies one process per request, which isn't (I believe) true of PHP, nor do I believe the Zope engine or mod_php to be "built on top of" CGI in any way. They use an interface similar to CGI but only in the sense that CGI is basically trivially obvious. Also, Java does NOT use CGI at all. I've never seen nor heard of a Java CGI program, although again it would be possible. The Servlet API is the usual alternative in Java, which uses an interface quite distinct from CGI to glue together HTTP and Java code that produces HTML or other documents.
  • I just want a browser. A simple browser that runs on UNIX / Linux.

    You do?? Shit, I don't think netscape/aol got word of this, I'll get on the horn to them right away. I'll say, "damn it, josepha48 just wants a browser, what are you guys doing!!"

    Netscape does not follow the average hacker's agenda or requirements. It has a design, that includes a mail client, composer, etc, and thats what they make. Does it matter that the mozilla includes these things? If you dont like them, dont use them. It's not as though the mail client is resident in memory if you're not using it, just the browser is. If you're going to argue that they are wasting development effort on the other things, thats wrong too, because they have plenty of people working on each component. If everyone at netscape was working on just the browser, jack shit would get done.

    As for the plugins, Edit, Preferences, Navigator, Helper Applications. Configure your normal apps for those things. Additionally, the Netscape 4.x flash plugin works under mozilla. Just copy it to the plugins/ directory.

    (I'm not blind to mozilla's performance woes, however. But blame that on lack of usage of native widgetry, and usage of XUL.)

  • but most websites do not use CGI anymore.
    mod_php, mod_perl, mod_python, zope, roxen, ...

    greetings, eMBee.

  • I just compiled my daily build of Mozilla a few hours ago, and while I havnt yet tested it, As a hard core mozilla user, and bug reporter, this should really spark some attention to Mozilla, since this is something that even 'the great and powerful IE5' can not do.

    It doesnt seem to be in Mozilla yet, after reading the article, and tinkering with my new build, but still a wonderful idea. But how can it interact with other files that need to be on the server that you dont have? And what if you dont use absolute URLs? Im curious to see how it handles stuff like this.

    Mozilla is really getting stable, I know some peoples opinions of Mozilla are tarnished, but seriously, give it a try, its come a long way in the past 6 months, I havnt used anything else in months. And please dont compare the current Mozilla tree to Netscape6, They are not the same thing. Netscape took Mozilla M18 (which is old nowadays) and messed up a very decent product. Try out the nightlies, then if you want to flame it, your at least qualified to do so.

    And lets not forget that Mozilla 0.8 is supposed to be released the first week of Febuary, 1.0 is expected as early as Mid-April. We're almost there!!
  • I would think this might be a script kiddies dream. Couldn't it be used to exploit local variables?

    Well, you know that if some other big company introduced it as a feature for their browser, everyone would be all over it in a heartbeat. Can you say "format c:"?

    Fortunately, it is something that you have to actively seek out. It is not pre-packaged.

    And you would suppose that developers would be up to speed on security and protection vs hackers and kiddies and industrial espionage

    It is likely not to be broadly used by the public at large. Not until someone includes it in the public version of their browser.

    Maybe MS will include it in the next version of their browser. One could only hope?

  • Because it's so hard to run a web server on your development machine! Whatever.

    And how well will you be testing your CGI, if you're not running it in the same (apache/thttpd/whatever) environment as the real server? You'll probably end up wasting more time modifying your code after the fact than it would take to set up a local web server!

    Wow, I must be in a bad mood today.
  • by Pulzar ( 81031 ) on Sunday January 28, 2001 @08:45AM (#474935)
    Looking at the White Paper [], executing CGIs locally is just one of the features of Protozilla. A more interesting feature is the "protocol handlers" feature -- you can assign any external program to handle any existing protocols (like finger), or you can define your own protocols and assign program (or URLs!) to handle them!

    For those afraid of the security issues associated with running CGI scripts locally -- this is a development tool only. In order for a script kiddie to misuse this, (s)he'll have to send your the CGI script in the mail, and tell you to run it for him :). Unless you're running Outlook, you're ok ;).

  • For anything meant for a market, I don't think it's good. However, it could be useful for experimentation. The first thing I thought was "security hazard". Looks to me like a developertool, not consumer-technology.

  • Surely you mean insecurity settings? :)
  • CGI means.. Common Gateway INTERFACE


    All web languages use CGI, java, mod_perl, mod_python, everything.

    Incorrect. There exist several other interfaces to use for dynamic content generation. ISAPI, NSAPI, and fastCGI are all faster alternatives.

    When you put text in a textbox, and hit submit, thats normally CGI.

    OK, you're quite some way from the truth now. When you put text in a text box and hit submit, you are performing a HTTP GET or HTTP POST. Whether the web server then uses CGI or fastCGI to interface with an out of process executable, or one of the many ways of dealing with the request in-process, has nothing to do with your form.

    (unless the form uses mail, or whatnot).

    You've finally lost me there. Could you explain how a form can "use mail". Surely you aren't talking about hyperlinks to mailto: URLs, which have nothing to o with forms?

  • by asa ( 33102 ) <> on Sunday January 28, 2001 @11:17AM (#474948) Homepage did not release Protozila (or Protozilla). This is an independent project that is being developed at is not a part of
    From the mozdev front page: is the location for development projects based on the open source Mozilla project. Anyone interested in Mozilla is welcome to look around and try out any of the more than 20 projects hosted on this site, and anyone working on a project is welcome to host their development here free of charge.

    The projects currently on include a number of the development projects that Alphanumerica had been developing. After Alphanumerica's merger with CollabNet these development projects were integrated with SourceCast, CollabNet's project hosting tool, to create
    While this project is not being developed (or released for that matter) from within itself, it and other projects at mozdev demonstrate how mozilla technologies can be used and extended and how the community of mozilla developers has and continues to expand "beyond the browser".
  • CGI programmes need not run as the owner of the web process. You can have a process with the necessary privileges for switch userid interposed between the webserver and the CGI process.

    CGIwrap, Apache's suexec, etc support this via setuid binaries. Zeus has some sort of CGI spawning daemon. The webserver itself need not and should not run as root. One or the other method should work for almost any webserver which runs on UNIX.

  • by llywrch ( 9023 ) on Sunday January 28, 2001 @11:19AM (#474951) Homepage Journal
    > I would think this might be a script kiddies dream. Couldn't it be used to exploit local variables?

    Interesting point, now that I have thought thru your question, & read the source page. What they wrote at Mozilla is:

    > Protozilla is a browser add-on that makes it very easy to implement protocols in Mozilla (or Netscape 6.x). It is not a
    > traditional browser plugin, but may be described as a "socket adapter", like the kind that you may carry around with your
    > laptop when you travel internationally.

    In other words, an ability to handle protocols like SMTP & NNTP akin to the ability of specifying helper-applications to handle MIME types. (And if this works with the Gecko rendering engine, you can specify your own choice of MTA or newsreader when you hit the link that requires that protocol, instead of being forced to d/l the whole bloated mass of Netscape!)

    And if the admin for the workstation running the browser has done a proper job securing the ports, then there should be no new security issues.

    My assumption -- & someone who knows more, correct me if this is wrong -- is that the browser add-in, being a daughter process, would inherit the environment the parent process has -- & ultimately that of the user. So unless you are doing something stupid like running your workstation as ``root" or ``Admin" this won't do anything to your computer worse than you can do in a non-privileged account. In other words, if *you* can't ``rm -rf *" & lose more than a few files, then neither can the enabled protocol.

    (Although it would be even safer if anything that ran in this wise ran in rsh as ``nobody".)

    However, I doubt anyone truly knows how security & environment variables are handled under NT4.0/Win2000, so maybe we do have another exploit waiting to happen in certain cases. Wouldn't be the first time MS coding practices proved injurous.

  • by burris ( 122191 ) on Sunday January 28, 2001 @10:41AM (#474952)
    This is a great idea. Now you can have easily special handling for URLs into distributed filesystems like Mojo Nation or Freenet without having to add another proxy to your long chain. Instead you have a special url like mojo: or freenet: and only those URLs are sent to your proxy, instead of every URL. This is a blessing because now there is much less chance that an added service will disrupt a users regular web browsing (which can happen if you chain your proxy in with all the others and it turns out to be flaky). Users are willing to try new things but they get very unhappy if their regular web browsing gets disturbed.


  • I was thinking much the same thing-- Nice idea, but it's a veritable viral breeding ground. (well -- trojan/worm, anyways). Before it's publicly useful/safe, I think that some real work is going to be needed in the area of security/sandboxing.
    (secure Linux, here we come!)
  • by Anonymous Coward on Sunday January 28, 2001 @08:50AM (#474960)
    why too much? netscape had a built in web server years ago.
  • OK, so I recently discovered PHP too, and I think it's a lot better than plain Perl CGI.

    But you should see CGI as a low-level protocol (the Common Gateway Interface) for transferring data, not as "a webscripting environment for Perl".

    And you should (definitely) see PHP as a high-level language using the CGI protocol internally (to transfer form data, mostly).

    I guess it's valid to compare the difference between PHP and plain CGI to the difference between Bonobo and plain CORBA (for as far as I know Bonobo, this seems quite a useful comparision).

    It's... It's...
  • Protozilla wasn't released by Mozilla. It was released by via the Alphanumerica/ merger. They have been pushing Mozilla stuff ever since.

    Protozilla is great stuff. There is some really cool stuff you can do. For example you can write javascript or a bash script within Mozilla to do crazy stuff.

    I created a cups:// protocol for the Common Unix Printing System. Basically since cups runs on a non-standard port I can just do a :


    which is cleaner IMO.

    There are some significant security concepts here. Your web application could use XPCOM and XSLT to build a full web application BUT use different users to request subsets of the same content.

    For example... My primary psuedonym could request the first part of my document (cars) then on the second part it could request contra-band like DeCSS et al. This without having my car psuedonym exposed.

    Good stuff. Here comes the semantic web!
  • Nifty. Should make it easier to extend Mozilla with new protocols. Mozilla could well become the browser of choice for file sharing.
  • by NoInfo ( 247461 ) on Sunday January 28, 2001 @08:57AM (#474977) Homepage Journal
    IE can already do this in the beta .NET stuff.. Not only that, it can run ASP, do all sorts of database stuff, etc, locally without needing a real web server.

Established technology tends to persist in the face of new technology. -- G. Blaauw, one of the designers of System 360