Hold on a sec. Why is such an intense library for javascript written IN javascript. This should be part of the browser. The same happens in perl... the underlying lib is written in c, but the interfaces are perl using XS.
Welcome to the world of web development where a certain monopoly holder uses his powers to let the majority of web users use a insecure and feature lacking browser with no intention to enhance it before there's a new technology to lure users into with it.
Yes.. browsers could implement a lot of really nifty things and you could do marvelous things with that but as long as the browser market does not change significantly there is this technology which works now.
This is javascript we're talking of. All scripts have to be transferred to the user. Implementing XPath in javascript is doomed to be a monster.
(Look at this for example. 100kb script library and the client code using this API will look clumsy and not as descriptive as JSON code. The javascript-RPC client api I wrote is about 4051 bytes, the server part 5853 bytes without any size optimization.)
Not the DOM is the problem, the implementation of a the javascript DOM doesn't work well for this kind of problem.
IMHO the only reason to use XML in javascript is that you absolutely WANT to. There's really no need in using to travel a DOM or using XPath when you can use nicely nested javascript objects with descriptive members.
That's what I've been wondering about too. Does this newer tech have some inherent advantage over the hidden iframe method? Is it just more structured?
The XMLHttpRequest has the advantage to be a little less of a hack and to support HTTP-POST.
You could use the JSON as message format with hidden iframes, too.
The problem we are solving is that XML handling in javascript is cumbersome. JSON offers a very simple solution to provide client java scripts with a normal javascript object without the need to use any DOM parser. This is the second easiest solution right after sending html text blocks to replace the html embedded in the original page. And the responses generated by this approach are much shorter than html text blocks.
Now my clients' computers can be compromised even faster because this language/protocol is "light weight".
If you can't write a secure web application you are fucked in any case. If the web application is well written this makes absolutely no difference from a security point of view.
In most cases implementations will use this as javascript enhanced alternative to a static html page based web application. The website will expose the same objects with the same data it does via html. The only difference being that the html data is layouted and the JSON data is raw.
And even if you use JSON as only means to use your website it makes no difference in security. You just have to design a RPC API which is secure enough for your purpose. And you have all the means available to make this RPC API secure. SSL, Authentication, Access control, all that can be combined with JSON if you want to.
Although I haven't called it JSON this is kind of exactly what I called "javascript views" in my web application toolkit. One small part of my project uses serverside java to generate dynamic javascript objects which are a javascript representation of nested java object graphs. The syntax of the generated js object source is a bit different because I did not know that the language constructs used by JSON exist (I think I'll switch to JSON very soon).
[...]
Note that views were strictly one-way in this model -- all program logic was done through the controller, which had to be aware of all the views being used in order to generate the right inputs. In other words the Model was the program state, the view was procedures for displaying model objects, and the controller did absolutely everything else.
How on earth this antiquated model stuck and transferred to web applications is beyond me. It shares almost nothing in common, except for a very under-specified "controller" class that has the very simple job of "doing everything except rendering". MVC is about as meaningful as "client/server" these days.
As an author of such a MVC webapplication toolkit and runtime engine I asked myself similar questions in the early design phase.
But my answers to these questions seem to be different from yours:
It is not true that the traditional Views were "strictly one-way". Where do you think the controller got its events from? Buttons and other controls embedded in the views.
The Controller of a webapplication receives the requests the user makes, associates the stateless requests with a session, interprets the semmantics of the specific request in the webapplication and send the appropriate view back to the client. Sounds to me very similar to the classic MVC.
MVC is primarily used in web application descriptions to distance them from a purely page-based structure. I highly doubt that this waters down the MVC term to the level of "client-server".
You normally just create a xml file which has the info on which methods are asociated with which views. Most of the application flow is in said xml, so your business logic is pretty insulated.
I never really understood the reasoning for defining the application flow in an XML descriptor.
Insulation or separation is nice but against what do you want to insulate your application flow?
You normally want to prevent the web documents itself managing the application flow thus leading to an incomprehensible mess of cross invoking documents.
in what way does a coder differ from a graphics artist? according to stallman's views, should a graphics artist not be able to freely obtain the art of a game so he could modify it, without having to pay for it? after all, that is what he demands of software. it has to be free so a coder is free to change it without having to pay for it. does he have double standards?
You're basically reproducing a common misunderstanding of the Stallmann / FSF / GPL position.
Although the GPL can make it more difficult to earn money from software it does in no way require the software to be free of charge.
RMS observed a basic injustice: The tendency of binary only software to lock in its users, to surrender him/her to the whim of the developer. RMS postulate four kinds of freedom which must be true for software and which the GPL is based on philosophically.
Works of art do not put such shackles on their recipients (Art doesn't have users - there is no algorithmic dimension to it) - and that's why there is a difference.
Even better, Debian often sabotages config files to force the admin to spend at least a little time looking at a config file before firing up some daemon.
I would call this theft, since it forces me to adopt GPL for my own code.
a) copyright infringement is not theft.
b) Nobody is forcing you to do anything with your code. You have the copyright on your code. The GPL does not change that. It only states the rules under which you are able to use other people's code which was put under the GPL. Those rules do not allow linking of GPLed code into non-GPL code.
You don't have to use that spell-checker. but if you do, you have to follow the GPL rules.
Eclipse is pure java, too. Oh, unless you don't consider SWT to be pure java, [...]
SWT uses platform specific libraries/DLLs, so the pure java claim for netbeans is not only technically correct but also in its meaning "running everywhere a VM is available".
Eclipse can use Ant to build a project. I don't know if it's the latest version, but for all basic purposes, the version included is good enough. I don't know if there's an Eclipse plugin that automatically updates build.xml or lets you handle it in a graphical way, but I think ant build files are meant to be hand edited, anyway. You can use XML buddy inside Eclipse to validate the XML.
Even the old 3.6 way of supporting ant was superior to the way eclipse handles ant scripts (integrating targets into the UI etc).
The new netbeans 4.0 project system is really good. Ant is the project system so netbeans projects can be build without netbeans.
There is even a wizard to import hand edited ant files as project. the ant files aren't even changed for that. beautifull.
Netbeans can not only validate ant scripts it offers element completion for ant targets etc.
And that stuff about using the NetBeans platform, sounds like the stuff Eclipse includes now with 3.0, where you can build your SWT apps using the same objects that make up the Eclipse IDE.
.. with the only difference that netbeans had the seperate platform for ages and lots of applications are already using it.
For me CTRL+L/CTRL+K was such a killer feature.
It cycles forward/backward through a list of words which start with the same chars as you just typed.
it's just wonderfull.. completion for any word, be it in code or comments.
I think a lot of Linux zealots tend to downplay the importance of the home directory. After all, if you're a smart user and don't run as root, all your important data is going to be in the home directory (and possibly other directories where your user has permissions). I could care less if the OS install gets wiped out -- that can easily be replaced. The data in my home directory can't. In that regard, losing your home directory is just as bad as losing the entire system.
The home directory normally only includes data and settings. It's not fun if you lose data ( if it's important data you should have backups ), but it's worse to have a system compromise where the attacker can control your system, install backdoors to use your system for every purpose he can think of and can even fry your hardware in some cases.
It is not exactly a failure of the secure sandbox environment. If you were running a standalone Java application or a Java Web Start application in the sandbox this hole wouldn't apply. This hole applies to the _C_ code that manages the Java plug-in.
Well.. the result of this vulnerability is a circumvention of the sandbox environment
( not in C code but via Javascript
).
You may argue that the sandbox in itself has not failed which is formally correct, but a hacker shouldn't be able to circumvent it via javascript.
So; johnny hacker writes his Java exploit; part of which decides what OS it is currently fiddling with, then has it deposit an appropriate payload for the OS.
Voila; spreads through Windows and Linux.
.. except that this vulnerability will escalate the privileges to that of the user which runs the browser if exploited, so in Linux it can "only" trash the user's home directory.
Not that critical? 1.5 was released in the last month. What do you think all the people were using before last month?
It seems to me that Applets are dead. I am a java developer and have often browsed for months without encountering the need to tell my browser where my java is.
So most of the people are using java for applications or server-side programming.
Add the fact that this is only a theoretical vulnerability with no known exploits and the fact that not all browsers are affecrted and the conclusion (for me) is "not that critical".
Meanwhile, applications such as Freenet are not working reliably under 1.5 JREs, and 1.4 is still suggested. "Latest and Greatest" is one thing when you're talking about an OS, but with Java, using the latest release is often counterproductive.
Applications like Freenet are not affected by the vulnerability. It only affects the Interface which couples java with a webbrowser (Java Plugin).
Slashdot Mirror
Yes.. browsers could implement a lot of really nifty things and you could do marvelous things with that but as long as the browser market does not change significantly there is this technology which works now.
(Look at this for example. 100kb script library and the client code using this API will look clumsy and not as descriptive as JSON code. The javascript-RPC client api I wrote is about 4051 bytes, the server part 5853 bytes without any size optimization.)
Not the DOM is the problem, the implementation of a the javascript DOM doesn't work well for this kind of problem.
IMHO the only reason to use XML in javascript is that you absolutely WANT to. There's really no need in using to travel a DOM or using XPath when you can use nicely nested javascript objects with descriptive members.
You could use the JSON as message format with hidden iframes, too.
The problem we are solving is that XML handling in javascript is cumbersome. JSON offers a very simple solution to provide client java scripts with a normal javascript object without the need to use any DOM parser. This is the second easiest solution right after sending html text blocks to replace the html embedded in the original page. And the responses generated by this approach are much shorter than html text blocks.
In most cases implementations will use this as javascript enhanced alternative to a static html page based web application. The website will expose the same objects with the same data it does via html. The only difference being that the html data is layouted and the JSON data is raw.
And even if you use JSON as only means to use your website it makes no difference in security. You just have to design a RPC API which is secure enough for your purpose. And you have all the means available to make this RPC API secure. SSL, Authentication, Access control, all that can be combined with JSON if you want to.
Online Demo showing the javascript view feature.
Project Documentation.
( Funny thing is my story about this was just rejected this morning.)
It is not true that the traditional Views were "strictly one-way". Where do you think the controller got its events from? Buttons and other controls embedded in the views.
The Controller of a webapplication receives the requests the user makes, associates the stateless requests with a session, interprets the semmantics of the specific request in the webapplication and send the appropriate view back to the client. Sounds to me very similar to the classic MVC.
MVC is primarily used in web application descriptions to distance them from a purely page-based structure. I highly doubt that this waters down the MVC term to the level of "client-server".
Insulation or separation is nice but against what do you want to insulate your application flow?
You normally want to prevent the web documents itself managing the application flow thus leading to an incomprehensible mess of cross invoking documents.
Then why not define the application flow in code?
Although the GPL can make it more difficult to earn money from software it does in no way require the software to be free of charge.
RMS observed a basic injustice: The tendency of binary only software to lock in its users, to surrender him/her to the whim of the developer. RMS postulate four kinds of freedom which must be true for software and which the GPL is based on philosophically.
Works of art do not put such shackles on their recipients (Art doesn't have users - there is no algorithmic dimension to it) - and that's why there is a difference.
There was an article about those flaws.
which only one was nearly as dangerous as this but was fixed in the current mozilla, firefox versions.
b) Nobody is forcing you to do anything with your code. You have the copyright on your code. The GPL does not change that. It only states the rules under which you are able to use other people's code which was put under the GPL. Those rules do not allow linking of GPLed code into non-GPL code.
You don't have to use that spell-checker. but if you do, you have to follow the GPL rules.
There is even a wizard to import hand edited ant files as project. the ant files aren't even changed for that. beautifull.
Netbeans can not only validate ant scripts it offers element completion for ant targets etc.
And that stuff about using the NetBeans platform, sounds like the stuff Eclipse includes now with 3.0, where you can build your SWT apps using the same objects that make up the Eclipse IDE.
For me CTRL+L/CTRL+K was such a killer feature. It cycles forward/backward through a list of words which start with the same chars as you just typed. it's just wonderfull.. completion for any word, be it in code or comments.
I'll do all that after I die.
So you would prefer a root compromise?
Mozilla/Firefox on linux will not run anything if I don't symlink libjavaplugin_oji.so to the plugins directory..
java.sun.com is where an administrator should go to.
So most of the people are using java for applications or server-side programming.
Add the fact that this is only a theoretical vulnerability with no known exploits and the fact that not all browsers are affecrted and the conclusion (for me) is "not that critical".
http://java.sun.com/j2se/1.5.0/download.jsp