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.
"...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
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
>(or was it written in FUD?)
Ok, I propose we create a new programming language called FUD. Variables will be assumed to have their most sinister values and be impossible to verify.
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.
. (or was it written in FUD?)
Sadly, no. The FUD compiler was written in Javascript, and was hijacked.
No, Greasemonkey exposed security sensitive functions to websites. They were meant to be used by Greasemonkey scripts but websites had access too.
This is about the way Javascript implements object oriented programming: In Javascript you don't define classes from which objects are instantiated. In a nutshell, you create prototype objects and new objects are copies of the prototypes. The "attack" is to change existing prototypes. For example, you can add a new function to the String prototype or replace an existing function with your own implementation. Every String object then gets the new function. There is one problem with this: Cross site checks don't apply. A script from one site can't simply communicate with another site, but it can modify the prototypes that the scripts from the other site use and subvert the communication of the other script with its host.
Ok, I propose we create a new programming language called FUD. Variables will be assumed to have their most sinister values and be impossible to verify.
Is that language derived from brainfuck?
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
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"
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.
http://www.adobe.com/products/acrobat/access_onlin etools.html
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).
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!
For your information, just skip to the last page of the paper. It describes both of the paper's authors. Probably the main author of the paper is Stefano Di Paola and his brief biography is given in the paper, you don't even need to look it up. He's a professor at the University of Florence and has found many dangerous vulnerabilities in MySQL and PHP. It also looks like a fairly well researched paper (didn't read all of it though). Obviously, you'd have to verify his bio to be 100% certain that it is true, but I have a feeling it is if he's a respected security expert (which would explain him presenting at 23C3).
You may also find this nice little gem as the last paragraph: Certainly, non of the end of the world scaremongering you attributed to himself. Somehow, I have a feeling that this guy knows more about this stuff than you.
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.
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.
There is one problem with this: Cross site checks don't apply.
You didn't test that and just assumed it's true I guess. But if they applied, and each page context runs in its own sandbox with its own version of String, Number, and so on, you'd sound pretty stupid right?
Try it yourself, the prototypes are NOT shared. They are not shared even among two page tabs on the same domain.
In fact not shared even among two instances of the SAME PAGE.
Embarassing, I guess, for all modded 5+ claiming this on this article.
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.
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!
I'm sorry, but I have to disagree. AJAX is NOT a great technology. It's a perversion. It bends HTTP and HTML to do things they were never meant to do. And because of that, it's not really surprising that it has so many huge problems. Not being able to bookmark or use the back button? Those are gigantic problems.
If anything good can be said about AJAX, it's a curiosity. It's certainly amusing that it can be done, but "great technology" it is not.
Maybe not
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.
those 'gigantic problems' aren't problems with Ajax. There exist good solutions for both. The solutions, however, are nontrivial and are typically ignored by developers for whatever reasons.
there is no need to sign your posts. this isn't usenet. your username is right there above your post. stop it.
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.
That's just stupid. A well designed AJAX app is faster to use than a regular one. Page reloads suck for applications. Have you seen Google Mail, with embedded Talk client, or maybe Calendar, or even the DHTML beta of slashdot's comments (barely AJAX, but still)? Those kick ass compared to older versions. A well designed AJAX app is great. Most AJAX apps suck, but it's not AJAX fault. And yes, it's sort of a hack. So what? So is every standards compliant site that looks good.
My english is sow-sow. Sowhat?
Speed is not the only criteria one uses to judge a Web application. For many people, being able to bookmark a page is very important. When it comes to sites using AJAX, such bookmarks are often not possible.
People also find it important to be able to open multiple pages of a site in multiple browser tabs concurrently. AJAX sites often do not allow for this, or run into problems if it is attempted.
It's also important that an AJAX site not cause a browser to repeatedly send out requests to the point of the CPU being maxed out, and the web browser becoming unusable.
There is a lot of talk about "well-designed AJAX applications", but we never actually end up seeing such a beast. You talk of GMail. I use the non-AJAX GMail interface mainly because the AJAX interface does not allow me to open emails in new tabs.
When it is very difficult, if not outright impossible, for virtually all developers to come up with even just a decent application using a specific technology, I do blame the technology. It obviously impedes the ability of even the best developers, presenting problems that cannot be avoided or worked around.
AJAX is to web development what a cucumber would be to the guy who nails in railroad spikes. It's fucking useless. The railroad builder will smash cucumber after cucumber on the railroad spike trying to nail it down, without any usable results in the end. The same goes for web development using AJAX.
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.
Bookmarking has been subverted way before AJAX came along. Any website generated from POST information can't really be bookmarked. That's what PERMALINK is for.
If it's no on fire, it's a hardware problem.
If it's no on fire, it's a hardware problem.
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
For example, let's say you have a page where a user has some sort of an inbox from which the user can delete things, like system notifications. Next to each item, you have a delete link. Clicking on the link deletes the item, meaning javascript deletes the node from the DOM, and an AJAX call gets the thing deleted from the DB. Good use of AJAX. In fact, in an AJAX-less solution, ths user 1) has to wait for the whole page to reload, and 2) if the user presses the back button, depending on browser settings, the deleted events will seem to reappear. That could be confusing. This is one very simple example of where AJAX is great.
Consider another example. A shared calendar web application, that builds a table server side, gets all the data, runs security checks on each event to see what the current user can do to each event, and then presents the data. Building the table server-side, then pumping out tons and tons of HTML code will not only tax your web server, but also generate unnecessary network traffic. You could pretty easily refactor this application to build the table client side, and then send the data to the client via a JSON object. Now, the server page that builds the JSON object is built to check the user's cookie or whatever you use for authentication and it only sends the data that the user can see. The client takes this data and build the content client side. This is the network equivalent of purchasing a disassembled computer desk and taking it home to assemble it rather than purchasing the floor model and trying to cram it into your Mazda Miata.
I give these two examples because they are real life solutions I developed at work. Both are absolutely secure, and both save the user wait time. Also, these reduce the network and server load. What's not to like?
Of course, if you design a website whose navigation controls use AJAX, or some other weird use of AJAX you will get interesting results, and by interesting I mean bad. No offense, but I think you are saying that AJAX is a bad technology perhaps because you just don't know enough about it.
Both solutions are on an intranet, else I would gladly provide links. On the internet, would I use AJAX? Absolutely! I would, of course, use just a bit more caution...no, not because of security (I know how to make secure AJAX code) but because of browser compatibility. On the intranet, I use web standards and therefore all modern browser will work great. The nice thing is, though, you aren't going to have some weirdo using Netscape 3 or something like that. On the web, would I pander, er, I mean cater to this type of user? Depends on how much I needed them as a client.
If you want to learn more about AJAX and effective javascript constructs like JSON, check out these links: http://www.sergiopereira.com/articles/advjs.html and http://www.sergiopereira.com/articles/prototype.j
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.
Look. It depends on HOW AND WHERE you use AJAX. Jeez!!! Can we please put this to bed? Yes, if you design a whole flippin site that is one page with a zillion AJAX calls, well, gee whiz! Bad idea! But, if you use your brain and use it only where it ADDS VALUE then maybe, just maybe, it's a good thing? You think? Just because beer is a good thing doesn't mean you pour it in your gas tank, use it to make Kool-Aid, or bathe in it. I am SICK (can you tell?) of people misusing technologies and then blaming the technologies! Stop it!!!
blah blah blah
We are talking about websites/webapplications here. The question is not whether you can and want to install it, but whether the customers/target group of that website want to/can/will install it -- and the answer is no, they won't. Even the most trivial install will only be made by a small percentage of people.
More than 90% of all webusers already have an AJAX-capable browser though.
while (!asleep()) sheep++
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.).
I have also given plenty of evidence that those companies don't know what they're doing: They've somehow managed to make an Ajax application many times slower for the client and server, as well as take up much more bandwidth, the exact opposite of what Ajax is meant to do. AJAX doesn't cut it for real-world deployments, kid. I know, you probably won't believe me. After all, I've only directly experienced the problems AJAX presents. I've only attempted to deploy eight AJAX applications, only to see all eight fail horribly. I can understand your frustration. But, please, try Ajax sometime in the future, after it's no longer Buzzword of the Week and you can find people who actually know how to use it properly, and you might find that it's a lot better than what you thought. I'm not talking about your experience with AJAX. Think bigger, kid. I'm talking about your lack of experience doing large-scale enterprise deployments. We're not throwing together some site for your high school that'll get 250 hits per month.
What we're talking about here is even towards the low end of the spectrum. The AJAX applications we attempted to use were only being used by about 8000 people spread throughout our offices in the northeastern US. You won't understand a deployment even of this small size until you've actually done it one or twice, kid. I've written Web sites that take advantage of Ajax that were used by a lot more than 8000 people. Believe me, I know how to use it in ways that actually save bandwidth and server processor cycles.
Want a high quality FOSS RTS game? Try Warzone 2100!