Recessions are bad for morale, and bad morale means that the people are more likely to take an interest in those doing the governing. It makes sense for our absurd two-party system to play hot-potato with the recession. Put it off as long as possible, and hope that your party isn't in control when it hits.
Of course, informed people realize that recessions are a natural part of the economy. I guess it sucks to be born into one, but thems the breaks, right?
As far as I can tell, that's the only solution that doesn't rely on Javascript shenanigans, but it doesn't really stop it. All it does is reduce the problem to a cryptographic attack -- which is subject to brute force.
The token should have a very short lifetime. If the attacker can brute-force the token before it expires, yes, they'll win, but correctly-implemented, that should not happen.
I think that you're thinking of CSS or other code injection, not CSRF. CSRF relies on a user being authenticated to another site (a bank, for instance) which allows you to visit a specially crafted URL to perform an action. For example, this URL might transfer money between accounts: http://mybank.example.com/transfer?amount=3000.00&sourceAcct=00001&destinationAcct=10001 The attacker just needs to get the user to visit that URL in any way, perhaps with a bit of javascript on a malicious site, or with a refresh, or through some trickery which involves action on the user's part. Note that some of these ways merely require that the user visit the bad guy's site. Note also that spam with this URL will be going to the bank site, which means that the user may be off-guard if they're only paying attention to the host part of the URL.
If I'm logged into my bank, and I own acct 00001, I will have transferred 3000 units of currency to account 10001. Using POST makes this harder--it requires a bit of Javascript--but it's may still be possible.
The solution involves tracking user actions and ensuring that the user pressed the button which performs the above action. Generally speaking, this is done using a technique called double-cookie submission--where a token cookie is passed from the server to the client and back on every page along with the user's session information. If the token cookie (which must change with each new page) matches, the site will trust that the user is performing that action.
The "get" method should be used when the form is idempotent (i.e., causes no side-effects). Many database searches have no visible side-effects and make ideal applications for the "get" method.
If the service associated with the processing of a form causes side effects (for example, if the form modifies a database or subscription to a service), the "post" method should be used.
Redirects are evil. They make it harder to use your back button, they may work differently in different browsers, and if the user does go back, they'll re-submit the request to add, delete, whatever, which may have unpredictable results or cause user-confusion.
Storing the session-ID in the URL is just generally a bad practice, and should be avoided when possible. Session-IDs in the URL opens your site up to a session-guessing attack if your session-ID generation algorithm is ever found to generate guessable sessions (e.g. the attacker knows that session 2381909-03802 is coming up, and so spams that URL to millions of people. The first hundred who click on the link don't get that session, but eventually someone probably will.) Even if you're only sending the session for a few of your URLs, the danger exists.
Double-cookie submission is a well known and understood pattern for preventing CSRF. Right now, it's the best way to prevent problems.
I'd forgotten about that one, but yes, that bugs me, too. It's slightly less irritating to me since Javascript doesn't explicitly declare an Associative Array object. But they do declare an Array object, so it seems to me that the typeof should return 'array' just like it does for strings, dates, etc.
In reality security is a process and their processes are obviously broken. No person (no matter whether it is the one who set up their network or not) should be allowed to just go pick up a router and sell it on eBay. If they feel a need to cash in on their old hardware then there must be a clear process for that which includes "make really sure that all sensitive data is wiped from any device you intend to sell".
Of course it's a process, but it's a human process. Mistakes are made. Repeat mistakes of this nature should absolutely be a grounds for termination. Yet for some reason, commentators on Internet forums insist on dehumanizing the entire process and calling for the head of anyone who slips up.
Want to know what probably happened? A bunch of equipment was being replaced, and the rest trashed. Someone knew this and grabbed some of it to sell on eBay, hoping to make a quick quid. The devices were probably already off of inventory by this time, so no one was the wiser, but the guy (or girl) who took the equipment didn't know about the security procedure.
I base that off of my understanding of Cisco contracts. A friend works for a company which uses Cisco gear. In the contract, they are supposed to destroy most of the gear they get from Cisco (after it's no longer in use), and in return, they get discounts on replacements. They're subject to various financial penalties (not the least of which is the cessation of the discount) if any employees are found to have sold equipment on the secondary market. The idea is that Cisco doesn't want to flood the market with old gear that's still perfectly serviceable, but they don't want to take the time to refurbish it or destroy it themselves.
I could easily see something similar being the case here.
And this is just one of many reasons why passwords should not be recoverable from devices like this. On a general purpose computer, it's hard to prevent, but I bet that it's nontrivial to modify the software on that device to give up the password.
Fascinating. Microsoft finally gets something right (reverse engineering correctly) and in the process, they manage to copy a bug.
Thanks for the lesson.
You know, I had a well-reasoned, civil responses to most of your post. Then I got to this:
null.typeof returns 'object'. So does Array.typeof. That's just... dumb.
So's your face.
And I realized that you're just being a dick. Call me back if you want to have a real discussion on the merits of Javascript as a language. Until then, go to hell.
Arguments over the use of "this" aside, I guess that strong vs. weak typing is somewhat subjective. Wikipedia implies that there's plenty of debate and wiggle-room over what qualifies as a strongly typed language. There's enough implicit casting in the language for me to consider it weakly typed. In fact, this was a design decision so that Javascript would be easy to use for non-programmers.
I guess that it depends upon your definition of "buggy." You can design a language where the Integer object has a destructor named "toString" if you want to. And if someone did that, I would consider the design to be broken.
That's an extreme case, but it illustrates the point. Javascript takes common programming paradigms, structure, and syntax, and turns them on their heads. It would be nice if the designers had chosen to make Javascript look a little less C-like, but I suppose that it might not have gotten widespread adoption (despite mostly being used incorrectly due to the syntax).
The real key is that in Javascript, you can say that you want something, and you get something different from what you want. I'm harping on the typeof "bug" because it's the most obvious. I have an object of type Array. I ask Javascript for the typeof that object. I get returned object. Ok. I have an object of type Integer. I ask Javascript for the typeof that object. I get returned Integer. The lack of internal consistency there should be considered a bug.
Nearly every gripe with Javascript stems from the first and last items on your list. 99% of the javascript I come across is written as if it is C, which causes all sorts of confusion with scope and efficiency.
Yes, and I think it's a bad design to model the statements of a language against a different language, but completely change the semantics. An extreme example would be using the '+' symbol for subtraction.
But I don't think that the typeof issues I mentioned are fundamental to functional programming languages. And I don't think that reusing bad design (===) excuses the language just because "Javascript is not alone."
Other languages with tons of theoretical cred share the newline/semicolon problems (Haskell, for example).
I haven't seen many other languages do this, but I still think it's a bad design. I'm sure that every programmer occasionally drops a semi-colon, and when they do, whitespace may be a significant factor in how the statement is interpreted. Good languages can have crappy features.
If more programmers understood functional idioms, Javascript wouldn't have such a bad reputation.
Even within the context of a functional language, I think that Javascript has some design problems that aren't going to go away (at least) due to legacy. A functional language can still return a useful type when you ask for it. A functional language does not have to have implicit semi-colons. A functional language can use different identifiers instead of three contextually different uses of 'this'.
The programming language itself has many, many problems.
It's a fully functional language which uses a syntax almost identical to C.
It implements the awful === operator.
Boolean values can be True, False, Undefined, or Null (this is a side effect of being weakly typed)
It tries to be easy to program by assuming end-of-statement operators (';') at certain places if the function wouldn't otherwise parse. This makes it incredibly difficult to debug. I truly consider this a bug in the design.
It's a weakly typed language with a strong understanding of type. By this, I mean that any variable is actually a reference which can hold values of any type (though they're all just objects anyway.) This isn't so much a bug as a design decision, but it's important for understanding the below--
null.typeof returns 'object'. So does Array.typeof. That's just... dumb.
The object which 'this' references has several different meanings depending upon the context.
So those are only a few of the issues. It feels like it's trying to be several different languages all at once. Coupled with the issues above (particularly the inconsistent use of 'this' and the implicit semi-colons), well frankly, if any design could be considered buggy, I'd say that it's Javascript's.
Yeah, what a great idea that was. Let's give away scanners, and then people can scan a barcode and be taken to a website, so its ad supported. Problem was, to get that barcode, you pretty much had to own the item, at which time, you were like, um, what is the point of researching the item AFTER you buy it. Kind of a gimick.
You missed the point. Cuecats were given away with Radio Shack catalogs, which included the bar code for almost every item listed. In a way, it acted as a bridge between old mail-order (catalogs) and e-commerce. They were never intended to be used with anything else (even already purchased items, as they wouldn't read standard barcodes), and I think that there were even some takedown notices regarding the various hacks, at first.
Abortion being wrong, abortion being a necessary evil to prevent more deaths, and the united states government having a right to dictate to women what they can and can't do to their own bodies are three totally separate issues.
At the risk of turning this into a debate about abortion, two of these are at odds.
Generally speaking, I'm allowed to do what I want with my body until I start harming another human being. That means I can thrust my fist out in front of me all that I want, right up until the point that someone is standing within arms readch in front of me.
Similarly, a woman can also do whatever she wants with her body, until she starts affecting another human being. The obvious question, then, is whether or not the fetus is a human being. It's a question with a high philosophical component. The Catholic Church says that it is a human, and therefore, killing it is murder. As such, I still hold that Biden is an example of a politician whose public policy indicates significant disagreement with statements issued by the Pope.
All that said, I'm well aware that there are other situations where the US government says that taking another human life is acceptable. Self defense is one. As a court-ordered punishment is another. I've always found it quite interesting that ultra right wing conservatives can be simultaneously in favor of the death penalty, but against abortion (because all life is precious, don't you know.)
The Pope also says that evolution and the Bible are not at odds. Many politicians claim to disagree. The Pope also says that abortion is wrong. Joe Biden (candidate for the Office of the Vice President of the United States, and a Catholic, even) disagrees.
The labels don't want any one distributor to become too big, lest they start making "unreasonable" demands. As long as they can threaten the stores with taking their business elsewhere, they maintain some amount of leverage. Thus, it makes sense to play distributors against each other as much as possible. One way to do that is to ensure that neither carries the full catalog in comparable formats.
Seems like a pain to have to reboot to play games... but I guess I already do that between Debian/Windows.:-/
That's not how I'd use it. Most of the time, I have my notebook plugged into an outlet, so I'd just use the power-hungry card. I'd reboot any time I plan on using the machine away from an outlet for an extended period of time.
A reasonable person, or the average person? I don't think that the average person is reasonable.
The average person cares about having the newest car, the newest TV, a house they can't afford, etc. They want to keep up with the Joneses. They measure their own worth as relative to other people's possessions. Their own happiness depends upon being "better" than other people. That's not reasonable. That's why the American economy is in the mess that it's in. We're a society where the goal is to attain money any way you can. If you don't, you're a failure.
It's not like Microsoft was open to developers out of the goodness of their hearts. Being open and and easily accessible goes a long way towards market dominance, though it obviously does not guarantee it. Look at Microsoft in the early years--piracy was rampant, and they basically looked the other way most of the time. It was only after their market share surged that they started cracking down. Today, we have online activation required.
They're not even as open to developers today as they once were. Microsoft is slowly moving to requiring signed binaries for device drivers. How long until they require it for user-mode drivers, and then user-mode programs? Maybe never, as Apple is slowly regaining some market share, but if they hadn't, I bet that's where we'd be going.
Microsoft wants total control--they're just patient. They realize that you first have to get people tied to your platform, and then you can start calling all the shots.
Ever programmed in Objective C? It's really an elegant design, and most developers seem to have no problem adjusting to it. Rather than thinking that it's unfortunate that Apple chose such an uncommon language for development, I think that it's unfortunate that Objective C hasn't gotten more acceptance outside of Apple.
Slashdot Mirror
Recessions are bad for morale, and bad morale means that the people are more likely to take an interest in those doing the governing. It makes sense for our absurd two-party system to play hot-potato with the recession. Put it off as long as possible, and hope that your party isn't in control when it hits.
Of course, informed people realize that recessions are a natural part of the economy. I guess it sucks to be born into one, but thems the breaks, right?
As far as I can tell, that's the only solution that doesn't rely on Javascript shenanigans, but it doesn't really stop it. All it does is reduce the problem to a cryptographic attack -- which is subject to brute force.
The token should have a very short lifetime. If the attacker can brute-force the token before it expires, yes, they'll win, but correctly-implemented, that should not happen.
I think that you're thinking of CSS or other code injection, not CSRF. CSRF relies on a user being authenticated to another site (a bank, for instance) which allows you to visit a specially crafted URL to perform an action. For example, this URL might transfer money between accounts:
http://mybank.example.com/transfer?amount=3000.00&sourceAcct=00001&destinationAcct=10001 The attacker just needs to get the user to visit that URL in any way, perhaps with a bit of javascript on a malicious site, or with a refresh, or through some trickery which involves action on the user's part. Note that some of these ways merely require that the user visit the bad guy's site. Note also that spam with this URL will be going to the bank site, which means that the user may be off-guard if they're only paying attention to the host part of the URL.
If I'm logged into my bank, and I own acct 00001, I will have transferred 3000 units of currency to account 10001. Using POST makes this harder--it requires a bit of Javascript--but it's may still be possible.
The solution involves tracking user actions and ensuring that the user pressed the button which performs the above action. Generally speaking, this is done using a technique called double-cookie submission--where a token cookie is passed from the server to the client and back on every page along with the user's session information. If the token cookie (which must change with each new page) matches, the site will trust that the user is performing that action.
w3c disagrees with you:
The "get" method should be used when the form is idempotent (i.e., causes no side-effects). Many database searches have no visible side-effects and make ideal applications for the "get" method.
If the service associated with the processing of a form causes side effects (for example, if the form modifies a database or subscription to a service), the "post" method should be used.
From http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13.1
Redirects are evil. They make it harder to use your back button, they may work differently in different browsers, and if the user does go back, they'll re-submit the request to add, delete, whatever, which may have unpredictable results or cause user-confusion.
Storing the session-ID in the URL is just generally a bad practice, and should be avoided when possible. Session-IDs in the URL opens your site up to a session-guessing attack if your session-ID generation algorithm is ever found to generate guessable sessions (e.g. the attacker knows that session 2381909-03802 is coming up, and so spams that URL to millions of people. The first hundred who click on the link don't get that session, but eventually someone probably will.) Even if you're only sending the session for a few of your URLs, the danger exists.
Double-cookie submission is a well known and understood pattern for preventing CSRF. Right now, it's the best way to prevent problems.
I'd forgotten about that one, but yes, that bugs me, too. It's slightly less irritating to me since Javascript doesn't explicitly declare an Associative Array object. But they do declare an Array object, so it seems to me that the typeof should return 'array' just like it does for strings, dates, etc.
In reality security is a process and their processes are obviously broken. No person (no matter whether it is the one who set up their network or not) should be allowed to just go pick up a router and sell it on eBay. If they feel a need to cash in on their old hardware then there must be a clear process for that which includes "make really sure that all sensitive data is wiped from any device you intend to sell".
Of course it's a process, but it's a human process. Mistakes are made. Repeat mistakes of this nature should absolutely be a grounds for termination. Yet for some reason, commentators on Internet forums insist on dehumanizing the entire process and calling for the head of anyone who slips up.
Want to know what probably happened? A bunch of equipment was being replaced, and the rest trashed. Someone knew this and grabbed some of it to sell on eBay, hoping to make a quick quid. The devices were probably already off of inventory by this time, so no one was the wiser, but the guy (or girl) who took the equipment didn't know about the security procedure.
I base that off of my understanding of Cisco contracts. A friend works for a company which uses Cisco gear. In the contract, they are supposed to destroy most of the gear they get from Cisco (after it's no longer in use), and in return, they get discounts on replacements. They're subject to various financial penalties (not the least of which is the cessation of the discount) if any employees are found to have sold equipment on the secondary market. The idea is that Cisco doesn't want to flood the market with old gear that's still perfectly serviceable, but they don't want to take the time to refurbish it or destroy it themselves.
I could easily see something similar being the case here.
And this is just one of many reasons why passwords should not be recoverable from devices like this. On a general purpose computer, it's hard to prevent, but I bet that it's nontrivial to modify the software on that device to give up the password.
Yeah, someone screwed up, but that someone was a person, and not necessarily the same person who set up the other security measures.
I seem to remember Nintendo saying that about a certain other new system back in 2004.
Yeah, but they were hedging their bets. The system came with a game demo, and almost every launch title for the system was clearly a game.
Fascinating. Microsoft finally gets something right (reverse engineering correctly) and in the process, they manage to copy a bug. Thanks for the lesson.
null.typeof returns 'object'. So does Array.typeof. That's just ... dumb.
So's your face.
And I realized that you're just being a dick. Call me back if you want to have a real discussion on the merits of Javascript as a language. Until then, go to hell.
Arguments over the use of "this" aside, I guess that strong vs. weak typing is somewhat subjective. Wikipedia implies that there's plenty of debate and wiggle-room over what qualifies as a strongly typed language. There's enough implicit casting in the language for me to consider it weakly typed. In fact, this was a design decision so that Javascript would be easy to use for non-programmers.
I guess that it depends upon your definition of "buggy." You can design a language where the Integer object has a destructor named "toString" if you want to. And if someone did that, I would consider the design to be broken.
That's an extreme case, but it illustrates the point. Javascript takes common programming paradigms, structure, and syntax, and turns them on their heads. It would be nice if the designers had chosen to make Javascript look a little less C-like, but I suppose that it might not have gotten widespread adoption (despite mostly being used incorrectly due to the syntax).
The real key is that in Javascript, you can say that you want something, and you get something different from what you want. I'm harping on the typeof "bug" because it's the most obvious. I have an object of type Array. I ask Javascript for the typeof that object. I get returned object. Ok. I have an object of type Integer. I ask Javascript for the typeof that object. I get returned Integer. The lack of internal consistency there should be considered a bug.
Nearly every gripe with Javascript stems from the first and last items on your list. 99% of the javascript I come across is written as if it is C, which causes all sorts of confusion with scope and efficiency.
Yes, and I think it's a bad design to model the statements of a language against a different language, but completely change the semantics. An extreme example would be using the '+' symbol for subtraction. But I don't think that the typeof issues I mentioned are fundamental to functional programming languages. And I don't think that reusing bad design (===) excuses the language just because "Javascript is not alone."
Other languages with tons of theoretical cred share the newline/semicolon problems (Haskell, for example).
I haven't seen many other languages do this, but I still think it's a bad design. I'm sure that every programmer occasionally drops a semi-colon, and when they do, whitespace may be a significant factor in how the statement is interpreted. Good languages can have crappy features.
If more programmers understood functional idioms, Javascript wouldn't have such a bad reputation.
Even within the context of a functional language, I think that Javascript has some design problems that aren't going to go away (at least) due to legacy. A functional language can still return a useful type when you ask for it. A functional language does not have to have implicit semi-colons. A functional language can use different identifiers instead of three contextually different uses of 'this'.
So those are only a few of the issues. It feels like it's trying to be several different languages all at once. Coupled with the issues above (particularly the inconsistent use of 'this' and the implicit semi-colons), well frankly, if any design could be considered buggy, I'd say that it's Javascript's.
Yeah, what a great idea that was. Let's give away scanners, and then people can scan a barcode and be taken to a website, so its ad supported. Problem was, to get that barcode, you pretty much had to own the item, at which time, you were like, um, what is the point of researching the item AFTER you buy it. Kind of a gimick.
You missed the point. Cuecats were given away with Radio Shack catalogs, which included the bar code for almost every item listed. In a way, it acted as a bridge between old mail-order (catalogs) and e-commerce. They were never intended to be used with anything else (even already purchased items, as they wouldn't read standard barcodes), and I think that there were even some takedown notices regarding the various hacks, at first.
Abortion being wrong, abortion being a necessary evil to prevent more deaths, and the united states government having a right to dictate to women what they can and can't do to their own bodies are three totally separate issues.
At the risk of turning this into a debate about abortion, two of these are at odds.
Generally speaking, I'm allowed to do what I want with my body until I start harming another human being. That means I can thrust my fist out in front of me all that I want, right up until the point that someone is standing within arms readch in front of me.
Similarly, a woman can also do whatever she wants with her body, until she starts affecting another human being. The obvious question, then, is whether or not the fetus is a human being. It's a question with a high philosophical component. The Catholic Church says that it is a human, and therefore, killing it is murder. As such, I still hold that Biden is an example of a politician whose public policy indicates significant disagreement with statements issued by the Pope.
All that said, I'm well aware that there are other situations where the US government says that taking another human life is acceptable. Self defense is one. As a court-ordered punishment is another. I've always found it quite interesting that ultra right wing conservatives can be simultaneously in favor of the death penalty, but against abortion (because all life is precious, don't you know.)
The Pope also says that evolution and the Bible are not at odds. Many politicians claim to disagree. The Pope also says that abortion is wrong. Joe Biden (candidate for the Office of the Vice President of the United States, and a Catholic, even) disagrees.
EndNote does one thing [citation management] well.
[citation needed]
The labels don't want any one distributor to become too big, lest they start making "unreasonable" demands. As long as they can threaten the stores with taking their business elsewhere, they maintain some amount of leverage. Thus, it makes sense to play distributors against each other as much as possible. One way to do that is to ensure that neither carries the full catalog in comparable formats.
Seems like a pain to have to reboot to play games... but I guess I already do that between Debian/Windows. :-/
That's not how I'd use it. Most of the time, I have my notebook plugged into an outlet, so I'd just use the power-hungry card. I'd reboot any time I plan on using the machine away from an outlet for an extended period of time.
A reasonable person, or the average person? I don't think that the average person is reasonable.
The average person cares about having the newest car, the newest TV, a house they can't afford, etc. They want to keep up with the Joneses. They measure their own worth as relative to other people's possessions. Their own happiness depends upon being "better" than other people. That's not reasonable. That's why the American economy is in the mess that it's in. We're a society where the goal is to attain money any way you can. If you don't, you're a failure.
Reasonable? My ass.
It's not like Microsoft was open to developers out of the goodness of their hearts. Being open and and easily accessible goes a long way towards market dominance, though it obviously does not guarantee it. Look at Microsoft in the early years--piracy was rampant, and they basically looked the other way most of the time. It was only after their market share surged that they started cracking down. Today, we have online activation required.
They're not even as open to developers today as they once were. Microsoft is slowly moving to requiring signed binaries for device drivers. How long until they require it for user-mode drivers, and then user-mode programs? Maybe never, as Apple is slowly regaining some market share, but if they hadn't, I bet that's where we'd be going.
Microsoft wants total control--they're just patient. They realize that you first have to get people tied to your platform, and then you can start calling all the shots.
Ever programmed in Objective C? It's really an elegant design, and most developers seem to have no problem adjusting to it. Rather than thinking that it's unfortunate that Apple chose such an uncommon language for development, I think that it's unfortunate that Objective C hasn't gotten more acceptance outside of Apple.
I've been looking. The best I can find quickly is this article on ibm.com:
http://www.ibm.com/developerworks/web/library/wa-cranky29.html
Search for "refuse to carry"