Absolutely no need for PHP, CGI, frameworks or whatever. The whole thing can be written purely client-side in one file of HTML and JavaScript. Couple hours’ project for a competent person with Notepad.
I use Firefox with NoScript and StumbleUpon. If I stumble a site that does not show any content because it needs javascript, I do not white list it (I do not need to see the dancing pigs), I just go on to the next stumble.
An implementation that does not need client side scripting could reach a larger audience.
It’s NoScript+interested+StumbleUpon. Is StumbleUpon a good way of promoting things? I bet that there is negative correlation between NoScript & StumbleUpon.
Anyhow, JGW’s first claim, that it is a terrible failure mode to produce a blank screen in the absence of js, is true and very cheap to fix.
A large portion of our Firefox users have added the NoScript add-on to their browser. This is one of the top-10 most popular extensions for Firefox. This extension blocks any javascript calls that the user doesn’t approve of. Blocking javascript causes Urchin, Google Analytics, Webtrends, etc to not work. These tracking services never see the traffic because NoScipt blocks it.
You may see a larger difference in reported traffic than with other advertising services because StumbleUpon has a much higher proportion of Firefox users—and in particular, a much larger proportion of people who use browser extensions—than a typical audience. In essence, StumbleUpon’s early-adopter user-base is much more privacy and security conscious than the typical internet user, and they block tracking services as a result.
Nitpick: Such a negative correlation between two Firefox extensions probably only persists in the set of Firefox users, not over Internet users at large, since (inexplicably) Firefox is not overwhelmingly popular among Internet users in general. (It’s possible that it is overwhelmingly popular in the set of people interested in this program, though.)
Turning it off is not “just totally stupid”. For one thing, scripts are sometimes annoying, and most of the web can still be successfully navigated without bothering with them. Turning scripts off can greatly decrease site load times, browser overhead, and network traffic.
For another, you don’t know what sort of user agent the customer is using—there are a lot of browsers for particular accessibility issues or other purposes that do not evenly support Javascript.
Supporting lack of javascript is just plain best practice, based on the principle of progressive enhancement.
Are you aware that with JavaScript, I can get your browser to submit a form to another site you are logged in to, that foolishly only validates sessions by cookies, and the other site will think you wanted to do that, and you would never know it happened?
Knowing this, would you still consider those who don’t want JavaScript enabled when visiting sites they don’t explicitly trust to be stupid?
Cross Site Scripting is the main vulnerability caused by javascript hosted on trusted sites. The problem there is that a hacker has managed to inject javascript onto the page (perhaps by submitting a comment that the server fails to encode for HTML) allowing the script to gather information provided in the version of the page associated with my login, and send that information to the hacker’s server. NoScript does provide some protection against this, but this is by suppressing the methods the injected script uses to report back to the hostile server. It only helps by disabling JavaScript when the injected attack loads a script from a (non white listed) hostile domain.
Cross Site Forgery, on the other hand, is an attack by JavaScript hosted on a random untrusted site I visit, perhaps by Stumbling. NoScript provides excellent protection against this simply by turning of JavaScript.
You can still have XSRF attacks without javascript though… so they are not caused by javascript but facilitated. Harder but doable, and you might protect yourself from some in the wild by turning off javascript.
Reading up about this a bit more it does appear that noscript does help against XSRF even those that don’t use javascript, by changing post requests from untrusted sites to empty gets.
Reading up about this a bit more it does appear that noscript does help against XSRF even those that don’t use javascript, by changing post requests to untrusted sites to empty gets.
Neat. Though I think you meant “changing post requests from untrusted sites to trusted sites to empty gets”, as would be expected to protect against Cross Site Forgery.
I agree with Vladimir Nesov—this is not relevant, and you seem to be using a soldier-argument. Anyway, validating write requests with cookies without auth tokens is plainly wrong, and there are trivial ways to do it right (automatically add auth token to all write forms, read-only forms like search boxes are not affected in any way by CSRF).
And you can do CSRF with “Press button to see kittens” trick, without a single line of Javascript. You can also read browser history with CSS, without Javascript. There aren’t that terribly many security failures that you can do with Javascripts but cannot without, and in any case it’s like using dynamite to deal with mosquitoes—completely disproportional reaction.
Suppose Mallory has identified 100 websites that are vulnerable to high valued Cross Site Forgery attacks. (The administrators of these websites failed to use any of the trivial ways to prevent this. Some users, though they can’t fix the servers, still want to protect themselves.) Is Mallory going to make a site that attempts to entice a user to click a button that apparently won’t do anything, but will actually attempt an attack that will work if the user happens to have an account and be currently logged in to the one targeted site? Or is he going to create a site that has some interesting content that may even entice the user to come back later, that will silently run a script that attempts an attack on every vulnerable site Mallory knows, every time the user visits, without the user having to press any buttons?
You can also read browser history with CSS, without Javascript.
Good to know, though it would have been nice to actually provide a description or a link instead of making me search for it. Though, finding a weakness in my armor does not convince me to abandon my armor which still protects me against many threats. I will consider strengthening my armor. (Unfortunately, it appears the linked extension only supports Firefox 2, but I will see what else I can find.)
I agree with Vladimir Nesov—this is not relevant, and you seem to be using a soldier-argument.
Neither you nor Vladimir have even attempted to identify a single detail about Soldier-Arguments that describes my arguments. I really don’t care about your unsupported opinions that an argument that you happen to disagree with has committed some fallacy.
The weak arguments shouldn’t be used to defend a position. These arguments may lower the other side’s confidence, but they won’t sway the conclusion, and so asking to reconsider the conclusion by giving such arguments is fallacious. It’s also pretty much useless and maybe even misleading, as getting a better idea of the real state of things requires a much more systematic study than a few hand-picked arguments, which are likely to suffer from selection bias anyway.
You don’t defend the statement that a country is economically prosperous by mentioning one successful company.
The weak arguments shouldn’t be used to defend a position.
The argument is not weak. If you think it is, explain why it is weak, why it won’t sway the conclusion.
You don’t defend the statement that a country is economically prosperous by mentioning one successful company.
This is not a good analogy. Malicious hackers will systematically exploit the most dangerous vulnerabilities in a way that the people of a country can not systematically do business with the most successful company.
Keep in mind, I was refuting the assertion that using NoScript is stupid. As thomblake has already explained, any good reason one might have for using NoScript is evidence for my position.
It seems you are using this fact as a soldier-argument. The position under discussion is that all things considered, turning scripting off seems to be a wrong decision. Of course there are potential problems, but at the same time, there are working solutions to these problems, and benefits from actually using the technology.
Such as? The only working solutions I know of are server-side, or disallowing javascript and/or cookies.
The position under discussion is that all things considered, turning scripting off seems to be a wrong decision.
No, the position under discussion is that turning Javascript off is “just totally stupid”. If one can provide good pro tanto reasons for doing so, it is at least not “just totally stupid”.
Disallowing Javascript does NOT protect you against CSRF—“Press button to see kittens” form works without any Javascript. The right solution is server-side—auth tokens for all cookie-validated write forms.
Doing this with server side scripting is crazy. You’d have to submit a zillion forms and take a second to get the answer for each try. This is precisely the sort of thing client-side scripting is meant for.
Of course, the page would explain that it needed JavaScript, if you had JavaScript disabled, not just show a blank page.
Porting the exact behavior of a command line application to a GUI environment like a web page is crazy. Reorganizing the content into a form that fits a new environment makes more sense. For example, the questions to test understanding of awesome sequences can all be part of one form, like in my javascript implementation.
You’d have to submit a zillion forms and take a second to get the answer for each try.
By “a zillion”, do you mean “tens of”? And a second for the form is a lot shorter than the infinite time it takes on a browser that does not support scripting.
This is precisely the sort of thing client-side scripting is meant for.
No, this is precisely the sort of thing client-side scripting is meant to do better on browsers that support it, without interfering with the good enough implementation on browsers that don’t. It most definitely is not meant for the sole means of delivering content that is intended for a wide audience.
Of course, the page would explain that it needed JavaScript, if you had JavaScript disabled, not just show a blank page.
I know I get annoyed quickly when I am asked to enable JavaScript for a purpose that should not need it. It would be better if we could explain that the page will be more responsive with JavaScript.
Absolutely no need for PHP, CGI, frameworks or whatever. The whole thing can be written purely client-side in one file of HTML and JavaScript. Couple hours’ project for a competent person with Notepad.
I use Firefox with NoScript and StumbleUpon. If I stumble a site that does not show any content because it needs javascript, I do not white list it (I do not need to see the dancing pigs), I just go on to the next stumble.
An implementation that does not need client side scripting could reach a larger audience.
The “NoScript” demographic is relatively small, I suspect, but potentially has a lot of overlap with people who might be interested in this.
It’s NoScript+interested+StumbleUpon. Is StumbleUpon a good way of promoting things? I bet that there is negative correlation between NoScript & StumbleUpon.
Anyhow, JGW’s first claim, that it is a terrible failure mode to produce a blank screen in the absence of js, is true and very cheap to fix.
From StumbleUpon’s advertiser FAQ:
Nitpick: Such a negative correlation between two Firefox extensions probably only persists in the set of Firefox users, not over Internet users at large, since (inexplicably) Firefox is not overwhelmingly popular among Internet users in general. (It’s possible that it is overwhelmingly popular in the set of people interested in this program, though.)
I’m all for ignoring the NoScript demographic—JavaScript is one of the basic building blocks of the web, and turning it off is just totally stupid.
Turning it off is not “just totally stupid”. For one thing, scripts are sometimes annoying, and most of the web can still be successfully navigated without bothering with them. Turning scripts off can greatly decrease site load times, browser overhead, and network traffic.
For another, you don’t know what sort of user agent the customer is using—there are a lot of browsers for particular accessibility issues or other purposes that do not evenly support Javascript.
Supporting lack of javascript is just plain best practice, based on the principle of progressive enhancement.
Are you aware that with JavaScript, I can get your browser to submit a form to another site you are logged in to, that foolishly only validates sessions by cookies, and the other site will think you wanted to do that, and you would never know it happened?
Knowing this, would you still consider those who don’t want JavaScript enabled when visiting sites they don’t explicitly trust to be stupid?
Cross site scripting is the main vulnerability caused by javascript, not request forgery.
I use noscript. It helps disable annoying ads.
Cross Site Scripting is the main vulnerability caused by javascript hosted on trusted sites. The problem there is that a hacker has managed to inject javascript onto the page (perhaps by submitting a comment that the server fails to encode for HTML) allowing the script to gather information provided in the version of the page associated with my login, and send that information to the hacker’s server. NoScript does provide some protection against this, but this is by suppressing the methods the injected script uses to report back to the hostile server. It only helps by disabling JavaScript when the injected attack loads a script from a (non white listed) hostile domain.
Cross Site Forgery, on the other hand, is an attack by JavaScript hosted on a random untrusted site I visit, perhaps by Stumbling. NoScript provides excellent protection against this simply by turning of JavaScript.
You can still have XSRF attacks without javascript though… so they are not caused by javascript but facilitated. Harder but doable, and you might protect yourself from some in the wild by turning off javascript.
Reading up about this a bit more it does appear that noscript does help against XSRF even those that don’t use javascript, by changing post requests from untrusted sites to empty gets.
More details can be found on the noscript developers blog,
Editted: Made correction suggested by child post of JGWeismann,
Neat. Though I think you meant “changing post requests from untrusted sites to trusted sites to empty gets”, as would be expected to protect against Cross Site Forgery.
I agree with Vladimir Nesov—this is not relevant, and you seem to be using a soldier-argument. Anyway, validating write requests with cookies without auth tokens is plainly wrong, and there are trivial ways to do it right (automatically add auth token to all write forms, read-only forms like search boxes are not affected in any way by CSRF).
And you can do CSRF with “Press button to see kittens” trick, without a single line of Javascript. You can also read browser history with CSS, without Javascript. There aren’t that terribly many security failures that you can do with Javascripts but cannot without, and in any case it’s like using dynamite to deal with mosquitoes—completely disproportional reaction.
Yes, this is plain stupid.
Suppose Mallory has identified 100 websites that are vulnerable to high valued Cross Site Forgery attacks. (The administrators of these websites failed to use any of the trivial ways to prevent this. Some users, though they can’t fix the servers, still want to protect themselves.) Is Mallory going to make a site that attempts to entice a user to click a button that apparently won’t do anything, but will actually attempt an attack that will work if the user happens to have an account and be currently logged in to the one targeted site? Or is he going to create a site that has some interesting content that may even entice the user to come back later, that will silently run a script that attempts an attack on every vulnerable site Mallory knows, every time the user visits, without the user having to press any buttons?
Good to know, though it would have been nice to actually provide a description or a link instead of making me search for it. Though, finding a weakness in my armor does not convince me to abandon my armor which still protects me against many threats. I will consider strengthening my armor. (Unfortunately, it appears the linked extension only supports Firefox 2, but I will see what else I can find.)
Neither you nor Vladimir have even attempted to identify a single detail about Soldier-Arguments that describes my arguments. I really don’t care about your unsupported opinions that an argument that you happen to disagree with has committed some fallacy.
Why, I agree with the argument. It just isn’t a killer argument that determines the overall decision, and that is the problem with giving it.
Are you serious? We should only ever present arguments that are powerful enough to convince everyone and conclude the discussion?
The weak arguments shouldn’t be used to defend a position. These arguments may lower the other side’s confidence, but they won’t sway the conclusion, and so asking to reconsider the conclusion by giving such arguments is fallacious. It’s also pretty much useless and maybe even misleading, as getting a better idea of the real state of things requires a much more systematic study than a few hand-picked arguments, which are likely to suffer from selection bias anyway.
You don’t defend the statement that a country is economically prosperous by mentioning one successful company.
Think of this in the scientific evidence vs. rational evidence setting. The protocol is there to ensure more reliable performance.
The argument is not weak. If you think it is, explain why it is weak, why it won’t sway the conclusion.
This is not a good analogy. Malicious hackers will systematically exploit the most dangerous vulnerabilities in a way that the people of a country can not systematically do business with the most successful company.
Keep in mind, I was refuting the assertion that using NoScript is stupid. As thomblake has already explained, any good reason one might have for using NoScript is evidence for my position.
It seems you are using this fact as a soldier-argument. The position under discussion is that all things considered, turning scripting off seems to be a wrong decision. Of course there are potential problems, but at the same time, there are working solutions to these problems, and benefits from actually using the technology.
Such as? The only working solutions I know of are server-side, or disallowing javascript and/or cookies.
No, the position under discussion is that turning Javascript off is “just totally stupid”. If one can provide good pro tanto reasons for doing so, it is at least not “just totally stupid”.
Disallowing Javascript does NOT protect you against CSRF—“Press button to see kittens” form works without any Javascript. The right solution is server-side—auth tokens for all cookie-validated write forms.
Doing this with server side scripting is crazy. You’d have to submit a zillion forms and take a second to get the answer for each try. This is precisely the sort of thing client-side scripting is meant for.
Of course, the page would explain that it needed JavaScript, if you had JavaScript disabled, not just show a blank page.
Porting the exact behavior of a command line application to a GUI environment like a web page is crazy. Reorganizing the content into a form that fits a new environment makes more sense. For example, the questions to test understanding of awesome sequences can all be part of one form, like in my javascript implementation.
By “a zillion”, do you mean “tens of”? And a second for the form is a lot shorter than the infinite time it takes on a browser that does not support scripting.
No, this is precisely the sort of thing client-side scripting is meant to do better on browsers that support it, without interfering with the good enough implementation on browsers that don’t. It most definitely is not meant for the sole means of delivering content that is intended for a wide audience.
I know I get annoyed quickly when I am asked to enable JavaScript for a purpose that should not need it. It would be better if we could explain that the page will be more responsive with JavaScript.