I take that back. (Using my post as an example.) In binary form, GZIP is unable to reduce the size at all. So all the compression comes from the BASE64 encoding.
That's not to say that encrypted packets that can be mildly compressed don't exist (especially in a situation like one-time pads), but my post isn't it.:)
Almost forgot to mention: Base64 encoding also chops two bits of information off of each byte. So part of the compressibility of the message is right there in the encoding.
You're assuming a perfect distribution of randomness. Getting perfect randomness is incredibly tricky, so we tend to settle for "good enough" randomness that doesn't tip off the contents of the message. That's why I can use gzip to compress my 1163 byte message down to 936 bytes. It's a pretty poor savings (227 bytes less or about 80% of the original size), but it does still compress.
Go to the police station. Get arrested. When they laugh at you, insist. [...] Get sentenced to 30 years in federal prison for a stupid crime. That's how you make people realize the law is dumb.
That won't get people to realize the law is dumb. That will get people to realize that you're a moron. I can just see the headlines now, "Man insists that he be arrested on self-trumped charges". Yeah, I'm sure the public will rally behind you on that one.
Cases like Rosa Parks and Martin Luther King involved activities for which they knew they could and likely would get arrested. They didn't go to the police station and tell the cop, "I sat on the white section of the bus today" or "I stood in front of a bus so it couldn't move." The cops would have told them to go home, as no one was pressing charges. In other words, their arrests were only notable because someone cared enough to press charges.
The lameness filter is built on compression ratios and obvious problems with the post. (e.g. ALL CAPS!) Encrypted text rarely compresses well, so it passes with flying colors.
The Atari 800 was a computer that you hooked up to your television for a monitor.
The Atari 2600 was a world-changing game console that lacked any sort of keyboard, text display, or any other computer-like features. (Not that there weren't dozens of projects to try and make it work more like a computer. Let's just say that those didn't go so well.)
The GP was talking about the former. The 2600 was never $1000./pedantry
I can believe that. MULTICS was a truly incredible operating system, but is so poorly known by the programming public at large. It wouldn't surprise me at all if HP reinvented something that was already invented in MULTICS.
It's simply too bad that Honeywell drove the system into the ground. We might all be using MULTICS derivatives today if Honeywell hadn't tried to compete against their own computers.:-(
I'm not up on my patent-ese, but I think this is describing a specific type of breakpoint technology based on virtual functions. Since we've been talking about Javascript so much lately, and it's so easy to do virtual functions in JS, here's an example in JS code:
Thus you end up with software breakpoints that can trigger the debugger based on optional listeners. At least, that's how I understand it. I could be wrong about the actual implementation.
They're defined as "all the browser vendors except Microsoft"
They're defined as "browser makers who will join". Microsoft simply hasn't agreed to join. They haven't been excluded.
their patent policy is worse than the W3C's. They don't have a patent policy. The WHATWG is an incubator/fast track for new web technologies. After it matures in the WHATWG, it gets submitted to W3C for more official level of standardization. If you've paid any attention to them, you already know that WHATWG has resulted in the reopening of the HTML working group, submission of a browser sockets standard, and several other key pieces of technology being ported over.
The only thing holding up Canvas is the fact that it includes changes to the HTML model. (i.e. The tag itself.) Thus it's up to the HTML working group to define it as a W3C standard. Something which I believe will be happening very soon now. (At least if the few hundred invited experts have any say in it.)
As someone who has done a lot of Flash and Javascript, I would say that the learning curve is feature-for-feature worse for Javascript because you need to learn about the different browsers, but may be greater overall for Flash because it offers more features.
Flash also has cross-browser problems. SWFs don't execute exactly the same on all browsers because many of the functions are handed off to the web browser. Nowhere is this more evident than with the XML.sendAndLoad APIs. They may work fine on one browser, but return unexpected results on another browser due to different caching architectures.
Computation for computation, Flash has better performance than Javascript. At least, I think that's why Mozilla accepted Adobe's donation of the EMCAScript execution engine from Flash.
Computationally, neither Flash nor Javascript have traditionally won any prizes in this area. If you want fast code and nothing else, look to Java Applets. The reason why Mozilla accepted Adobe's donation is because Adobe offered a brand new VM that fully supported the new ECMAScript 2.0 standards. Thus Adobe saved the Mozilla team a great deal of time and effort that they would have had to spend building an updated Javascript engine. The fact that the engine contains a new high-performance JIT compiler is simply gravy.
The only reason everyone uses Javascript to embed the files now is because of Microsoft's attempt to screw plug-ins.
Actually, I think it has something to do with Java being too big to be realistic in a browser, and Flash being too annoying for the average user. I know of more than one person who has ripped out the Flash plugin just so they won't have to see spinny, flashing, animated, and noisy intros or advertisements.
That's what the search engines can't index, and again it's something that's going to be a problem for any Ajax site that does the same.
Generally when you use AJAX, you put most of the content in the page itself. The only content that won't get indexed is the content that you probably don't want indexed in the first place. (e.g. Personal information)
Also, Flash-dependent sites like YouTube are definitely not starving for traffic.
Flash-dependent is not the same as being Flash-exclusive. If you build your entire site in Flash, you've got a nice-looking but ultimately less usable site. If you build your site in HTML and use Flash only where it matters, then you've got the best of both worlds. Youtube does the latter, with only the videos themselves in Flash. Everything else is easily indexable HTML. (Though arguably YouTube could get away with an all-Flash site simply because their primary advertising is word-of-mouth.)
1) Built in security against cross-domain scripting.
Untrue. For example, FoxyLady posted a vulnerability that nails any site that uses pure JSON. That's regardless of whether you use Flash or Javascript. As I mentioned before, connections from Flash go through the web browser, so stateful information can still be exploited through the same methods used in Javascript.
That's a very interesting security exploit you and your colleagues have found there. Allow me to be the first to congratulate you on being both foxy and smart!;)
I have a minor question, though. I'm currently implementing a JSON-type of interface, but I'm doing things slightly different from the straight-up JSON message described in your paper. Correct me if I'm wrong, but wrapping the JSON request in an XML packet would negate the effects of the exploit, wouldn't it?
For example, if I'm sending this message:
({test: "Hello World!"})
The actual data delivered to the client is in the form of:
I did this for maximum compatibility between request libraries. (I'm dealing with more than just Javascript requests.) If I'm understanding the exploit correctly, the browser would see this message as a malformed script and fail to load it, correct? Do you see any obvious method of defeating this encapsulation?
I am actually aware of the situation. (Apple landed that little bomb on the WHATWG mailing list about a month or two ago.) However, it was just an Apple CYA stating that Apple "makes no representations as to Apple's willingness or unwillingness to license these IP Rights." They then went on to say, "in the event that the Web Applications 1.0 Working Draft becomes part of a formalized draft standard at W3C or IETF, for example, Apple is prepared to address the disclosure/licensing rules of such organizations."
Basically, Apple is ensuring that they are clear on the fact that they haven't given up any IP rights yet because of the lack of a patent policy at the WHATWG. Since the WHATWG specs are all slowly migrating into W3C specs as they stabilize, Apple is stating that they'll deal with the patent issues as soon as they get there.
In Microsoft's case, though, there is absolutely nothing stopping them from asking Apple for individual rights that cover their browser. Microsoft and Apple have had cross-licensing patent deals in the past, so throwing Canvas into the pot would be nothing new for them. I expect that it's simply a matter of asking nicely, rather than any real barricade to implementation.
WHATWG is a perfectly good standards organization. They've been doing more to push web technology forward in the past few years than Microsoft has done in the last ten. It wouldn't kill Microsoft to sit up and pay attention to a standard implemented by all other browsers, regardless of whether it comes from the W3C or not. After all, the W3C is not the only organization that's ever standardized web technology...
Amen. I want to see DOM 2 support (not just their crappy 1.0 support from 1998), CSS that works, caching that actually works, Canvas (ok, so it's not a W3C standard; but IE is the only one missing it), SVG, a Javascript debugger that doesn't suck, so on and so forth.
Either that, or you are completely unaware of all the behind the scene computations made possible by a high level language such as JavaScript, in which case you have no idea how much "control" you are giving up.
Funny thing, though. "Control" was never a term I used. I never even insinuated that it was a problem.
Let me learns you something here, my young friend. There is a time for everything. A time to laugh, a time to cry, a time to make war, and a time to make peace. There is also a time for frameworks that meet your project specifications, and there is a time to eschew such frameworks as not being a good choice for what you need to do.
Now hear me out for a moment here. How many publicly available Google projects use GWT? When you come up with the correct answer (a lot of folks have the wrong answer to that question) you may find yourself with something to ponder.
Funny thing, though. I've seen more than enough situations where the framework is obsolete by the time it's done. Take Portlets for example. Seems like a beautiful idea. Web pages are composed of sections, therefore they should be built in sections, right? Right. 5-7 years ago, that is. When I built custom frameworks to good effect that did the same thing.
Today, you often need to go back to looking at the entire page. Why? Because the cutting edge developments require that the page be looked at as a complete memory model. If you try to take the HTML Component approach, programmer 1 may stomp all over programmer 2's Javascript or document ids by accident. Thus it suddenly makes sense to unify those pieces into libraries akin to more traditional programming methods.
Frameworks are what professionals use - the enforce well-formed code and design patterns.
Funny thing, though. We "professionals" (I like the insinuation there, BTW) use the right tool for the right job. Sometimes the right tool is NOT someone else's framework. Sometimes, you're actually creating inefficiencies by adding layers unnecessary to the project at hand. Only an amateur selects a server-side framework before knowing the requirements of the project. The "professionals" will use off the shelf if it makes sense or build their own if better results can be achieved.
In the case of Javascripting, you've got a lot of factors working against you. The first is size. You can't afford waste, because you're trying to ensure that the page renders as fast as possible. Dumping 100K+ from the scriptalicious framework just to fade out a single box isn't very effective to your budget. Especially since the same effect can be achieved in a few hundred bytes by using a custom framework.
The second factor working against you is reusability. Javascript is not very well designed to handle this area. Object Oriented concepts we take for granted in Java (interfaces, abstract classes, private methods, final assignments, etc.) are not enforceable in vanilla Javascript. So you have to either be really clever (sounds like trouble), or work through standardized practices.
The third factor working against you is maturity. These frameworks are of varying levels of maturity because such web technologies are anything but old-hat yet. There are plenty of situations they are untested in, potentially leaving you debugging someone else's code rather than moving your project forward. Thus a framework may actually increase your project time if you're not careful.
And with that, there's one last note I'd like to point out. Frameworks are far too often chosen as a crutch rather than a time-saving component. Make sure that when you chose a framework, it's because you know it will do the job you need it to. Not because you heard it's the latest craze (bad), or because you have no idea how to implement the functionality it provides (even worse).
Am I the only one who usually finds frameworks to be pointless for serious web development? It's not that they're necessarily bad, but that they pack in dozens of features that you don't necessarily need (potentially bloating the size of your page download by tens to hundreds of K) or even want. In many cases, the frameworks have a ton of little "gotchas". For example, Prototype has a set of functions that are supposed to make it easy to show and hide elements. The only problem is that if you define the "display" element in the style sheet (say, to make an element invisible by default) you can't change the element's state. This is because the Prototype library works in a stateless fashion, assuming that the default value for "display" is the way to make an item visible. Which may not be not be true.
Other libraries have some cool GUI widgets, but often those are actually too much for a project. In some cases they even require you to build the entire project out of their widgets! That's nice if you're writing the next Outlook on the Web, but not so nice if you're trying to add interactive elements to an existing webpage. Especially if you like the more open HTML design rather than the cluttered pseudo-GUI design.
In general, I've found that these libraries may be kind of nice if you're not too familiar with DOM/CSS and want to perform some neat effects. (Scriptaculous in particular does some nice effects without a whole lot of difficulty. Just watch the download size!) But if you're doing a complex website, you'll probably be better off with a custom library for now. At least until some standard practices emerge among professional sites.
Now if you want to talk about libraries that patch minor browser issues like no DOM 2 Events, lack of Object.toSource, unified XMLHttpRequest instantiation, etc., then I'd have to jump in and add glowing support for such pieces of code. The key is, though, that they're very passive libraries. You include them, and they make sure that your code works the same everywhere. Which is a bit different than being forced to structure your project around a framework. If there's one thing I love about Javascript, it's that everything is virtual.;)
They found a hammer in this kid's house. He could easily have knocked one, maybe even two people unconscious with that thing before anyone could do anything about it.
You know, that gives me an idea for a FPS mod. Rather than having all the bad guys slash you, bite you, or throw fireballs at you, how about someone ports the Hammerhead Brothers from Super Mario? Can you imagine the sheer terror of it all? Spinning hammers flying left and right, and all you have is a puny FN P90 Personal Defense Weapon for defense! How will you ever survive the onslaught?!?
Interesting factoid: I learned more about submachine guns from Stargate SG-1 than ever I learned from video games. Maybe we should arrest people who watch Stargate, too?
Slashdot Mirror
I take that back. (Using my post as an example.) In binary form, GZIP is unable to reduce the size at all. So all the compression comes from the BASE64 encoding.
:)
That's not to say that encrypted packets that can be mildly compressed don't exist (especially in a situation like one-time pads), but my post isn't it.
Almost forgot to mention: Base64 encoding also chops two bits of information off of each byte. So part of the compressibility of the message is right there in the encoding.
You're assuming a perfect distribution of randomness. Getting perfect randomness is incredibly tricky, so we tend to settle for "good enough" randomness that doesn't tip off the contents of the message. That's why I can use gzip to compress my 1163 byte message down to 936 bytes. It's a pretty poor savings (227 bytes less or about 80% of the original size), but it does still compress.
That won't get people to realize the law is dumb. That will get people to realize that you're a moron. I can just see the headlines now, "Man insists that he be arrested on self-trumped charges". Yeah, I'm sure the public will rally behind you on that one.
Cases like Rosa Parks and Martin Luther King involved activities for which they knew they could and likely would get arrested. They didn't go to the police station and tell the cop, "I sat on the white section of the bus today" or "I stood in front of a bus so it couldn't move." The cops would have told them to go home, as no one was pressing charges. In other words, their arrests were only notable because someone cared enough to press charges.
I don't think it works. All I get is a bunch of numbers.
Except that you're missing about 3/4 of the post. When you use an online cryto program, remember that they have scrollbars. ;-)
The lameness filter is built on compression ratios and obvious problems with the post. (e.g. ALL CAPS!) Encrypted text rarely compresses well, so it passes with flying colors.
RC4; Base64 Encoding; Key = "09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0"
t Ds1V97iWQxx ySmgi8BdedG AsLVTLLTc0J Yg11Y576o"j Ue7R919DRxl wzs_UvVSRhh nyCcADUH6Gf GSm7HfCs_iy BTwMZnuZYLI Wn1KXh6_Rx2 q3ZzeFJD5MQ nlxHfxzWhlj P8of4TEJU0k Fg3voVVPEpn ceesWk6v0rG oYSEXQH_Bo_ qmXGJlSjF"w wPLEWhn1kzs A1_faWxcxe
mI0mUyOUE8S24UAsIVqR12Z8_P1WveIRFqpBO4FEeH_TPGuc0
QDhXbGpiERffrXz6lvQpcOFlDY_AXJWGw7f9saosuSBDj7c4e
l4APCHQIzYXETWu"xkhR4MNnw7zI_mBf5YJOLJ3DKD6wSQ6Pv
ZAPkCzunB7xarymAJEOOu0fe"tdhy"rZZY5XOSiipi6vf_84x
rPfhQQNneUX"JGXWhN3bgRIZwIOoIUu8c282MQ5_Grb6ALolI
j7cWlf2G2V467N4EjnJbR"9j_4oDCytfpkQBFX0jGOCsjRYcL
HH7DzXzB2tPz7i"L1Unvljgh05d1qoFs2N38qWugtaUMGM9RX
yUXVAbsO9ZcD33UKD80sulFF0FiSxIr4NOiRv4EZBoIU3eY1F
yi4NfhRLz3ai50dbx0CWCJwlvti_gsXgQLJrE70ihDROzdUyj
9AM2M99"s2d"hQxtoj7yTTki2M4dK3Y8_wvSyM8fp5fyyDpJW
z3W8iYIMIObDRG1H914rayBqj3EPhUDsz2NfVhjYBIxHBPgeW
saZXht6YNavXOyFLh24D84kXC4weBrJsI598yUpFhg41NB694
vZaHrMlSDxODtGlaU5rfJkODjrCr99Rr6hgQaegXnHE6Oe6iK
DwDtOw3"khTuVWYDStjRd4w2eOt2wvl24XvC3iDQBIA40uJQh
29XXEh_9hplaGD1YBw6pW2yiuyW8ifdaS4Mm7IGdH"6JMgSFg
k8"H70be7kCOdyDSLX9jLkz"4MF_LD"yaYdWopVnoryVQ9YD5
RqZmxLv2loAoM5WFs2""qGG4yATAMz9zhyuc4wMPZZLiZJhTt
pNNm045ma6vnqBdwtEE00zdjJBhBjz5VMoqPS6EZvQbwbEyiU
KJdzO7ATz47fYRWQZNWjy7Uda1P8RPnhSd2FbrL"aOegRzUX_
Azf
Hey, it's not often that I find an opportunity to compliment a lady without sounding like a total dork. So just enjoy the compliment.
Thanks for verifying that. I figured I was safe, but every once in a while there is a very clever workaround.
Nitpicking warning: This post is nitpicky.
/pedantry
The Atari 800 was a computer that you hooked up to your television for a monitor.
The Atari 2600 was a world-changing game console that lacked any sort of keyboard, text display, or any other computer-like features. (Not that there weren't dozens of projects to try and make it work more like a computer. Let's just say that those didn't go so well.)
The GP was talking about the former. The 2600 was never $1000.
I can believe that. MULTICS was a truly incredible operating system, but is so poorly known by the programming public at large. It wouldn't surprise me at all if HP reinvented something that was already invented in MULTICS.
:-(
It's simply too bad that Honeywell drove the system into the ground. We might all be using MULTICS derivatives today if Honeywell hadn't tried to compete against their own computers.
They're defined as "browser makers who will join". Microsoft simply hasn't agreed to join. They haven't been excluded.
their patent policy is worse than the W3C's.
They don't have a patent policy. The WHATWG is an incubator/fast track for new web technologies. After it matures in the WHATWG, it gets submitted to W3C for more official level of standardization. If you've paid any attention to them, you already know that WHATWG has resulted in the reopening of the HTML working group, submission of a browser sockets standard, and several other key pieces of technology being ported over.
The only thing holding up Canvas is the fact that it includes changes to the HTML model. (i.e. The tag itself.) Thus it's up to the HTML working group to define it as a W3C standard. Something which I believe will be happening very soon now. (At least if the few hundred invited experts have any say in it.)
Flash also has cross-browser problems. SWFs don't execute exactly the same on all browsers because many of the functions are handed off to the web browser. Nowhere is this more evident than with the XML.sendAndLoad APIs. They may work fine on one browser, but return unexpected results on another browser due to different caching architectures.
Computationally, neither Flash nor Javascript have traditionally won any prizes in this area. If you want fast code and nothing else, look to Java Applets. The reason why Mozilla accepted Adobe's donation is because Adobe offered a brand new VM that fully supported the new ECMAScript 2.0 standards. Thus Adobe saved the Mozilla team a great deal of time and effort that they would have had to spend building an updated Javascript engine. The fact that the engine contains a new high-performance JIT compiler is simply gravy.
Actually, I think it has something to do with Java being too big to be realistic in a browser, and Flash being too annoying for the average user. I know of more than one person who has ripped out the Flash plugin just so they won't have to see spinny, flashing, animated, and noisy intros or advertisements.
Generally when you use AJAX, you put most of the content in the page itself. The only content that won't get indexed is the content that you probably don't want indexed in the first place. (e.g. Personal information)
Flash-dependent is not the same as being Flash-exclusive. If you build your entire site in Flash, you've got a nice-looking but ultimately less usable site. If you build your site in HTML and use Flash only where it matters, then you've got the best of both worlds. Youtube does the latter, with only the videos themselves in Flash. Everything else is easily indexable HTML. (Though arguably YouTube could get away with an all-Flash site simply because their primary advertising is word-of-mouth.)
Untrue. For example, FoxyLady posted a vulnerability that nails any site that uses pure JSON. That's regardless of whether you use Flash or Javascript. As I mentioned before, connections from Flash go through the web browser, so stateful information can still be exploited through the same methods used in Javascript.
I have a minor question, though. I'm currently implementing a JSON-type of interface, but I'm doing things slightly different from the straight-up JSON message described in your paper. Correct me if I'm wrong, but wrapping the JSON request in an XML packet would negate the effects of the exploit, wouldn't it?
For example, if I'm sending this message: The actual data delivered to the client is in the form of: I did this for maximum compatibility between request libraries. (I'm dealing with more than just Javascript requests.) If I'm understanding the exploit correctly, the browser would see this message as a malformed script and fail to load it, correct? Do you see any obvious method of defeating this encapsulation?
I am actually aware of the situation. (Apple landed that little bomb on the WHATWG mailing list about a month or two ago.) However, it was just an Apple CYA stating that Apple "makes no representations as to Apple's willingness or unwillingness to license these IP Rights." They then went on to say, "in the event that the Web Applications 1.0 Working Draft becomes part of a formalized draft standard at W3C or IETF, for example, Apple is prepared to address the disclosure/licensing rules of such organizations."
Basically, Apple is ensuring that they are clear on the fact that they haven't given up any IP rights yet because of the lack of a patent policy at the WHATWG. Since the WHATWG specs are all slowly migrating into W3C specs as they stabilize, Apple is stating that they'll deal with the patent issues as soon as they get there.
In Microsoft's case, though, there is absolutely nothing stopping them from asking Apple for individual rights that cover their browser. Microsoft and Apple have had cross-licensing patent deals in the past, so throwing Canvas into the pot would be nothing new for them. I expect that it's simply a matter of asking nicely, rather than any real barricade to implementation.
WHATWG is a perfectly good standards organization. They've been doing more to push web technology forward in the past few years than Microsoft has done in the last ten. It wouldn't kill Microsoft to sit up and pay attention to a standard implemented by all other browsers, regardless of whether it comes from the W3C or not. After all, the W3C is not the only organization that's ever standardized web technology...
You have no idea how much server-side GZipping futzes up AJAX and Flash apps in IE. Absolutely no idea.
Amen. I want to see DOM 2 support (not just their crappy 1.0 support from 1998), CSS that works, caching that actually works, Canvas (ok, so it's not a W3C standard; but IE is the only one missing it), SVG, a Javascript debugger that doesn't suck, so on and so forth.
Funny thing, though. "Control" was never a term I used. I never even insinuated that it was a problem.
Let me learns you something here, my young friend. There is a time for everything. A time to laugh, a time to cry, a time to make war, and a time to make peace. There is also a time for frameworks that meet your project specifications, and there is a time to eschew such frameworks as not being a good choice for what you need to do.
Now hear me out for a moment here. How many publicly available Google projects use GWT? When you come up with the correct answer (a lot of folks have the wrong answer to that question) you may find yourself with something to ponder.
You laugh now. But what if I told you that previous versions of EyeOS did exactly that? I wish I was joking.
I don't know about the current version, though. It seems to do some sort of weird page-refresh thing.
Funny thing, though. I've seen more than enough situations where the framework is obsolete by the time it's done. Take Portlets for example. Seems like a beautiful idea. Web pages are composed of sections, therefore they should be built in sections, right? Right. 5-7 years ago, that is. When I built custom frameworks to good effect that did the same thing.
Today, you often need to go back to looking at the entire page. Why? Because the cutting edge developments require that the page be looked at as a complete memory model. If you try to take the HTML Component approach, programmer 1 may stomp all over programmer 2's Javascript or document ids by accident. Thus it suddenly makes sense to unify those pieces into libraries akin to more traditional programming methods.
Right tool. Right job.
Funny thing, though. We "professionals" (I like the insinuation there, BTW) use the right tool for the right job. Sometimes the right tool is NOT someone else's framework. Sometimes, you're actually creating inefficiencies by adding layers unnecessary to the project at hand. Only an amateur selects a server-side framework before knowing the requirements of the project. The "professionals" will use off the shelf if it makes sense or build their own if better results can be achieved.
In the case of Javascripting, you've got a lot of factors working against you. The first is size. You can't afford waste, because you're trying to ensure that the page renders as fast as possible. Dumping 100K+ from the scriptalicious framework just to fade out a single box isn't very effective to your budget. Especially since the same effect can be achieved in a few hundred bytes by using a custom framework.
The second factor working against you is reusability. Javascript is not very well designed to handle this area. Object Oriented concepts we take for granted in Java (interfaces, abstract classes, private methods, final assignments, etc.) are not enforceable in vanilla Javascript. So you have to either be really clever (sounds like trouble), or work through standardized practices.
The third factor working against you is maturity. These frameworks are of varying levels of maturity because such web technologies are anything but old-hat yet. There are plenty of situations they are untested in, potentially leaving you debugging someone else's code rather than moving your project forward. Thus a framework may actually increase your project time if you're not careful.
And with that, there's one last note I'd like to point out. Frameworks are far too often chosen as a crutch rather than a time-saving component. Make sure that when you chose a framework, it's because you know it will do the job you need it to. Not because you heard it's the latest craze (bad), or because you have no idea how to implement the functionality it provides (even worse).
Am I the only one who usually finds frameworks to be pointless for serious web development? It's not that they're necessarily bad, but that they pack in dozens of features that you don't necessarily need (potentially bloating the size of your page download by tens to hundreds of K) or even want. In many cases, the frameworks have a ton of little "gotchas". For example, Prototype has a set of functions that are supposed to make it easy to show and hide elements. The only problem is that if you define the "display" element in the style sheet (say, to make an element invisible by default) you can't change the element's state. This is because the Prototype library works in a stateless fashion, assuming that the default value for "display" is the way to make an item visible. Which may not be not be true.
;)
Other libraries have some cool GUI widgets, but often those are actually too much for a project. In some cases they even require you to build the entire project out of their widgets! That's nice if you're writing the next Outlook on the Web, but not so nice if you're trying to add interactive elements to an existing webpage. Especially if you like the more open HTML design rather than the cluttered pseudo-GUI design.
In general, I've found that these libraries may be kind of nice if you're not too familiar with DOM/CSS and want to perform some neat effects. (Scriptaculous in particular does some nice effects without a whole lot of difficulty. Just watch the download size!) But if you're doing a complex website, you'll probably be better off with a custom library for now. At least until some standard practices emerge among professional sites.
Now if you want to talk about libraries that patch minor browser issues like no DOM 2 Events, lack of Object.toSource, unified XMLHttpRequest instantiation, etc., then I'd have to jump in and add glowing support for such pieces of code. The key is, though, that they're very passive libraries. You include them, and they make sure that your code works the same everywhere. Which is a bit different than being forced to structure your project around a framework. If there's one thing I love about Javascript, it's that everything is virtual.
You know, that gives me an idea for a FPS mod. Rather than having all the bad guys slash you, bite you, or throw fireballs at you, how about someone ports the Hammerhead Brothers from Super Mario? Can you imagine the sheer terror of it all? Spinning hammers flying left and right, and all you have is a puny FN P90 Personal Defense Weapon for defense! How will you ever survive the onslaught?!?
Interesting factoid: I learned more about submachine guns from Stargate SG-1 than ever I learned from video games. Maybe we should arrest people who watch Stargate, too?