Nithendil writes "guyhersh from reddit.com describes the situation (warning: title NSFW): Based on what I've seen today, here's what went down. Reddit user Empirical wrote javascript code where if you copied and pasted it into the address bar, you would instantly spam that comment by replying to all the comments on the page and submitting it. Later xssfinder posted a proof of concept where if you hovered over a link, it would automatically run a Javascript. He then got the brilliant idea to combine the two scripts together, tested it and it spread from there."
Hi there - you must have just popped in from some alternate universe
Yep. It's called Google Chrome -- or, more accurately, the Chromium nightly. Javascript executes quickly, and I don't have to wait for an entire separate page to load. Additionally, if I have to wait, the "submit" button has a countdown timer.
And regardless of speed, it is convenient to have that much more context on the page. For example, right now, I can see your post and mine, and I can expand the parents if I need to. If I was replying from the main discussion, I could scroll up to see the whole discussion. Yes, I know about tabs, but even switching with keyboard shortcuts isn't as nice as being able to actually see a few posts of context as I type.
In this universe, the speed with javascript is noticeably slower - in many cases it's so slow as to be unusable.
Just as exploits in the image processing components of web browsers will hopefully educate people to surf in Lynx? Or exploits in their HTML rendering will hopefully educate people to surf by piping wget through less?
This was not because of Javascript, nor is Javascript going away because of this.
Just as exploits in the image processing components of web browsers will hopefully educate people to surf in Lynx? Or exploits in their HTML rendering will hopefully educate people to surf by piping wget through less?
There's a huge difference in complexity between image/HTML renderer and Javascript. Image file formats and HTML pages are not Turing complete, while Javascript is. Consequently, the former are "safe" in that it's possible to prove that a particular implementation is free of exploits that would allow running arbitrary code, while Javascript by definition can never be; the whole point of Javascript is to allow arbitrary code execution, so the best you could ever prove is that the code never leaves the confines of the Web browser - but having a script post comments does not require that.
This was not because of Javascript, nor is Javascript going away because of this.
Yes, this was because of Javascript, but no, sadly it won't be going away.
This isn't a lesson about javascript. It is a lesson we should have learned from Bobby Tables a long time ago. This shouldn't have been possible regardless of javascript.
No it's not. The Reddit hack was a Cross Site Scripting [wikipedia.org] attack made possible by bugs in their markdown implementation which let javascript through the parser. It was not a SQL injection attack, it did not attack the database directly, no commands were ran to directly put data into the database. It's an entirely different vector and an entirely different vulnerability, all the stored procedures, escaping of apostrophes and parametrised SQL in the world would not have stopped this.
Filtering user input properly would have stopped this though. It is not an attack which relies on a flaw specific to javascript - the flaw is a very general one - using untrusted user input without aggressive filtering.
What exactly does being Turing complete have to do with it? If a scripting language weren't turing complete, but had direct read/write access to your file system, would it be any safer than JS?
The problem with Reddit isn't JavaScript but rather their markdown implementation. And the security threat here isn't to the user whose system is running the JS, but instead to the Reddit site. If you're using an up-to-date & secure browser, there's typically minimal risk to enabling JavaScript. That JavaScript ca
Yes, this was because of Javascript, but no, sadly it won't be going away.
So, all bots that crawl forums to spam them are Javascript? Honestly, if Javascript could do this, I wonder what a more complex bot could have done. Are we all going to lament about the programming language that some forum bot was written in? C? Python?
"Yes, this was because of C, but no, sadly it won't be going away."
Can't see why people get such a hardon bashing Javascript. "Because it's not a real programming language!"? I guess it's the same mentality that leads people to bash PHP, Perl, Ruby, ASP, etc. etc.
I look at it this way. Javascript is a tool and bad programming is bad programming and sadly, bad programming won't be going away.
It's 2009. We should be able to use the internet the way it is intended, with javascript. Javascript isn't the problem, poor programming on reddit's behalf is the problem.
This is a flaw in Reddit's comment system, that allows the poster to get javascript code executed. A comment system should not allow you to use "onhover" that is the point.
Years ago I actually proposed to the W3C and the mozilla bunch to add a tag to disable dynamic stuff like javascript.
Basically it would work something like this:
<shield lock="some_random_hard_to_guess_string_here" enabled="basic_html_only"> The browser will only recognize basic HTML stuff here, it won't recognize javascript or any _future_ dynamic stuff that the W3C or browser people think off </shield unlock="some_random_hard_to_guess_string_here">
The some_random_hard_to_guess_string_here would be different for each page.
The idea is while the website should still have filters, even if in the future the W3C or browser wiseguys create some new fangled way of inserting javascript or some other dynamic content that the filters do not protect against (since it's new and the filters have not been updated), the browser will just ignore the new stuff that some hacker inserts when it's between the tags.
To me the current state of things is a bit crazy - basically it's like having a car with 1000 gas pedals (tags) and to stop the car you have to make sure all 1000 pedals are not pressed (escaped or filtered). There is not a single brake pedal! And worse, the W3C or MS or Mozilla or whoever could introduce a new gas pedal, and you the website operator have to filter out the new gas pedal when it's introduced.
With something like this tag there is a brake pedal, so even if you don't manage to filter out all the 1000 gas pedals, the brake helps to keep stuff safe.
If they had implemented such a tag, the google and myspace worms would not have worked for so many browsers.
FWIW, these sort of worms are not new. I managed to find a hole in advogato some years ago (iframe worm) - and hence my suggestion to the W3C and Mozilla.
But it seems to me than NONE of them are really interested in improving security. They're all just interested in inventing new gas pedals for people (and hackers) to step on. They're not even interested in creating a single brake pedal. They just pay lip service to security.
See the thing is - it's not too difficult to code a browser to go "OK from now on there's no such thing as javascript till I see a valid unlock tag", so even if there is a browser parsing bug and a hacker manages to insert javascript via a stupid browser bug (that the website filters naturally do not and cannot cater for) it does NOT matter - since javascript will be disabled - between those tags the browser will be respecting the flag that says "I do not know javascript, java and all that fancy stuff" - it does not even have to parse javascript - since for all intents and purposes between those tags, the browser does not know there's such a thing as javascript (or activex or flash etc).
This is very useful for sites that have to include 3rd party content - sites like slashdot or webmail sites or even sites that serve up ads from 3rd parties.
Tools like that aren't foolproof, especially since browsers go out of their way to attempt to parse malformed input (unless you're serving content as application/xml, in which case the browser will just show an ugly parse error). I can't speak about that tool not having used it, but all it takes is one hacker finding yet another way to create a broken script tag that a browser will still run that they don't yet know about and all your efforts are for nothing.
There are many situations other than forum posting where it is desirable to include third-party content in your site. Advertisements are the first thing that jump to mind, but web widgets are also becoming popular. Having some browser markup that will limit what the third-party code can do would enable this to be done safely, without having to trust the third party or load and filter third-party content server-side.
Reddit does escape all of those symbols, and they use Markdown [wikipedia.org] for adding links. Still, they managed to get owned by an obscure vulnerability that was discovered only because their code is open source.
And that's the point TheLink was trying to make. It would be far simpler to tell the browser not to accept javascript in a certain block of code than it is to explore all the possible exploits that could be leveraged against your alternative markup language. There are hundreds if not thousands of places you can make mistakes, and it could be remedied by a single mechanism that prevented javascript from existing in certain blocks of code.
Cue me reposting my views on noscript being a pretty crappy tool for modern web security then.
NoScript comes from a broken way of thinking, "you can identify attacking sites and trusted sites", the attack code for this was coming from reddit.com (a site you have to allow in order to use reddit). The only way this sort of bug can be protected against is by use of javascript filtering tools such as controldescripts [mozdev.org] that filter javascript request by type and domain, with such a tool it would be possible to protect yourself much more effectively.
mouseclick is submitting info -> allow mouseover is requesting data -> allow mouseover is submitting data -> request user confirmation javascript function is doing something weird -> request user confirmation javascript is trying to use a known exploit* -> deny and notify user (as a workaround for 0-days simply blocking the bad JS calls will protect users much faster than browsers usually get patched)...etc
You could also combine this with domain checking to have lists of pages where you allow *no-js (untrusted), *simple-JS (google, youtube, etc) but [it might allow functionality but could prevent tracking], *complex-js (facebook, etc) [all the ajax stuff means simple-JS wouldn't work] *all-JS (fancynewsite.com) [even the complex list of functions you allow just isn't enough]
Such tools could also help the paranoid among us use website that require JS, by disabling mousetracking and sending of data on non-click actions.
As long as people stick to the broken thinking of trusted/untrusted domains, there is little chance of this actually happening. The worst thing about noscript is that for an unkown site you often have to allow JS on it to see what it looks like, so unless you plan on only browsing sites you've already been to and those that don't use javascript, it is completely useless yet its users claim, nay genuinely think they are more secure!
The only fucking thing NSFW about the link is that it fucking says "What the fuck" in the title. And if you can read my fucking comment, you can go ahead and fucking click that link.
And here's another "Fuck" just for the heck of it.
Warning: my comment was NSFW and should not have been read.
This is not a weakness or an exploit, it's simply a javascript bookmarklet. [wikipedia.org] You could make something like this for any site, such as Slashdot.
It's only an exploit if you can force other people to run that code without their consent.
KeyserSosa
Thanks for this (and thanks aedes ). I'm going to steal his idea and post here as well.
We've fixed a couple of underlying bugs in markdown.py, and will write a blog post for those interested once the dust settles. We've also gone through and deleted the offending comments.
This exploit was a good old-fashioned worm, and its only purpose seems to have been to spread (and spread it did). The effect was limited to the site, and no user information was compromised.
by Anonymous Coward
on Monday September 28, @09:21AM (#29565353)
As a web developer, I beg to differ. There is absolutely no excuse for writing a page that doesn't 'fail gracefully' when javascript isn't present. Let's face it, for every reputable page out there (att.net, youtube.com, etc) there are a hundred others designed by average joe-schmo webprogrammers. And lord only knows if they designed their page securely, and lord only knows if someone has hacked them and injected malicious scripts. I seem to recall hearing a few weeks ago that the majority of malicious scripts were being put into hollywood celebrity gossip sites that people were hitting off their google searches.
For me, the solution is to just whitelist the sites I visit frequently, only allowing scripts/cookies when I know they can be trusted. I'm not saying that you shouldn't design without javascript, but I am saying that you shouldn't assume that everyone visiting your page is going to have it. Besides, how hard is it to write a page that vomits up its contents in a readable form when the javascript doesn't run to position all the css objects? It doesn't have to look pretty, but it should be usable.
Amen. I've gotten into the habit of structuring the document, outputting the data into readable form, then using CSS and JS to make it look and behave how I want it to.
There are some pages where "no access without javascript" is acceptable - but they are few and far between. For the most part, you should be able to use Lynx and view the content.
There is absolutely no excuse for writing a page that doesn't 'fail gracefully' when javascript isn't present.
Yes there is. Making your page fail gracefully takes extra time and resources, which could be put to better use than supporting the 1% of users who choose to handicap their browsers by turning off javascript.
Failing gracefully is an important concern, but its not the only concern, and should be balanced against other priorities.
The idea is to build the page in fail-state first, and then use JavaScript to enhance it. Or in other words, build your DOM and then restyle, add event listeners, etc.
It doesn't take extra time, and it's a great technique for future-proofing your pages. It also makes them accessible to people who, for whatever reason, can't take advantage of teh javascript. If your website is in the US, and is big enough for anyone to care, ADA compliance pretty much requires it.
Absolutely right for your personal homepage. A professional web designer would not be able to get away with this. This kind of laziness translations directly into additional support costs for the client. And each time Microsoft recommends turning off Javascript due to a 0-day exploit you are cutting off more than 1%.
I can't think of any cases where it is ok to not fail gracefully. I hope you are not talking about just using client side validation, one of the most used cases for Javascript but where you must
Anyone who believes this has simply never written a web application. Javascript and cookies are absolutely essential to any web programmer who wishes have any type of dynamic content on a page.
So by advising people to disable Javascript, I'm doing my part for killing off "Web Applications" and getting us back to good old Web Pages. Excellent.
Seriously, why would I want "dynamic content" when all that really means is a thousand pauses as more data is fetched? Give me static pages whenever possible. Better yet, give me a single large static page rather than a dozen small pages, so I don't have to wait while the next page is being loaded and rendered.
The solution is for programmers to stop being idiots and write secure code, both in web applications and in the browsers themselves.
The solution is to understand that most web sites are not applications, from the users point of view, and stop stuffing them full of scripts that do nothing but slow things down.
Is this good news or bad? (Score:4, Funny)
I don't know. Sounds good !!
Re:Is this good news or bad? (Score:5, Insightful)
*cough*Slashdot*cough*
Parent
Re:Is this good news or bad? (Score:4, Interesting)
Hi there - you must have just popped in from some alternate universe
Yep. It's called Google Chrome -- or, more accurately, the Chromium nightly. Javascript executes quickly, and I don't have to wait for an entire separate page to load. Additionally, if I have to wait, the "submit" button has a countdown timer.
And regardless of speed, it is convenient to have that much more context on the page. For example, right now, I can see your post and mine, and I can expand the parents if I need to. If I was replying from the main discussion, I could scroll up to see the whole discussion. Yes, I know about tabs, but even switching with keyboard shortcuts isn't as nice as being able to actually see a few posts of context as I type.
In this universe, the speed with javascript is noticeably slower - in many cases it's so slow as to be unusable.
Which browser?
Parent
Re:Is this good news or bad? (Score:5, Insightful)
No, it won't. The other 6 million javascript exploits didn't do that. What makes you think this one will?
Parent
Re:Is this good news or bad? (Score:5, Insightful)
Just as exploits in the image processing components of web browsers will hopefully educate people to surf in Lynx? Or exploits in their HTML rendering will hopefully educate people to surf by piping wget through less?
This was not because of Javascript, nor is Javascript going away because of this.
Parent
Re:Is this good news or bad? (Score:5, Insightful)
There's a huge difference in complexity between image/HTML renderer and Javascript. Image file formats and HTML pages are not Turing complete, while Javascript is. Consequently, the former are "safe" in that it's possible to prove that a particular implementation is free of exploits that would allow running arbitrary code, while Javascript by definition can never be; the whole point of Javascript is to allow arbitrary code execution, so the best you could ever prove is that the code never leaves the confines of the Web browser - but having a script post comments does not require that.
Yes, this was because of Javascript, but no, sadly it won't be going away.
Parent
Re:Is this good news or bad? (Score:5, Insightful)
For those not in the know: http://xkcd.com/327/ [xkcd.com]
Parent
Re: (Score:3, Informative)
Re:Is this good news or bad? (Score:4, Informative)
Filtering user input properly would have stopped this though. It is not an attack which relies on a flaw specific to javascript - the flaw is a very general one - using untrusted user input without aggressive filtering.
Parent
Re: (Score:3, Insightful)
What exactly does being Turing complete have to do with it? If a scripting language weren't turing complete, but had direct read/write access to your file system, would it be any safer than JS?
The problem with Reddit isn't JavaScript but rather their markdown implementation. And the security threat here isn't to the user whose system is running the JS, but instead to the Reddit site. If you're using an up-to-date & secure browser, there's typically minimal risk to enabling JavaScript. That JavaScript ca
Re:Is this good news or bad? (Score:4, Insightful)
Yes, this was because of Javascript, but no, sadly it won't be going away.
So, all bots that crawl forums to spam them are Javascript? Honestly, if Javascript could do this, I wonder what a more complex bot could have done. Are we all going to lament about the programming language that some forum bot was written in? C? Python?
"Yes, this was because of C, but no, sadly it won't be going away."
Can't see why people get such a hardon bashing Javascript. "Because it's not a real programming language!"? I guess it's the same mentality that leads people to bash PHP, Perl, Ruby, ASP, etc. etc.
I look at it this way. Javascript is a tool and bad programming is bad programming and sadly, bad programming won't be going away.
Parent
Re:Is this good news or bad? (Score:4, Insightful)
Parent
proof of concept (Score:3, Insightful)
Re:proof of concept (Score:4, Informative)
Parent
html tag to disable active content (Score:5, Insightful)
Basically it would work something like this:
<shield lock="some_random_hard_to_guess_string_here" enabled="basic_html_only">
The browser will only recognize basic HTML stuff here, it won't recognize javascript or any _future_ dynamic stuff that the W3C or browser people think off
</shield unlock="some_random_hard_to_guess_string_here">
The some_random_hard_to_guess_string_here would be different for each page.
The idea is while the website should still have filters, even if in the future the W3C or browser wiseguys create some new fangled way of inserting javascript or some other dynamic content that the filters do not protect against (since it's new and the filters have not been updated), the browser will just ignore the new stuff that some hacker inserts when it's between the tags.
To me the current state of things is a bit crazy - basically it's like having a car with 1000 gas pedals (tags) and to stop the car you have to make sure all 1000 pedals are not pressed (escaped or filtered). There is not a single brake pedal! And worse, the W3C or MS or Mozilla or whoever could introduce a new gas pedal, and you the website operator have to filter out the new gas pedal when it's introduced.
With something like this tag there is a brake pedal, so even if you don't manage to filter out all the 1000 gas pedals, the brake helps to keep stuff safe.
If they had implemented such a tag, the google and myspace worms would not have worked for so many browsers.
FWIW, these sort of worms are not new. I managed to find a hole in advogato some years ago (iframe worm) - and hence my suggestion to the W3C and Mozilla.
But it seems to me than NONE of them are really interested in improving security. They're all just interested in inventing new gas pedals for people (and hackers) to step on. They're not even interested in creating a single brake pedal. They just pay lip service to security.
See the thing is - it's not too difficult to code a browser to go "OK from now on there's no such thing as javascript till I see a valid unlock tag", so even if there is a browser parsing bug and a hacker manages to insert javascript via a stupid browser bug (that the website filters naturally do not and cannot cater for) it does NOT matter - since javascript will be disabled - between those tags the browser will be respecting the flag that says "I do not know javascript, java and all that fancy stuff" - it does not even have to parse javascript - since for all intents and purposes between those tags, the browser does not know there's such a thing as javascript (or activex or flash etc).
This is very useful for sites that have to include 3rd party content - sites like slashdot or webmail sites or even sites that serve up ads from 3rd parties.
Parent
Re:html tag to disable active content (Score:5, Insightful)
Well that's an overly complicated and... well *wrong* way to do it. The correct solution is:
1. Escape all <'s and >'s and &'s in the input.
2. Interpret BB-code to add links & basic formatting.
Simple.
Parent
Mod parent down (Score:3, Informative)
Re: (Score:3, Interesting)
Tools like that aren't foolproof, especially since browsers go out of their way to attempt to parse malformed input (unless you're serving content as application/xml, in which case the browser will just show an ugly parse error). I can't speak about that tool not having used it, but all it takes is one hacker finding yet another way to create a broken script tag that a browser will still run that they don't yet know about and all your efforts are for nothing.
I think the parent's suggestion of BBCode is saf
You have a narrow view of the problem. (Score:3, Insightful)
There are many situations other than forum posting where it is desirable to include third-party content in your site. Advertisements are the first thing that jump to mind, but web widgets are also becoming popular. Having some browser markup that will limit what the third-party code can do would enable this to be done safely, without having to trust the third party or load and filter third-party content server-side.
Re:html tag to disable active content (Score:4, Insightful)
And that's the point TheLink was trying to make. It would be far simpler to tell the browser not to accept javascript in a certain block of code than it is to explore all the possible exploits that could be leveraged against your alternative markup language. There are hundreds if not thousands of places you can make mistakes, and it could be remedied by a single mechanism that prevented javascript from existing in certain blocks of code.
Parent
Re: (Score:3, Insightful)
Apparently the damage was limited to only one site... But similar hacks could be done on other vulnerable sites.
NoScript (Score:5, Insightful)
"NoScript FTW!" comments commencing in 3... 2... 1...
I skimmed the FAQ on the first link, and it seems reddit is responsible for not scrubbing input.
Next!
Re: (Score:3, Interesting)
I love how *their* mistake causes viral problems in YOUR browser. All one needs is some sort of cross site vulnerability now and ...
Re:NoScript (Score:4, Insightful)
Cue me reposting my views on noscript being a pretty crappy tool for modern web security then.
NoScript comes from a broken way of thinking, "you can identify attacking sites and trusted sites", the attack code for this was coming from reddit.com (a site you have to allow in order to use reddit). The only way this sort of bug can be protected against is by use of javascript filtering tools such as controldescripts [mozdev.org] that filter javascript request by type and domain, with such a tool it would be possible to protect yourself much more effectively.
mouseclick is submitting info -> allow ...etc
mouseover is requesting data -> allow
mouseover is submitting data -> request user confirmation
javascript function is doing something weird -> request user confirmation
javascript is trying to use a known exploit* -> deny and notify user (as a workaround for 0-days simply blocking the bad JS calls will protect users much faster than browsers usually get patched)
You could also combine this with domain checking to have lists of pages where you allow
*no-js (untrusted),
*simple-JS (google, youtube, etc) but [it might allow functionality but could prevent tracking],
*complex-js (facebook, etc) [all the ajax stuff means simple-JS wouldn't work]
*all-JS (fancynewsite.com) [even the complex list of functions you allow just isn't enough]
Such tools could also help the paranoid among us use website that require JS, by disabling mousetracking and sending of data on non-click actions.
As long as people stick to the broken thinking of trusted/untrusted domains, there is little chance of this actually happening. The worst thing about noscript is that for an unkown site you often have to allow JS on it to see what it looks like, so unless you plan on only browsing sites you've already been to and those that don't use javascript, it is completely useless yet its users claim, nay genuinely think they are more secure!
Parent
NSFW? (Score:3)
guyhersh from reddit.com describes the situation (warning: title NSFW)
Does anybody have a SFW link? Something like this certainly must have more than one FA.
Re:NSFW? (Score:5, Funny)
> Eye owl wise ewes a spill chucker sew eye no my spilling is core wrecked.
Hey, whadda ya know? A sig with a New Zealand accent.
(Yeah, yeah, I know, offtopic, blah, blah, mod-away...)
Parent
Re:NSFW? (Score:5, Funny)
The only fucking thing NSFW about the link is that it fucking says "What the fuck" in the title. And if you can read my fucking comment, you can go ahead and fucking click that link.
And here's another "Fuck" just for the heck of it.
Warning: my comment was NSFW and should not have been read.
Parent
Re:NSFW? (Score:5, Funny)
Parent
Re:NSFW? (Score:4, Funny)
FUCK!!!
Parent
Re: (Score:3, Insightful)
And if you did have a braindead tripwire like that, it would have jumped on the fact that fuck is in the url in the summary.
Reddit Hacks (Score:3, Interesting)
Putting javascript:$(".up").click()() in the address bar upvotes everything on the page.
Re:Reddit Hacks (Score:5, Insightful)
This is not a weakness or an exploit, it's simply a javascript bookmarklet. [wikipedia.org] You could make something like this for any site, such as Slashdot.
It's only an exploit if you can force other people to run that code without their consent.
Parent
Already fixed. (Score:3, Informative)
KeyserSosa Thanks for this (and thanks aedes ). I'm going to steal his idea and post here as well. We've fixed a couple of underlying bugs in markdown.py, and will write a blog post for those interested once the dust settles. We've also gone through and deleted the offending comments. This exploit was a good old-fashioned worm, and its only purpose seems to have been to spread (and spread it did). The effect was limited to the site, and no user information was compromised.
So obviously this is no longer spreading.
A Good Idea (Score:5, Insightful)
Hey, everyone, there is a javascript exploit on Reddit! Click on these links to Reddit to learn more.
Incidentally, this old sock smells awful. You should smell it.
Myspace (Score:3, Interesting)
http://web.archive.org/web/20060208182348/namb.la/popular/tech.html [archive.org]
Same thing, find a way of executing javascript and then have it self-replicate by posting itself all over the site.
That's how IT saved the world. (Score:3, Funny)
Can you imagine the same people in other fields of science?
"...Hey guys, look! I made the black hole generator we were theorizing yesterday! See? I just have to press this button and
Re:That's how IT saved the world. (Score:4, Funny)
Parent
Re:That's how IT saved the world. (Score:4, Funny)
Can you imagine the same people in other fields of science?
"...Hey guys, look! I made the black hole generator we were theorizing yesterday! See? I just have to press this button and
They keep having problems with that black hole generator, just wait until November. [slashdot.org]
Parent
Re:White hat vs Black hat (Score:4, Funny)
What do you think stops black hats from converting? Easy money? Life outside the "norm"?
Sociopathy, perhaps?
Parent
Re: (Score:3)
Well.. this one was posted before on reddit. *laughts*
So.. yea.
Can anyone post the Javascript code here?, Its probabbly some boring use of ajax, but anyway...
Re:Well, that site has a terrible design (Score:4, Informative)
Parent
Re:Is this good news or bad? (Score:5, Insightful)
As a web developer, I beg to differ. There is absolutely no excuse for writing a page that doesn't 'fail gracefully' when javascript isn't present. Let's face it, for every reputable page out there (att.net, youtube.com, etc) there are a hundred others designed by average joe-schmo webprogrammers. And lord only knows if they designed their page securely, and lord only knows if someone has hacked them and injected malicious scripts. I seem to recall hearing a few weeks ago that the majority of malicious scripts were being put into hollywood celebrity gossip sites that people were hitting off their google searches.
For me, the solution is to just whitelist the sites I visit frequently, only allowing scripts/cookies when I know they can be trusted. I'm not saying that you shouldn't design without javascript, but I am saying that you shouldn't assume that everyone visiting your page is going to have it. Besides, how hard is it to write a page that vomits up its contents in a readable form when the javascript doesn't run to position all the css objects? It doesn't have to look pretty, but it should be usable.
Parent
Re: (Score:3, Interesting)
Amen. I've gotten into the habit of structuring the document, outputting the data into readable form, then using CSS and JS to make it look and behave how I want it to.
There are some pages where "no access without javascript" is acceptable - but they are few and far between. For the most part, you should be able to use Lynx and view the content.
Re:Is this good news or bad? (Score:4, Insightful)
There is absolutely no excuse for writing a page that doesn't 'fail gracefully' when javascript isn't present.
Yes there is. Making your page fail gracefully takes extra time and resources, which could be put to better use than supporting the 1% of users who choose to handicap their browsers by turning off javascript.
Failing gracefully is an important concern, but its not the only concern, and should be balanced against other priorities.
Parent
Re: (Score:3, Insightful)
The idea is to build the page in fail-state first, and then use JavaScript to enhance it. Or in other words, build your DOM and then restyle, add event listeners, etc.
It doesn't take extra time, and it's a great technique for future-proofing your pages. It also makes them accessible to people who, for whatever reason, can't take advantage of teh javascript. If your website is in the US, and is big enough for anyone to care, ADA compliance pretty much requires it.
Re: (Score:3, Interesting)
Absolutely right for your personal homepage. A professional web designer would not be able to get away with this. This kind of laziness translations directly into additional support costs for the client. And each time Microsoft recommends turning off Javascript due to a 0-day exploit you are cutting off more than 1%.
I can't think of any cases where it is ok to not fail gracefully. I hope you are not talking about just using client side validation, one of the most used cases for Javascript but where you must
Re: (Score:3, Informative)
Section 501 only applies to government websites, and really, it should apply to crappy screen readers that can't handle javascript.
Re:Is this good news or bad? (Score:5, Insightful)
Any proposal that relies on any group of people to not be idiots is doomed to failure.
Parent
Re:Is this good news or bad? (Score:4, Insightful)
So by advising people to disable Javascript, I'm doing my part for killing off "Web Applications" and getting us back to good old Web Pages. Excellent.
Seriously, why would I want "dynamic content" when all that really means is a thousand pauses as more data is fetched? Give me static pages whenever possible. Better yet, give me a single large static page rather than a dozen small pages, so I don't have to wait while the next page is being loaded and rendered.
The solution is to understand that most web sites are not applications, from the users point of view, and stop stuffing them full of scripts that do nothing but slow things down.
Parent
Re: (Score:3, Funny)
It actually works the same way if you read it forwards.