Slashdot Mirror
AJAX May Be Considered Harmful
87C751 writes "Security lists are abuzz about a presentation from the 23C3 conference, which details a fundamental design flaw in Javascript. The technique, called Prototype Hijacking, allows an attacker to redefine any feature of Javascript. The paper is called 'Subverting AJAX' (pdf), and outlines a possible Web Worm that lives in the very fabric of Web 2.0 and could kill the Web as we know it."
So can I hijack slashdot to always get the first post?
Not surprising considering that slashdot is slowly trying to AJAXify itself...
Haven't RTFA yet, but I doubt it will live up to the hype.
Javascript vulnerabilities will stop people from using AJAX just like Word vulnerabilities will stop people from using Microsoft Office.
Care about privacy? Read this!
Patch the hole and release Web 2.0.1. Good thing there's already a Web 3.0 in the works.
Isn't this the thing that forced the redesign of Greasemonkey a while back?
The roots of education are bitter, but the fruit is sweet.
--Aristotle
"...and could kill the Web as we know it." Oh come on! Isn't that exaggerating a tad? Obviously with some browser patches and more secure server code, the problem is solved. Gotta love sensationalism!
This paper is absolutely ridiculous, and its author is scaremongering --- if you have access to a site's scripting system via some cross-site vulnerability, then you don't _need_ to subvert an object's prototype to change its behavior. If you're relying on client-side code of any sort, be it written in Javascript or C, for security, you're up a creek without a paddle anyway. Oh nooes, man in the middle proxy attacks! Oh noes, browser bugs allowing javascript to leak outside its security context! There is no security vulnerability in this paper that hasn't been known and worked around for years. I'm wondering what kind of agenda the author has in writing this, actually.
Having skim read the article, it outlines how *if* you can execute malicious javascript for a website you can subvert the AJAX communication so that you can have man in the middle attacks etc.
However once an attacker can execute malicious javascript in the scope of the target website you're toast whether you are using AJAX or not.
I'll make a bold prediction and say that is not going to "kill the Web as we know it" contrary to what the /. article says.
Struggling to find a day everyone can make? WhenShallWe.com
a possible Web Worm that lives in the very fabric of Web 2.0 and could kill the Web as we know it.
This statement has FUD written all over it. (or was it written in FUD?)
There is no "I disagree" mod for a reason. Flamebait, Troll, and Overrated are not substitutes.
I hate JS, it Had potential, 8-9 years ago. What we are seeing now is a push way beyond its original intended scope. The truth is, it would have had much less potential for vunerability if it had not been neglected for so long. Every time I have to get down and dirty with it I think of that. Its Ok, and somethings are nice from a shorthand perspective if youre used to other lll, but for GODS Sake , Revise the spec and put some effort into it, OH Wait, but thats been part of the problem all along, MS puts this in, NS/Moz (Used to) and what do we have , something no one entity controls, or even standards of. Whats wrong with putting a friggin python interpreter in a browser ? Ms is running that way with IronPython (Yea Proof of concept I know) but Read Scott G, and Paul W. aticles on dynamic languages theyre a fan. Oh well, back to ajaxifying the planet because my boss dosent like the flash when he clicks buttons on the web ( Oh wait I quit that job 4 months ago....)
Do they ever learn? All of this scaremongering is numbing the uninitiated, and when there is a real threat no one will be prepared.
Well, my BS meter pings off the scale when I see alarmist claims like "shutting down the web." How many of those claims have we all seen over the past years?
I suppose it's the 21st-century equivalent of "The World is Comming to an End!"
I consider that anyone who makes such outlandish claims should be remembered, indexed, marked, and noted. When their claims fails to come true, then we can all stand around and laugh at them and grant them Idiot Awards.
Ruby Neural Evolution of Augmenting Topologies
A Worm that lives in the very fabric of Web 2.0 and could kill the Web as we know it lurks is the deep dark recesses of the javascript
Who is this masked man known as the worm?
Why does he hate Web 2.0 so much?
Will this worm try to make us revert to Web 1.0?
And does this worm have anything to do with disappearances of Web 1.1 through Web 1.9?
This and much much more on the next epside of Days of our Web 2.0 Lives
I think the invisible hand of the market has its middle finger extended
--A wise old fart named SC0RN
Well, considering that AJAX is used on only a tiny proportion of web sites, and often not to particularly good effect, I'd say that's a bit of a silly claim. In any case, AJAX often suffers from the same flaws as pseudo-web technologies like Flash before it: lack of bookmarkability, breaking back buttons, etc. These are far more likely to doom it than any random security flaw.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
You can detect it even from the summary: "a Web Worm that lives in the very fabric of Web 2.0 and could kill the Web as we know it."
Even if JS suddenly stopped working outright today, web wouldn't change a whole lot, from what we know it.
Apparently the guy just comes from compiled languages like C++ where you can't modify a class once its defined, and he decided to spread some FUD to express his disgust with dynamic languages.
I guess he was disappointed he can't safely store his server root passwords in his JS files.
The same thing shows up again and again. Air has pollutions, none wants to stop breathing.
Check out these great functions from the std lib:
...who says Microsoft don't innovate?Goodbye, friends. It seems that this is, truly, the end of the internet. *sniff*
_
For whose sake, henceforth, may his vowes be such As what he loves may never like too much.
If 'Web 2.0' comes to be widely untrusted, it will have to change or die. This doesn't represent any new threat to the web itself. The threats are old and because of their nature have been there from the beginning and aren't going away any time soon.
Loose lips lose spit.
JavaScript S on Domain A needs to access the server side script on Domain B. All S has to do is AJAX to a local bridging script which forwards the request using CURL,LWP, etc to B. The bridge then feeds the response to S. S has no idea that the AJAX request went to another domain. As far as B knows, A is just a web visitor.
Since AJAX runs on the client side it's not possible to whitelist IPs and Referers can be spoofed.
As with every client/server app the client can never be trusted.
Work Safe Porn
One of the biggest issues I have with Ajax and really what the web browser has turned into is Javascript.
Don't get me wrong, I think the language is "alright". The problem is it is the only choice out there.
There are many flavors of Linux and pratically everytype of appliation out there. But only one real choice for scripting on a web page.
Ajax's primary function is the ability to grab content from a web server ( or any server ) and then modify DOM of the web page you are working on.
The could be done by any programming language. Most of the time I use Ajax I just grab some HTML content and blast it into a div or some other object. Here Jscript isn't that big of a deal with a good library.
When I start to have to actually grab the value and parse it that is where JScript is the only option. I wish that browser would stat offering some choice. Maybe Ruby or Python or Perl, don't really care. Just something else besides JScript. Seems like ActionScript might get a chance.
Worm? What kind of worm? Is it like a heartworm? Cause I can just give my PC a pill once a month. Except I don't want to pay for pills. So I'll just use Necco wafers.
See, I'm safe!
Ajax sucks. Not because of security.
The article Why Ajax Sucks (Most of the Time) is a nice spoof of an old article about frames. Despite being a spoof, the word 'frames' replaced by 'ajax' and little else changed, it's surprisingly accurate and nicely outlines WHY it's harmful.
Anagram("United States of America") == "Dine out, taste a Mac, fries"
Anyone know where I can find a non-PDF version of this paper?
AJAX would perhaps be better for inTRAnet than internet where hacking is less likely. At least it is not any more vulnerable than existing desktop apps (VB, Delphi, Powerbuilder, etc.) where the hacker can do anything to the EXE. Internal biz forms can probably make more use of AJAX than public internet stuff anyhow.
Table-ized A.I.
But, yes, there is nothing new in AJAX that causes security problems. It is not new tech, just a style of architecture. The same problems and solutions with respect to security exists for AJAX as for the underlying infrastructure. Java applets, Flash apps, "traditional" Javascripted pages, all have had their trials and tribulations in the past, and their security models are well mapped-out. The sandboxes already exist. AJAX runs within them, not outside.
I haven't read it either, but from experience, I'd imagine it hold up very well.
AJAX applications just aren't solid or stable, for the most part. We tried to integrate a number of them into our network here, and frankly each attempt went terribly. I'd like to think it was just one application vendor or AJAX toolkit that was problematic, but that wasn't the case.
We found a number of common problems with every AJAX application we tried. Just for the record, the applications included three CMS systems, a Web-based email system, two groupware systems, and three Web forums.
The first major problem with one of resource usage, on both the client-side and the server-side. Client-side, many AJAX applications consume far too much CPU time. From our investigation, it was due to the use of poor JavaScript algorithms that'd consume 100% of the CPU in some cases, for minutes on end. The applications "worked", in that they'd provide the correct result. It'd just take them far too long to get it done.
On the server-side, they'd again result in excessive CPU and RAM consumption. For one of the Webmail systems, we could only handle a fifth (yes, 20%) of what our old Perl-based system could. And that was on a quad-core Opteron system with 8 GB of RAM! The Perl-based system was on a couple of 200 MHz Pentium systems, each with 128 MB of RAM. Even after assistance from the AJAX-based Webmail system's vendor, we were only able to handle roughly 90% of the number of transactions of our older system.
The second major problem is that of usability. Many of the AJAX apps we tried didn't play well with browser tabs, for instance. Some even fucked around with text input areas, resulting in copy-and-pasting no longer working. One application even prevented the text within a text field from being highlighted! We thought these problems may be browser-specific incompatibilities, be we ran into this same problem with Firefox, Safari, Opera, and even IE6! After talking with the vendor, they admitted these were known problems, and no solutions were presently available.
The third major problem is a lack of quality. Many AJAX applications are poorly coded and poorly designed. I think the main reason for that is because it's such an unstructured technology. Even competent software developers run into problems that cannot be solved easily, and thus must resort to hackish techniques to overcome these inherent problems.
The fourth major problem was that the users hated the systems. Of the few systems we managed to roll out successfully, the users absolutely hated them. Their complaints were a combination of the above three factors. The AJAX applications would not do what the user wanted. The AJAX applications did not conform to common practices (eg. copy-and-paste, textbox text selection, etc.). The AJAX applications ran far too slowly, even on fast client machines. The AJAX applications just plain didn't work!
All of our AJAX trials were abysmal failures. That's why we're sticking with the existing Perl- and Java-based systems that we currently use. They perform far better on much fewer resources, actually do what the users want, avoid violating the most common of conventions, and they do what they're supposed to. I'm sorry to say it, but AJAX might just be the worst technology I have ever had to deal with.
I don't think Comet is any better.
LMAO
When vulnerabilities of C/C++ stop people from using C/C++, this may happen.
There is a spark in every single flame bait point.
To summarize, if you can get people to come to your website you can make the browser do what you want. Also some plug in have bugs. If you install a plug in it can do thing that are bad.
All you need to know.
Don't add javascript from another site and expect your app to be secure.
Javascript can make a man in the middle attack more effective.
The point is NONE of the vunerablity is in the javascript or the browser.
I have all those problems with changepoint. It's supposed to make our life easier but it's a huge nightmare. It's slow - on my dual core centrino and 2GB RAM it crawls. On 12MB internet link. Plus because somebody forgot to update a code it doesn't work with IE7 (which I use it for testing and sucks) AND Firefox.
Same is with for example yahoo mail. All my friends who used the 'new improved' one, reverted to old one. Too slow and annoying.
There's more examples like that. When finally vendors understand that people want working fast software not beautiful, shiny piece of not working crap?
Just my 2p.
"an experienced, industrious, ambitious, and often, quite often, picturesque liar" - Mark Twain
Sorry, I still don't think that it will "kill the Web as we know it." That's sensationalist, fear-mongering BS.
As well as the dingbat mod who let this crap summary get on /. unedited?
I hate all this crap about "ZOMG, once I can inject javascript into a page, something else makes it totally insecure!!!"
Once someone can inject javascript onto a page, you're toast. The article itself is valid, and isn't complaining about ajax so much as prototyping (despite the title of the paper).
AJAX is a great technology. Yes, if you overuse it or use it in the wrong places then it is harmful. Saying AJAX is unstable, unusable, brittle, impractical is simply an untrue generalization. Like anything else, if you do it right it enhances usability and is quite reliable.
blah blah blah
I'm a professional web developer, amd have been using XMLHttpRequest (ajax, if you really want) for the past two years in a large number of web applications. Having taken the time to actually carefully read (not skim) the eight pages of this document, I have only one thing to say: I want my 15 minutes back.
This is a paper about more efficient ways of being malicious, but they only work if you can be malicious in the first place.
You know what? If a malicious user can insert script to be executed for another user, I already have an unacceptable problem! I really don't care if that unacceptable problem is now 10% worse than was generally realized before.
Have you ever considered that those could all be badly programmed? I mean, I could write a Java program that took tons of resources, ran really slowly, didn't allow text selection, and more. And I could write an Ajax application that ran far faster than the equivalent non-Ajax one.
As for your specific case of a text field being unhighlightable, I suspect that has to do with the Ajax application using onSelectStart to disable selection within the page (sometimes as really crappy DRM, sometimes because click-and-dragging is needed for some other functionality), and not knowing how to re-enable it for the text field (which is something I, a 16-year-old, know how to do). Problems like the ones you describe are usually caused by vendor incompetence.
Ajax, by itself, can't possibly cause any of the problems you describe. All it is is a system by which Web pages can interact with the server without needing to load a new page. This means:
1. Less bandwidth is used because you don't need to load layout information for each page. Consequently, it's faster than non-Ajax applications.
2. The Back button goes to the last page, as opposed to the last action, which is a good thing for true Web applications, since the Back button usually causes tons of problems (Ever seen "DON'T PRESS THE BACK BUTTON OR YOU COULD ACCIDENTALLY PAY FOR THIS PRODUCT TWICE"?).
3. If coded to do so, the server can relegate translating raw data into a human-readable HTML layout to the client. This is usually done because the client usually has many processor cycles to spare, while the server doesn't. (This also doesn't take much processing power, and should be unnoticeable to the client)
4. You have more control over page transitions, and you can have things like "Loading..." messages while the data is being fetched from the server (as opposed to traditionally, where the only indication is "Loading..." in the browser status bar and the top right loading animation, and then, when it loads, the page goes white and the new layout is loaded.)
Those are the only differences. So, in reality, Ajax is superior in every way for Web applications, and the problems you describe are caused by bad programming practices, and would've happened whether or not they were written in Ajax.
Want a high quality FOSS RTS game? Try Warzone 2100!
Damn Right! If you mix that stuff with a chlorine bleach, the fumes will put you straight in the morgue.
We are all just people.
This technique requires the prior existence of a full-exploitable XSS hole before it can work; otherwise the script which modifies object prototypes never loads and never executes. Again, the author of this paper is simply saying, "if your site has an XSS hole I can use an XSS exploit against it". This would be akin to a physical security expert pronouncing that he can get into your house if you leave your doors and windows unlocked, and is not earth-shattering or insightful in any way; the only reason it's getting press is the mistaken belief that use of object prototypes constitutes a never-before-seen technique, and that's debatable; even if no-one's ever actually tried a real-world exploit with this technique, any JavaScript programmer with his or her salt knows it's possible.
(Yawn) Death of the internet, ho hum.
It already died. In 1996. Bob Metcalfe said so, didn't he?
"How to Do Nothing," kids activities, back in print!
all the vulnerabilities discussed are not new.
I'm not sure how they managed to convince anybody these are "new" to AJAX.
Everybody's known about Javascript XSS issues for a while and the http cache/proxy issues as well
Do they get bonus points for calling them AJAX vulns? I hope not.
Fortunately, on my team, I'm not allowed to use AJAX (even XML-free Javascript) or Cookies to develop web applications -- for security reasons. Other teams have AJAX programmers on staff, but that's only for the slick b2c stuff, not the actual b2b stuff.
Yup, everyone i know has stopped using it.. Microsoft is going broke since they cant sell MSO anymore.
Nah, people really dont care/understand/know.
---- Booth was a patriot ----
You've stated quite an amount of vagueness there, sir, not to mention this confounding statement:
Very interesting, seeing has how AJAX has nothing to do with your server-side technology whatsoever. Or how about this:
Again very interesting, seeing as how AJAX itself has nothing to do with the way users interact with form elements.
It sounds to me like either 1) you're BSing, which is my actual guess, or 2) your and your team have no idea how to actually code Javascript/AJAX/whatever, and you picked crappy packages off the internet and expected them to Just Work out of the box the same as your custom built solution.
Your problems have had nothing to do AJAX; rather, they have had to do with either your lack of knowledge or your life as a Slashdot troll.
The United States of America: We do what we must because we can.
I'm no JS expert, but it would seem that an easy fix is simply to contextualize JS prototypes - One document/frame can't modify prototypes for another.
This has been partly covered by others already, but this attack really isn't that hard to prevent. In order to perform this attack, the attacker has to first be able to post JavaScript code onto the page. This would be something like putting JavaScript code into your posts on /. or some other website that allows people to author content on the Internet. /. is already safe from this attack. They don't let you put JavaScript code in your posts. That's pretty standard web programming security (filter input, escape output).
I suppose he could still inject the code by putting javascript: [put code here] in the address bar. Don't believe me, try this...
javascript: alert('It works');
But even then, the code injection is still limited to the attacker's session only. Oh, no! he can capture his own information. The world is comming to an end!
On a serious note... I hadn't thought about extending XMLHttpRequest like that for a security vulnerability. I'd give him credit for thinking that up.
I can see where attacking the prototype might expose some risks to phishing attacks. The attacker would need to get your domain to issue the bad script code, so the usual hardening techniques (don't trust input, don't accept any executable script code, etc.) would help.
I'm wondering if making the hard-to-guess pointers to standard objects (xmlHttpRequest) could neuter this attack. When your page first starts, you copy the standard prototypes to function names known only to your server.
"We receive as friendly that which agrees with, we resist with dislike that which opposes us" - Faraday
Prototype overloading isn't special. It's no more risky than getting the opportunity to run _any_ code against the target. You still need to craft exploits directly against the websites in use, except the easier passive sniffing of the native xml functions might mean less code has to be inserted in the client side. You still have to know what to do with the sniffed data on a per-site/program basis.
I just consider this an efficient use of javascript. It's not enabling anything that couldn't be done already.
The important user data for almost all sites is stored on the server anyways, not being sent over the wire, and if it were, it would require much specific effort to make the data usable.
It's not a new class of vulnerabilities, it's merely a new minor exploit technique of already-existing vulnerabilities. It doesn't decrease anybody's actual security.
You're confusing the AJAX protocol with a complete AJAX application. I'm talking about complete applications, involving both the client-side and the server-side. After all, a protocol is pretty useless unless there are applications involved making use of that protocol.
Very interesting, seeing has how AJAX has nothing to do with your server-side technology whatsoever.
Excuse me? AJAX is intimately involved with server-side technology. After all, there has to be some recipient on the server-side to respond to the AJAX requests sent by the client's Web browser. You can rarely build a useful AJAX application without involving a server of some sort. When designing an AJAX application, one must take into account server resource usage. Unfortunately, it often proves to be greater than when one is using a more traditional Web application development approach, including CGI scripts, PHP, JSP, etc.
Again very interesting, seeing as how AJAX itself has nothing to do with the way users interact with form elements.
Again, you're confusing protocol with applications. We're talking about AJAX applications here, many of which do end up using JavaScript to mess around with UI elements. This often leads to non-standard behavior which confuses users to no end.
your and your team have no idea how to actually code Javascript/AJAX/whatever, and you picked crappy packages off the internet and expected them to Just Work out of the box the same as your custom built solution.
Between the 9 of us, we have around 95 years of Web development experience. We know what we're doing. And we can also identify poor technology, AJAX being the latest example. Had you read my post, you would have read that we even worked with the vendor of one of these commercial products to improve its performance with our installation (to no avail, I may add). I'd like to name names, but I don't think I'm in the position to do so right now.
Nobody is explaining this right.
JavaScript has a security policy. The security model is that 1) scripts can only talk to the site from which the script came, and 2) scripts can only alter documents from the site from which the script came. The security model is enforced only at a few points, notably the XMLHttpRequest object and at points where Javascript stores into the document object tree.
Other than those few enforcement points, JavaScript objects in the same browser instance can communicate freely. This offers a number of potential exploits, some of which are listed in the paper.
If the security model is tightened up, prohibiting all intercommunication between Javascript objects from different sites, "mashups" no longer work, so it's too late to tighten this up without breaking some popular sites.
This is going to be hard to fix without breaking existing programs. Javascript has a very weak concept of what's immutable. It might work to mark functions as "dirty" if changed once loaded, then forbid "new" on "dirty" functions. That would prevent changing the base instance of a class without breaking too much else, and would fix this new vulnerability. But it wouldn't fix all potential vulnerabilities in that area. As long as multiple scripts share global variables, there's going to be potential for trouble.
Maybe "https" pages should be locked down more. "Secure" pages should be single source - everything has to come from one specific domain address. No frames, no cross-site anything - one secure site per window, and no shared data with other pages whatsoever. That's a start.
I'm going to call bullshit here. An ajax application is not significantly different on the server side than a regular web app. In fact, it is often easier on the server because the server only needs to render a small portion of the result for a given action rather than and entirely new page.
What does "perl based" have to do with it? You could very well have a Perl based (on the server side) AJAXy application.
Bullshit again. You are comparing AJAX with Perl/Java based systems as if there was any comparison to be made. Saying Perl based systems are better than AJAX systems is like saying roads are better than cars!
But thanks for you input anyway, Mr. Coward.
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
Have you missed the portion of my post where I explained exactly what Ajax was? It's just a JavaScript library that allows the page to communicate with the server without clicking a link and bringing up a new page. How does that encourage poor development?
And I have to dispute your claim that "virtually every Ajax application is problematic". I've seen plenty of places where Ajax is used effectively - Google Maps and GMail, to name two. Maybe in your experience, they are, but, as they say, the plural of "anecdote" is not "data".
Care to give examples of these "obvious and integral ways"? I have deployed real systems, and they have worked, and I haven't come across any of the problems you've mentioned.
Want a high quality FOSS RTS game? Try Warzone 2100!
Sure, tell me that Ajax is harmful, after I've just eaten a meal I made with it. Why don't they put this on the warning label??
Sure. And the very "design" of AJAX encourages such poor development to occur. The fact that virtually every AJAX application is problematic shows that the problem is not with the developers, but with the technologies those developers are trying to use.
Err... what? Are you saying that when I go to this-magical-php-script.com and download a bunch of PHP apps made by $0M3.Kr@zY.GuY and they don't work that PHP is a design flawed language?
What's your point? That's exactly how Java applications work: poorly. Java applications are often just as problematic as AJAX applications, in most cases.
Are you saying Java apps work poorly? I can understand you commenting on how AJAX apps are, on the whole, not working out very well as you have the initial "Holy crap new hype" bloom if junky software developers trying to make a few bucks while people don't understand the language. What I can't understand is how you can say the Java apps work poorly. Have you run any Java apps on your systems - from real vendors? I'm not talking about "Pizza Joes Amazing Taxes Pro Java Edition" but something more... interesting: http://www.sun.com/software/index.jsp
I just got to the part of your post where you say that you're 16
Just because someone's young doesn't mean that they're stupid. When I was 19, coming out of College, I did placement where I had to roll out a Windows 2000 upgrade in an existing RedHat + Windows NT + Solaris setup. Was I young and I did the job - reading does wonders to expand on what you don't know. Now they have a lot more resources online you can pick through for answers.
In the end, Mr. Anonymous, you should be giving helpful remarks to the rest of us as to where we shouldn't be going for our apps. Giving vague examples of this-and-that app didn't work, this-and-that old Perl app was amazing doesn't help anyone. Give us some meat to chew on, not empty angry remarks.
An ajax application is not significantly different on the server side than a regular web app. In fact, it is often easier on the server because the server only needs to render a small portion of the result for a given action rather than and entirely new page.
In theory it is "easier" on the server. But what we actually find is that the overhead of the requests can be greater. This happens when too many AJAX requests are made to generate a page. Soon the overhead of the request made by each individual AJAX request, plus the XML processing on the server-side, end up consuming more CPU and RAM than would be consumed had a typical CGI, PHP, JSP, etc., script been run.
What does "perl based" have to do with it? You could very well have a Perl based (on the server side) AJAXy application.
I could have been more clear here. The existing system is basically a number of CGI scripts written in Perl. A request is made, the script is executed, the full page is generated, the full page is sent to the client, the script is terminated.
You are comparing AJAX with Perl/Java based systems as if there was any comparison to be made. Saying Perl based systems are better than AJAX systems is like saying roads are better than cars!
What we're comparing is, in this instance, two Webmail applications. One is implemented as a number of Perl-based CGI scripts. The other is written using AJAX. The functionality being tested is equivalent in both, for the most part. The AJAX script does some work on the client-side which is just not necessary with the Perl CGI scripts, as would be expected.
And what we find is that the Perl-based system is far more efficient, even if it is generating an entire page for each request. We have been successfully running it on what is today considered rather ancient hardware: two 200 MHz Pentium systems, with 128 MB of RAM in each. Yet the AJAX implementation, running on an extremely powerful quad-core Opteron system with 8 GB of RAM, couldn't handle as many concurrent clients as our Perl-based CGI system could. Even with the AJAX application vendor's help we only managed to get the AJAX system to handle 90% of the load of the existing Perl-based system.
Really, I don't care if you think I'm full of shit. What I can tell you is that I have tried the technology you support, and I found it to be nonsense. It has numerous technological flaws, and it seems that developers, even highly talented ones, are unable to develop quality software using it. Blab about the "greatness" of AJAX all you want. Those of us who have actually tried it know how much of a failure it is. We'll continue to use techniques and technology that actually works, while talking heads like yourself advocate AJAX and other fecal technologies that just can't carry their weight. Have yourself a good day, sir.
Doesn't include javascript.
Err... what? Are you saying that when I go to this-magical-php-script.com and download a bunch of PHP apps made by $0M3.Kr@zY.GuY and they don't work that PHP is a design flawed language?
We actually stuck with only commercial vendors for the AJAX apps we tried. We even worked with one of them to try to improve the performance of their Webmail product, with no avail. Read my original post for more details.
Are you saying Java apps work poorly?
Performance-wise, yes. In terms of resource usage, yes. We have deployed a number of commercial groupware systems implemented in Java, as well as several implemented in Perl. We have found the Perl systems to perform far better. We'd take the time to try to figure out why the Java solutions perform so poorly, but it just wouldn't be feasible. The Perl solutions meet our needs more than adequately, so we use them.
Just because someone's young doesn't mean that they're stupid.
I didn't say he was stupid. I suggested he was inexperienced. And when it comes to deploying web applications to be used in a business environment by several thousand users at a time on a near-constant basis, experience is key.
Until one has actually had to deal with the performance issues of such environments, one cannot have a real appreciation of the difficulties that will be faced. And yes, that may mean finding that the technologies that make you feel all warm and fuzzy inside (AJAX, for instance) just don't cut it. When faced with empirical evidence that such technologies as AJAX just don't cut it, the best thing to do is to admit that they can't be used. Arguing against real-world experience and results does nothing to change the fact that the performance and development limitations of AJAX are problematic for many users.
In the end, Mr. Anonymous, you should be giving helpful remarks to the rest of us as to where we shouldn't be going for our apps.
I am. I'm telling you to avoid AJAX at all costs. My original post explained the problems we encountered with a number of commercial AJAX applications of various sorts. I even broke it up into four categories of problems for you. Go back and read it.
I may be missing something here, but this is nothing to do with AJAX in particular. What the article appears to demonstrate is that if you can do javascript code injection (the real vulnerability), then you can subvert the functionality of any javascript object by using the prototype system. But if you can inject code, then you can inject any code you like; you could create an AJAX reporting system even if one didn't exist already, or you could create invisible frames on the page which could submit regular forms to your server without using AJAX. Basically, if you can inject javascript code into a page, then you can make the page do anything javascript can do. How is this new, and how is it a particular flaw of AJAX? Isn't the flaw whatever problem (XSS or whatever) allows you to inject code in the first place?
You worked with one of them to improve the server-side performance of their Webmail product, which has absolutely nothing to do with Ajax, to no avail.
And, earlier, you said:
If said commercial vendor had problems with the server-side performance, a technology that has nothing to do with Ajax, I think the problem is with the developers.
And I replied that I am not.
You gave anecdotal evidence. I supplied plenty of counterexamples: GMail and Google Maps.
Want a high quality FOSS RTS game? Try Warzone 2100!
You are aware that AJAX is not a programming language, I take it?
Let's compare apples to apples. On the one hand you have a server side webmail system implemented using Perl, and I assume the tried and tested CPAN CGI modules. On the other hand you had an AJAX backend written in what language and implemented using what (if any) third party components?
If you want to be taken seriously, you need to provide this information. Otherwise a lot of people are going to conclude that you're just blowing FUD
Don't let THEM immanentize the Eschaton!
Name one technological flaw, then. And I doubt "highly talented developers" would design a system that uses multiple Ajax requests to generate a page and then blame the resultant server slowdown on Ajax.
Want a high quality FOSS RTS game? Try Warzone 2100!
You gave anecdotal evidence. I supplied plenty of counterexamples: GMail and Google Maps.
:)
You mean that fly by night organization, what is the name of that place.... err.... oh yeah, Google. I mean come on, they can't possibly know what they are doing, after all everything they write is in "Beta" for years.
But surely you can understand where all the confusion (and hostility) is coming from surrounding all your posts. You seem to be referring to AJAX as some sort of encompassing language and application framework on both client and server. An AJAX application could quite easily be Perl-based CGI scripts on the server side too.
I'm not saying you're wrong that thus far in practice AJAX applications require more server-side resources. For example perhaps what would conventionally be handled by a single request is handled by N XMLRPC calls, and so the overhead of a request (which includes gathering session data and authenticating) is done N times. But this isn't a fundamental property of AJAX.
Also, aside from the hidden iframe trick (which remains fringe), the whole asynchronous web app paradigm is still fairly young, and there is plenty to be learned. I'm happy to believe that AJAX amplifies bad programming and bad design, and since the overwhelming majority of programmers suck -- and sucky programmers tend to be the early adopters, while the experienced software engineers are far more skeptical and conservative -- we are inundated with garbage AJAX webapps, and therefore the (naive) conclusion to be drawn is that AJAX sucks. But I think that's premature.
By enabling development to occur at all. The program that is never written has zero bugs and is therefore the perfect program.
there is no need to sign your posts. this isn't usenet. your username is right there above your post. stop it.
for ajax to be harmful - what you are doing with ajax is delegating the running of some operations to the client side - you may not use it for harmful purposes maybe, but if ajax gets widespread use and acceptance, same people who used anything invented before to evil purposes will.
Read radical news here
They've known this since 1978 (see last paragraph) ;)
--- Commission free trading & free stock up to $500 - use http://share.robinhood.com/kelvinp6
Sounds like hype and sensationalism to me. But really, if true, would that be a bad thing?
I mean the we is a series of hacks. It was never designed to do the things it is being asked to do. Maybe a step back and rethinking of the technology is in order.
putting the 'B' in LGBTQ+
Now you're really showing your ignorance. A GET request is a GET request.
It depends on the framework, of course, but usually the initial page is generated through normal means. At least that is how AJAX works when using Ruby on Rails.
How is processing XML any more intensive than processing HTML? And why do you keep making some distinction between CGI and AJAX?
As opposed to an AJAX request being made, the script is executed, some XML is generated (less than the size of a full page), and the scrpt is terminated. Now what makes them so fundametally different?
There is no such thing as an "AJAX script." You're talking about AJAX as if it were a language. It is not. You're not making meaningful comparisons.
Why is it that you can't seem to be more specific about this "AJAX system?" Not once have you actualy described its real architecture. What was the backend written in? Why did you see fit to "upgrade" your apparently awesome perl based system in teh first place? Clearly something was lacking.
You have no idea what I "support," coward.
Like your posts.
I dunno. People seem to like Gmail a lot.
Talking head??? ROFL!
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
Here's a link to the PDF with the rest of the article.
h ments/1158-Subverting_Ajax.pdf#funny=javascript:al ert('Oh my god, they killed Kenny !');
http://events.ccc.de/congress/2006/Fahrplan/attac
Wanna fight ? Bend over, stick your head up your ass, and fight for air.
The best feature of Javascript is the ability to alter objects!
.style to MSIE which when used just forwards to MSIE's embedded style object! You could code to standard and just include a javascript "patch" which makes bad browsers work properly! We re-invent and re-use the same dom hacks when they should just be an include that fixes browser dom bugs.
Just like your DESKTOP, if you include libraries that are not safe, they have total control over your memory space...
Seriously, we need a REAL TWO WAY TCP protocol accessible to javascript which sends and receives TEXT with any other server. Then add a parse to xml feature to create an XML dom object. Its STUPID to always pass xml/soap all the time; furthermore, its STUPID to have a one-way street. It encourages polling which can generate massive server load.
We have been using this frame-hack method and further hacked into XMLHttpRequest for far too long! I prefer the old javascript hack with JSON.
We are still working from hacks when we should have a DESIGNED solution!
I think we NEED the ability to override the access/assign of properties with functions!
Imagine finally being able to add an object like
Mozilla already has features along this line already. (but Firefox works, so they are not needed much.)
Keep your eyes open for when domfu.org gets online. I hear their goal is javascript browser patches.
Democracy Now! - uncensored, anti-establishment news
It sounds like you have issues with these specific products; I don't see how you can apply this to all of AJAX.
From what I understand, AJAX would be a bitch to program right, and comes with a whole lot of issues that you describe for the programmer to sort out. But there are some clear success stories - gmail being the obvious one. Gmail started out with a couple of these issues, but google have been steadily fixing them and now it's slick and a great user experience.
And this is rather off-topic since it has nothing to do with the security vulnerabilities in TFA.
- nm -D
/some/binary
- Choose a dynamic loaded symbol
- Reimplement it in your evil library
- gcc -fPIC -shared -o evil.so evil.c
- LD_PRELOAD=./evil.so
/some/binary
- Sorry, this list doesn't end with "Profit!!"
Btw, this requires access to the binary and it can't be suid, BUT YOUR SUBVERTING IT!!!!!! And remember, kids: in Soviet Russia AJAX subverts you, Al Gore invented AJAX and Chuck Norris could subvert AJAX using a Beowulf cluster of... AJAX?!I'm sorry to say it, but AJAX might just be the worst technology I have ever had to deal with.
Parent post should go on AJAX's headstone.
rd
If it's no on fire, it's a hardware problem.
Now you're really showing your ignorance. A GET request is a GET request.
You're missing his point, I think. Yes, a request is a request, but where a conventional webapp makes a single request to load the page, some AJAX webapps will make several. It's a sign of badly written apps more than of weakness in the AJAX concept, but a quite a few of them end up replacing one large request-response with many smaller ones.
Plus, highly interactive pages may be making a *lot* of requests in response to user activity. That's partly avoidable, but also just a consequence of writing complex pages - it's not that they're worse than their non-AJAX equivalents, because equivalents don't (and cannot) exist. Again, that's just something that has to be considered in the design, balancing the cost of server-side calls versus the cost of greater client-side complexity.
AJAX is cool technology, but implementing it isn't a trivial matter. If you don't know what you're doing, you hit all the problems the original poster is complaining about.
I'm in the middle of writing a fairly complex application in which the UI is ajax based. The calls to the back end are all done via these ajax calls.
At the end of the day, I verify the data I accept from the application before storing it. I don't trust anything coming from the client side. Just because it's ajax and I "think" I'm in control of the application doesn't mean that I am.
Big deal.
You still can send me options as selected if the options aren't in the list I offered you -- because I check. You can't send me invalid data because I check it for validity. That's my responsibility.
You can get me to send you something you don't have access to, because the agents that retrieve the data are running under your authority -- not as a system admin. If you don't have access to them, the data won't exist for you.
Again -- security happens at the back end. The front end is always to be considered hostile.
The problem with quotes on the internet, is that nobody bothers to check their veracity. -- Abraham Lincoln
Some of us have been using this "prototype hijacking" technique with HTML filters for years to block and thwart CORPORATE and capitalist abuses of JavaScript. That, in my book, counts as a good use of this technique. Please don't take my Kodachrome away!
Don't dismiss this to soon.
This covers clever javascript methods of abusing the XMLHttpRequest function by effecitvely adding or overloading functions (yes, I know that's not REALLY what happens, but same result), however, it sounds like you still need to inject malicious code somehow in the first place, via XSS or stream injection or site hijacking to make this effective (and in any of those cases, you are already home free)
I don't fully understand the scope of the re-clonedreplacement XMLHttpRequest, if it is in scope for all subsequent calls to XMLHttpRequest even from parent windows or other non-child windows, then I can see this being very serious, but if not, it's just a clever way to take advantage of XSS.
I'll have to read this more when I'm awake tomorrow.
Yet the AJAX implementation, running on an extremely powerful quad-core Opteron system with 8 GB of RAM, couldn't handle as many concurrent clients as our Perl-based CGI system could.
Very informative posts. The only thing missing was what the various commercial server side products using AJAX were written in. Perhaps you have already added something on that in a later post, or being commercial products, you may not know, but AJAX versus non-AJAX is the point, which I understand.
rd
Why is it that you can't seem to be more specific about this "AJAX system?"
Actually, he referred to eight commercial packages using AJAX, all of which the users rejected.
That's real life.
rd
I think everything that I want to say has probably already been mentioned, but I really need to say this. Javascript is not a bad thing. Sure its design sucks, and the 20 different ways the same code can be interpreted is a real pain in the ass, but it has its uses. Developing interactivity is not a bad thing, and that is exactly what javascript is great at.
In order to make safe javascript, all you need to do is consider one thing - would my site send and recieve the same data if there was NO javascript? Consider google maps, and the old mapquest. When you drag around the map, the javascript is merely requesting images at a certain coordinate. Even if the user hacks up the javascript to do whatever, the only thing they'll be able request are images at a certain coordinate. Which is exactly what mapquest did when you clicked the edges. If you need to send text data and you use ajax, the javascript can send ANYTHING to ANYWHERE. But should you care? Not if your server actually only accepts proper data with full error checking. Same applied to standard form text boxes. ajax or not, if your server dumps all the data from a POST into a database, your server is good as hosed.
I play with ajax quite a bit. I love making things interactive. Yeah it's a pain in the ass to work with, especially if you're an ascetic like me, and refuse to use any libraries (I love making my own code, hehe). Locking down the javascript is not one of my concerns though. Sure you need to make good code, if only to make sure it makes sense to yourself. But all server-side handling should be done as if javascript did not exist at all. Server-side code should have only one failure mode - rejection. Client side code can, and WILL fail no matter what. Even slight interpretation issues between the various browsers will muck up the script. You just have to pretend that it doesn't make a difference, and allow the site to be operational still. Follow this, and I don't see how you can actually compromise a site.
I know from job experience what your talking about, I have found the same types of problems in working with what one could call the 'ajax paradigm.' It's unfortunate that your description of the subtleties of the problems with the ajax paradigm is getting lost in all these hop on the latest web 2.0 bandwagon replies. I think a big reason the ajax paradigm generates all these problems is because it puts too much system functionality in Javascript. Javascript is a very unstable and undeveloped application platform compared to Java, Perl, etc. And on top of that, it's even worse because the ajax paradigm expects Javascript to function as a component in a distributed system, a task that is challenging for even the most developed languages and platforms. The ajax paradigm is like going back to pre internet client-server, but with a much worse programming system. I think one additional reason why there were so many negative responses to your post, is that younger people don't know about all the challenges that client-server systems had to solve over time in the 80's and early 90's. So they know think a very underdeveloped scripting platform can waltz in and work without the years of development done with past client-server systems like foxpro, etc.
C++ applications just aren't solid or stable, for the most part. We tried to integrate a number of them into our network here, and frankly each attempt went terribly.
Java applications just aren't solid or stable, for the most part. We tried to integrate a number of them into our network here, and frankly each attempt went terribly.
In all cases, I'd kindly suggest the problem is not with the technology, but with the person doing the work.
blah blah blah
There's a reason Java applications seem to be, on average, slower and more heavyweight than their equivalents in Perl: it seems to encourage complexity.
The typical Java stacktrace you get when something goes wrong is, in my experience, some 30+ levels deep. That's ridiculously high.
That means that Java applications are built with class upon class upon class upon class, to a ridiculous degree. The amount of subclassing that happens in a typical Java program is much worse than any other language I've seen, by a factor of 4 or more.
It's so bad that you have to use a language-aware tool like Eclipse to keep track of it all. Without the ability of such tools to track the class relationships, such programs would literally be impossible to maintain.
And what does all that extra complexity buy you? Why, nothing at all, actually. The software isn't any easier to develop, debug, or maintain than it would be in any other reasonable language. In fact, I would argue that it's harder to maintain because of the additional complexity.
The choice to make a program more complex is one that must be made very carefully. Java somehow seems to encourage developers to increase the complexity of their programs. Whether it's because of the language (which includes the class libraries in this case) or the development tools I cannot really say. I suspect it's a combination of both.
Because of these issues, I've been completely underwhelmed with Java as a development and execution platform. As a language it has some strengths, as all languages do, but I don't find any of those strengths particularly compelling, and find the weaknesses to be very significant.
Java actually turns out to be a reasonable language to write programs in, but it requires an extreme amount of discipline and you don't get a whole lot in exchange. If I want my programs to be maintainable, I'll write them in Ada or something.
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
Man, am I glad I am not the only one who feels like the whole "use OOP (java) everywhere for everything!" mantra is a bit cargo-cultish. Thank you. I thought there was something wrong with me for a minute.
blah blah blah
In all cases, I'd kindly suggest the problem is not with the technology, but with the person doing the work.
It wasn't *a* person, but rather eight commercial apps using AJAX that didn't work, because users said so, compared to existing non-AJAX web apps that do work.
Other than that, your earlier examples of use of AJAX were good.
rd
Your clients who use mobile phones aren't going to appreciate your shifting the burden to them.
I use Firebug (Firefox extension, google it) all the time to debug my own JavaScript.
It lets you review the source, traverse the DOM, etc. and make live changes to the JavaScript/DOM/HTML on the fly.
You can add code, redefine functions, change variables, etc.
I hate to encourage this sort of thing, but you'd be surprised at the number of shopping carts and other systems online that rely on the JavaScript code to be "trustable". This, of course, is a horrible methodology. Sadly, it's widespread.
For example, say someone uses AJAX to call a serverside PHP script that returns the price for a given SKU and stores it in a variable 'p'.
You skip past all this code and just set p = 0.01 in Firebug. Refresh the page and now your item's price is $0.01. This works in at least 20-30% of all the small-to-medium enterprise AJAX carts I've informally tested it on.
Having never checked out (that would be theft) with this modified value, it's impossible to say if those same retailers were using proper serverside validation in the checkout process. I'd guess not, given their lackluster approach to AJAX security.
-mh
Well, there is absolutely, positively nothing AJAX-specific about what this paper describes. Despite it's ignorance about AJAX being a framework, the paper does point out some realistic concerns about XSS. Unfortunately, those same techniques could be used to subvert regular HTTP GET/POST as well as fancy-pants XHRs. There is nothing uniquely AJAX about this save the authors' attempt to capitalize on trendy terms vis-a-vi their consulting firm. BTW, fantastic job description, mind if I use this for my own postings? "Senior Security Engineer of proved experience, works since many years as an IT consultant for private and public companies."
... only if swallowed.
Not one by name. Sorry, I but I detect a troll.
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
Sorry, but there isn't going to be any meaningful discussion here until you decide to be more specific about what "some AJAX webapps" are. I'll admit that I rejected Yahoo's new beta email client because it is slow and cumbersome. In general I am against webapps that try to mimic the desktop experience with massive amounts of javascript running the the browser. But I've also seen AJAX implemented quite well. I've even implemented it myself. There are some really cool things you can do with AJAX that are totally worth it such as auto_complete fields and drag/drop and sorting lists.
The real problem is that HTML royally blows when it come to building rich UIs. It isn't necessarily AJAX that is the problem, it is all the hacks required to make rich GUIs out of HTML/CSS.
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
All the details were right on, but to be honest with you, they could beta eight web apps without AJAX and find them lacking. If he didn't know what the server sides were written in some of them may just be hyping him about AJAX. And it may not even be the cause of less performance, for example a Java app server could be slower than Perl CGI's as well.
So yes, he definitely should have provided more server side details.
rd
I thought that the problem with AJAX was that it consists of readable code on the client side, period.
AJAX is a bit slower, per K of HTML, than straight HTML from the server because it receives XML and parses it into changes it makes to the DOM. That's the only technical limitation of AJAX, really.
If you try to receive 60K of XML and do complicated parsing in the browser, UGH. If instead you receive back 10-50 bytes and render this into important status updates, you save a 50k load and a corresponding wait, with the convenience of having a single action on a single page, so that going back doesn't appear to undo your event.
If you change *any* UI element, you're probably doing something wrong, standards are good. Your AJAX app shouldn't change how clicking in textboxes works, I agree, but neither should all the local Windows apps that do this. An old company I worked for deployed a phone-status package that exactly fit a 1024x768 page with standard-size windows bar. Any changes in this and it started to look horrible. If we changed the system font size it was almost unreadable. Needless to say, this is just before the otherwise successful company tanked. This was all done windows native, with MFC code. Had my testing team gotten our way the status page would have been HTML and worked static, having AJAX only to provide a live view. The web interface would have been faster and better, even with AJAX.
It's not the tech, it's how you. If you think not, that proves it's you... Real experts can use dangerous tools sparingly and safely.
Write in whatever style results in the easiest to understand code that works. If you're modeling physical things, OOP is often that paradigm, but you can do OOP in C - it's a philosophy as well, not just a technology. If you find it's a pain to make something fit OOP, maybe you examine it and it's not an analog of a thing but a non-concrete idea like security, perhaps it just isn't amenable to this abstraction.
Similarly, your object model should represent your data, not your programming hurdles. If you have five levels of class hierarchy for a Table, you're probably over-using inheritance.
Short understandable code - the "right way" is whatever the fastest way to achieve this is.
I wouldn't say that AJAX encourages poor development.
... hack.
However, AJAX itself is abysmal. It's "graunching" a web browser and server to do something it fundamentally wasn't designed to do. Drawing a GUI by writing HTML fragments on a browser window? With a protocol which is stateless, designed for serving documents? Ye gods! Java applets are a MUCH better way to get AJAX-like things done, yet we've abandoned that and decided to go with this
Oolite: Elite-like game. For Mac, Linux and Windows
About gmail and google maps...
;) ) developed and sells to them with a per-use license that I'm not free to name the terms of.
Mutt beats gmail hands down. the l button and the regular expression support in mutt rules anything google has.
Google maps is the only AJAX app that's worth anything, and it wasn't written by google, it was written by some freelancers who sold the concept to google based off of a mapping drill down server somebody else wrote.
And every other map vendor now has "draggable" maps anyways, so it's not that big of a deal. It's not even that important, either. The routing and geocoding library aren't even written by google --- its speed is almost wholly a function of the algorithms that that another company (
AJAX can be ok, but it's not fast, and it's not easy on servers. Google had to put up massive hardware to make it scalable.
> Anyone know where I can find a non-PDF version of this paper?
Yes, but you'll need AJAX to read it.
Bugs longa, ars brevis
I've known that Ajax was harmful since I was 1. Ever since then, I stopped eating things that I found under the sink.....
( bad pun )
Knowing Google's lust for data collection, the Soviet Union is still alive and well inside the psyche of Sergey Brin....
You are missing the biggest part. As with every other application or framework, the AJAX ones are released when barely mature. With any other application it 'kinda works' because they rely on a stable base (a JVM, an OS, W3C standards, etc...)
AJAX applications rely on a fragmented unstable and constantly moving base. And no, it is not JavaScript, it is the various DOM implementations and javascript limitations inherent to every different browser. I have written an AJAX framework, and know the pain and the hacks needed to make such a framework usable. The problem is that any browser vendor may chose to disable this CSS feature or this javascript one, or this DOM hack because all of a sudden a whacko has found a way to make it a security vulnerability.
Again, the problem is not with JavaScript or with AJAX, it's with the fragmented unstable base of JavaScript's implementations in web browsers and the 'extra features' the AJAX vendors think they need to make their product competitive (when listing features against a competitor).
Write boring code, not shiny code!
Eye irritant. In case of eye contact, flush with water. To avoid harmful fumes, do not mix with ammonia or other cleaning products. Keep out of reach of children.
2. The Back button goes to the last page, as opposed to the last action, which is a good thing for true Web applications, since the Back button usually causes tons of problems (Ever seen "DON'T PRESS THE BACK BUTTON OR YOU COULD ACCIDENTALLY PAY FOR THIS PRODUCT TWICE"?).
The Post-and-Redirect design pattern (or the use of unique once-only form ids) solves this problem in almost all cases. Only badly written web apps still suffer from it.
The rest of your points are good, though.
It's just a JavaScript library that allows the page to communicate with the server without clicking a link and bringing up a new page. How does that encourage poor development?
I'll take a stab at this. The problem is that it encourages people to write substantially more complex front-end code in javascript than was ever attempted prior to the development of AJAX. And front-end javascript is notoriously difficult to do right: there are a lot of browser incompatibilities that need workarounds, and many things that should be common in an application are actually very difficult to achieve, primarily because Javascript wasn't designed for this purpose -- its design goal was to allow small page modifications to be performed at the client, not to allow people to produce complete user interfaces. The fact that it is restricted to a single thread of execution and doesn't have a wait-for-event primitive makes some complex designs very hard to implement. Its handling of common user interface elements is basic and often difficult to work with.
All of these factors combine to make AJAX development substantially harder than equivalent development in more friendly environments (e.g. Java app development, native Windows, Linux or MacOS app development, etc.).
..fix the hole in that. Meantime, I'll need to avoid putting state secrets or credit card information on ajax based forms.
The problem with quotes on the internet, is that nobody bothers to check their veracity. -- Abraham Lincoln
He can't be more specific. The fact of the matter is that virtually every AJAX app is poorly written. The most specific you can get is every AJAX application you can think of: GMail, Yahoo! Mail, Hotmail, any of the AJAX-based CMS systems, Digg, any of the AJAX-based groupware systems, any other AJAX-based Webmail system, any AJAX-based forum systems, etc. They all exhibit numerous problems due to their use of AJAX.
Off-hand, I recall one of the CMS systems using Ruby on the server-side, and the other two used Python.
The webmail system used some server software provided to us as a native binary, running as its own HTTP server. I presume it was written in C, C++ or some other language that is compiled natively. We didn't have access to the source code.
One of the groupware systems used PHP, and the other used Java.
For the forum software, one used Ruby, one used Java, and one used PHP.
Fag.
That seems more an argument in favour of fixing the incompatibilities between browsers, rather than against the use of more complex Javascript.
and many things that should be common in an application are actually very difficult to achieve, primarily because Javascript wasn't designed for this purpose -- its design goal was to allow small page modifications to be performed at the client, not to allow people to produce complete user interfaces.Javascript is a fairly generic Turing-complete language, and I can't see feature of the language itself that would make creating a user interface particularly difficult. Indeed, the entire Firefox UI is essentially XUL and Javascript. It seems to me that the source of any problems with Javascript would be inadequate (and incompatible) libraries, rather than the language itself.
The fact that it is restricted to a single thread of execution and doesn't have a wait-for-event primitive makes some complex designs very hard to implement.A wait-for-event primitive? What do you mean? Javascript allows one to create callback functions to a number of user-triggered events, and one can also easily trigger functions on custom events. Though the single threading is an issue, I'll grant.
Its handling of common user interface elements is basic and often difficult to work with.Again, it would appear you're more criticising the libraries, rather than the language.
Although you're posting as AC, I think this is worth saying, as your post was useful:
This is Slashdot, which nowadays is inhabited 99.9% by inept, illiterate, inarticulate, illogical and incompetent morons with an attention span exceeded by that of gnats. Their reading ability terminates immediately on encountering any sentence longer than 7 words, any phrase containing more than one adjective, and any word with more than two syllables. And the concept of statement attribution in composite articles is of course utterly meaningless to them.
There's no point getting annoyed at all this, just ignore them like you ignore the slime molds covering the ground outside.
Those of us not afflicted by the above are still here mainly for amusement value.
PS. In case you're new, it wasn't always like this. In the early days, most people here were very logical techs.
The main benefit that is often claimed of AJAX is that you don't have to generate entire pages over and over again. You just modify a portion of the current page. Unfortunately, that prevents bookmarking of pages.
So we point out that pretty major flaw that is inherent with the AJAX way of doing things. And here you come, telling us to cut down on the number of AJAX requests, basically to the point of sending an entire page for each action.
This is why many of us think that AJAX is nonsense. When it is used as intended, it suffers from serious performance problems. And then the solution AJAX advocates give is to revert to what we were doing before!
Don't waste our time by telling us you have some fantastic technique that offers numerous benefits over what we're currently doing, only to find that your technique fails to perform adequately, and then you suggest that we just revert to what we have been doing for a decade.
And I doubt "highly talented developers" would design a system that uses multiple Ajax requests to generate a page and then blame the resultant server slowdown on Ajax.
AJAX advocates tell us that the main benefit of AJAX is that we don't have to generate a complete page for every request from a user. We are encouraged to generate the page dynamically on the client-side in small chunks, via AJAX requests. And when we do so, we run into severe performance problems.
So then you AJAX advocates turn around and tell us to reduce the number of AJAX requests we perform. To get decent performance, we end up having to generate a complete page for each client request. Thus we end up with a situation where we don't get any of the benefits of AJAX, as we're still generating complete pages for each client request, but we have to deal with its added complexity.
That doesn't fly in the real world, bub. We don't have the time, money and resources to waste on your pathetic claims.
Want a high quality FOSS RTS game? Try Warzone 2100!
Ajax, by itself, can't possibly cause any of the problems you describe.
The point is that AJAX makes it easy to do things badly, in the same way that Java makes it easy to do things slowly and Perl makes it easy to do things incomprehensibly.
As with any new language, it takes time to develop and institutionalize the idioms that work around the inherent problems, and because AJAX is flavour-of-the-month that hasn't happened yet. Thus, the OP's experience with badly written AJAX apps. They are the result of some marketing droid saying, "Hey, code me up some AJAX--it's what customers are beggging for!" and ever-optimistic technologists saying, "This stuff is bleeding-edge kewel, we'd love to!" and then doing a crappy job of it because the idioms for doing it well aren't yet well known and the gotchas are still being discovered.
So you're right that there is nothing "inherent" about AJAX that makes it necessary that AJAX apps will be crap, but there is something inherent about where we are on the AJAX learning curve and adoption cycle that makes it an absolute certainty that most AJAX apps will be badly-written unscalable pieces of garbage. And AJAX apps from large third-party vendors with big marketing budgets that are purchased by PHBs with an eye to nothing more than buzzword compliance will the worst hit. In-house service apps like Google's offerings will in general be much better because the people who write them also have to live with them.
The unfortuante side effect of this is that the technology itself will get a bad rep, and people will avoid it until it is revivified under a new name.
Blasphemy is a human right. Blasphemophobia kills.
If you have XSS vulnerabilities, you're screwed. That's just a fact, and it's unrelated to prototypes or AJAX. And XSS won't get fixed by changing prototypes or by not using AJAX.
In different words, the paper is irrelevant and stupid.
"I haven't come across any of the problems you've mentioned."
How would you know, whether or not you (actually your client) have "had problems", if the purpose of an "evil attack" using the XSS attack were merely to document your browser's behavior so that its behavior could be "registered/monitored" and then used as input for another Type 2 XSS attack on another of perhaps "problematically coded" one among many "non-problematically coded" AJAK applications running on a specific client's browser? If I read the article correctly, the implication is that a malicious attack could use the potential of a XSS Type1-Type 2 attack on one AJAK application to eventually, if intelligently done (ie in the correct and sufficiently stealthy order), comprise any or all other AJAK applications given sufficient time without the user's or the AJAK application's knowledge or intention.
From my reading of the article, it seems to me that it is precisely these kinds of "deep threats" that the article draws attention to in dicussing the underlying the vulnerabilities of all AJAX methods. Ultimately don't AJAX approaches rely on assuming that all other AJAX apps are well-behaved so that the scripting behavior of a particular client browser machinery has not already been penetrated/compromised and is behaving "honestly"?
I ask this as a java-developer interested in incorporating AJAX methods so that the well-known "time penalties" of many Java web apps can be avoided. While I want to use Java to control application logic I thought I might be able to use AJAK to avoid the time penalties. However, if I must reduce security to gain speed am I not better served by going to the Sun Webstart approach for my apps and not to AJAK? I am in particular interested in incorporating Google Maps AJAK scripts into my apps so that I don't have to reinvent the wheel (especially since my version would almost certainly be a poor man's version of the Cadilac that Goggle has already created). Yet know I wonder if the maps Google is sending me can not be used to encrypt malicious data because my client's (both senses) browsers have been compromised by other AJAK apps.
I don't see from your post that you have addressed the central concern raised in the article that even "well written/well behaved" AJAK apps are not at risk here? What is it about Javascript Libraries that would lead you to believe that this is a non problem? As noted by Wikipedia Google itself has been vulnerable to such attacks (see XSS). If my reading of the article is correct, it is that "Effective" and "well-behaved" are not always synonymous. While I would like to agree with you, my reading of the article suggests that there is good reason to doubt your confidence in Javascript Libraries
It's not an ad hominem attack to point out that a particular individual does not have the background and experience to be discussing a particular topic.
The grandfather poster is right: a 16-year-old kid probably does not have the experience necessary to make decisions about deploying a large application into a corporate environment. That's not to say the kid is stupid, or will never obtain such experience.
I wouldn't take legal advice from a 16-year-old. I wouldn't take medical advice from a 16-year-old. Maybe I would accept such advice when those 16-year-olds grew up, graduated from university, graduated from medical or law school, and then practiced in their chosen fields for several years.
Likewise, I wouldn't take advice on how to run my corporate network from some random 16-year-old kid on the Internet, of all places. I especially wouldn't take his advice when I know from actual experience that what he is saying is incorrect. The technologies he advocates do not work as he says they do, even if he believes with all his might that they do.
The fact is that the kid is inexperienced in this area, and the technology he advocates does not perform as he thinks it does. It's not an ad hominem attack to point out his inexperience and incorrectness, as they are both 100% factual and correct.
You're missing the point. You generate a complete page, minus the part that doesn't change between pages. (Which, for most actions, is the majority of the page).
No, you're missing the point. For many applications, the overhead associated with generating and executing the JavaScript to perform the requests to fill in the missing parts of the page can often exceed that of just sending the complete page in the first place.
Not only that, but the use of AJAX adds additional complexity which must be tested. I know you've never worked on any large-scale corporate intranet project before, so I understand that you're not aware of how costly such testing can be, especially when there are so few benefits from using the technology.
When we sit down and run the numbers, AJAX just isn't feasible. The savings you claim either do not exist, or are actually negative (ie. the AJAX solution uses more bandwidth, client and server CPU time, etc.)! And that's ignoring all of the other problems, such as the inability to bookmark pages, non-standard textfield behavior, an inability to use multiple browser tabs, and so forth.
Sorry, AJAX just doesn't cut it for real-world development.
I hope it's true. I am so tired of client side. Lamers.
The rest of your points are good, though. I was giving an example. The "form id" solution still gives the annoying "Content has Expired" message in IE and the "Are you sure you want to resend form information" dialog in Firefox. The "Post-and-Redirect" method breaks the back button even worse, unless you try to press Back several times really quickly or use the Back menu, in which case it suffers from the same problem as I mentioned earlier. Although both solve the problem I mentioned, Ajax is still better for it (as long as you have a fallback for public sites).
Want a high quality FOSS RTS game? Try Warzone 2100!
All of these complaints could easily be applied to Windows 3.0, as well. It's not the type of technology that's bad (Ajax isn't a specific technology, but rather a class of technology, like "windowed system"), but simply the implementation of it. If 5 of 5 Ajax apps you tried are bad, well, that's not surprising since it's a relatively new field with a really low barrier to entry and lots of money. Why would one expect anything else from the first round?
It is possible to do Ajax right. Compare Google Maps to any non-Ajax map site, for example. There probably isn't a good Ajax CMS yet, but that's because all the Ajax CMS vendors suck, or all the good Ajax programmers haven't done CMS yet, not because it's fundamentally impossible.
Factors like usability, performance, and quality can be designed for. People have gradually figured out how to engineer desktop apps for these attributes in the past 20 years. They just haven't figured out (most of them) how to do this for Ajax apps yet.
I've recently starting writing Ajax apps (after doing desktop apps for many years). Yes, the tools aren't what you'd call "good", but they're far better than some tools I've had to use over the years. If you can't figure out how to "structure" a client-server app, I do not consider you a "competent software developer", and I look forward to eating your market share for lunch.
Cheers!
But surely you can understand where all the confusion (and hostility) is coming from surrounding all your posts.
I don't see hostility. I do see some stupidity and ignorance, namely from that tyke who insists that AJAX is so great, even after it has been shown empirically (eight times over!) that even commercial applications are not suitable. Then again, I don't care, because I have such strong evidence and experience to show they are wrong. Unlike them, we have tried to deploy these AJAX applications, and they failed horribly in so many respects.
You seem to be referring to AJAX as some sort of encompassing language and application framework on both client and server.
I've clearly been talking about AJAX web applications. This involves both the code that is employed on the server-side and the client-side. But the problems we were running into were all over the place. Again, it didn't matter which language or platform the server-side portion of the applications we tried was written in. The products we tried included native binaries, PHP scripts, Ruby scripts and Python scripts. The end result was that the performance was unacceptable. Our Perl-based system ran better on PC hardware a decade old, when compared to the new AJAX-based systems running on a goddamn quad-core Opteron with 8 GB of RAM!
Of course, the client-side problems were numerous, as well. See my original post for more details.
It's useless to talk of AJAX without considering its applications. How AJAX should theoretically work is fucking useless. When it comes to real-world usage, it fails to provide a usable system.
Luckily for me, I am still on Web 1.0...
Want a high quality FOSS RTS game? Try Warzone 2100!
The Javascript engines in Mozilla and IE are not that bad speed-wise. The killer slowdown is the poorly implemented DOM bindings in these browsers. God help you if you have to create or manipulate thousands of DOM elements in AJAX - it can take a minute of client CPU time.
Brendan Eich's roadmap talks about this topic in his blog:
So the goals for Mozilla 2 are:
* Clean up our APIs to be fewer, better, and "on the outside."
* Simplify the Mozilla codebase to make it smaller, faster, and easier to approach and maintain.
* Take advantage of standard language features and fast paths instead of XPCOM and ad hoc code.
* Optimization including JIT compilation for JS2 with very fast DOM access and low memory costs.
* Tool-time and runtime enforcement of important safety properties.
Cruft? An injection mechanism being available is an "unpleasant substance"? Perhaps you mean "crux"? This is Slashdot, so I suppose it's anyone's guess.
Web applications are "always on" applications.. Something you can not do with even a laptop. With the knowledge of a URL, a username and password, you can access a service from anywhere on the planet, with as little as a cell phone.
Wrong. You need Internet access, which is not available everywhere, even with a cell phone. Many cell phones have sub-bar browsers that do not work well with many sites, even those offering some degree of support for such phones.
You don't have versioning nightmares.
Wrong. Many web applications depend on a certain version of a browser being present. Many will bail if a non-standard browser, even one as popular as Firefox, is used.
You don't have installation headaches.
Wrong. You still need to install a Web browser. Many web applications require plugins like Flash or a Java plugin to be installed. These are often not supported on some platforms (PPC Linux, for instance). Even on i386 Linux, it can be a major hassle to get those plugins working.
You don't have platform lock-in.
Wrong. Many AJAX web apps will only work with a small subset of the browsers out there, which in some cases means only IE 6 and IE 7. Many non-AJAX apps still use JavaScript code that uses proprietary extensions, thus only running on certain browsers.
You don't have OS restrictions.
Wrong. Web apps that involve Java applets or Flash will often not work on non-Windows platforms. See the points above.
You don't have performance / hardware requirements.
Wrong. Try running Firefox on even a 300 MHz system with 512 MB of RAM. It's not pretty. It's fucking awful, to be honest. Opera is somewhat better. AJAX on a cell phone is just terrible. It's far too much processing to do on the client side, especially when the client side is short on resources.
You don't have EULA's because..
You don't have copyright infringement
You don't have software co-mingling concerns
Wrong. Wrong. Wrong. You agreed to an agreement with Google when you signed up for GMail. The same for Hotmail, Yahoo! Mail, Digg, Slashdot, YouTube, and virtually every other site out there.
You don't have tons of test platforms during development time.
Wrong. You have to test a wide array of web browsers, and different version of those browsers. Netscape Navigator 4.x, Netscape Navigator 6.x, Netscape Navigator 7.x, Netscape Navigator 8.x, IE 5, IE 6, IE 7, Opera 6.x, Opera 7.x, Opera 8.x, Opera 9.x, Mozilla Firefox 0.9x, Mozilla Firefox 1.0.x, Mozilla Firefox 1.1.x, Mozilla Firefox 2.x, Mozilla Seamonkey 1.0.x, Mozilla Seamonkey 1.1.x, Safari 0.x, Safari 1.x, Safari 2.x, etc., etc.
You don't have technical support calls out the ass (assuming your site has a standard user interface).
Right. But that's only because your service is so poor that anyone who would actually go to the trouble of making a tech support call isn't using your service.
You have intrinsically collaborative software.
Wrong. Special care must be taken to make sure that web software is not abused. It actually takes more care and concern to make sure an application is collaborative only to the extent that is wanted, so that it isn't easily exploited (eg. for sending spam).
You don't have hard-drive crashing concerns / backup concerns.
Wrong. It's always important to back up critical data, even when a company like Google, Yahoo! or Microsoft is hosting your data. It doesn't matter if it's their hard drive dying or yours. The end result is that your data can easily become lost.
If you're willing to stand behind that assessment with an actual login, I wouldn't be calling you out as an AC troll.
This has all the hallmarks of either a troll post (not a single actual product mentioned that can be critiqued), or a poor technology implementation (I'm sorry but CMS and mail systems are not exactly where the sharpest programmers tend to live).
All the problems you cite sound like poor programming. You want to see a good web app that uses AJAX? Try Gmail or Google Maps, you may have heard of them. I don't see anyone complaining about those apps screwing with text fields or the back button!!
FUD!
By Post-and-Redirect, GP meant at an HTTP level, rather than a Javascript/"HTML META" level. Using the correct standard and doing it with HTTP does NOT break the back button. And I think, although I'm not sure, that the unique ID was supposed to suggest something within the application, in which case displaying "You have already submitted this payment" is trivial.
That seems more an argument in favour of fixing the incompatibilities between browsers, rather than against the use of more complex Javascript.
//Standard JS //do stuff //clean up without doing stuff
//Some environment that does what I was talking about // do stuff // clean up without doing stuff
In an ideal world, sure. Realistically, this isn't something I'm holding my breath for. MS have practically zero interest in interoperability with other browsers. Mozilla devs are only interested as far as it improves conformance to W3C recomendations (which MS routinely ignore). For stuff outside of standards, Mozilla has virtually no interest. Sticking to standards isn't viable when MS browsers don't work when you follow them.
Javascript is a fairly generic Turing-complete language, and I can't see feature of the language itself that would make creating a user interface particularly difficult. Indeed, the entire Firefox UI is essentially XUL and Javascript.
Yes, but XUL isn't available in a web context, where one must generally support a wider variety of browsers than just mozilla, with your own XUL packages installed locally. We're talking about AJAX apps here, not XUL development which is a completely different game with different rules.
The problem is in developing UIs that operating through the HTML DOM, not anything intrinsic to Javascript as a language. It's a library issue, not a compiler one, to compare it using the terms of desktop programming.
A wait-for-event primitive? What do you mean? Javascript allows one to create callback functions to a number of user-triggered events, and one can also easily trigger functions on custom events. Though the single threading is an issue, I'll grant.
When programming UIs in other environments, it is generally possible to call a function of some kind that displays a UI and waits for user response. JS has a limited version of this in the window.alert(), window.prompt() and window.confirm() methods. Other environments tend to allow the programmer rather more control over the format and behaviour of the dialog box that is shown (e.g. using the Win32 ExecuteDialog() API, or some object-oriented equivalent). Compare the following snippets:
function button1_onclick() {
dlg=new mydialogbox();
dlg.okhandler=button1_onclick_dlgok;
dlg.cancelhandler=button1_onclick_dlgcancel;
dlg.show();
}
function button1_onclick_dlgok() {
}
function button1_onclick_dlgcancel() {
}
or
function button1_onclick() {
if (new mydialogbox().execute() == 1) {
}
else
{
}
}
The flow of control in the latter example is substantially easier to understand, but it is impossible to structure your code like this in the javascript environment, because there's no "wait for event/dispatch event" API available (which is how the 'execute' method in the latter example would work).
Again, it would appear you're more criticising the libraries, rather than the language.
Yes, I am. However in the context we're talking about (AJAX programming) you're stuck with the libraries you're given, so they become (at some level) one and the same thing. Yes, I'm aware of what javascript can do in different environments; I'm even considering using it as an extension language in my own apps. But that doesn't change the fact that writing advanced user interfaces using javascript in web browsers is more difficult than it should be.
Damn right. AJAX = protocol to communicate with the server.
The client-side complaining is hardly a problem with AJAX. Calling and getting information from the server is easy and quick. It's the DOM scripting that is then used to display the information that comes back from the server that causes CPU spikes and client-experience breakdowns.
Further, a block of text fading in and out on a page is not AJAX. For the love of God, it's DOM scripting via Javascript, and in no way AJAX at all. Perhaps AJAX was used to get the text to display, but putting said text in a div or whatever and then FADING it in to be cool is not AJAX at all.
Excuse my speling.
Making The Bar Project
It's Wednesday. The link to the PDF is still dead (connection refused). Maybe this article should be titled "Slashdot may be considered harmful (to weak web servers)".
now we need to go OSS in diesel cars