Land is a finite commodity. If everyone got the same amount, there would only be about 5 acres of land available per person today.
It might not be fair to the teacher to have to pay high taxes on the land, but it's not fair to society to let him keep it for no/low cost when it might be put to better, more productive use for society by someone else.
If he can't afford it, let him sell it to someone who can. If there's no incentive for people to make productive use of capital, the economy stagnates.
While it's true that it's much better to follow the RFC here, just switching to POST doesn't solve the CSRF problem. An attacker could set up a malicious Web page which has a form with all the necessary parameters and a JavaScript to automatically submit it, hence meeting the POST requirement. Similarly, if the client has an older version of Flash or a buggy version which does not obey same-source security principles, the attacker could embed a malicious SWF which creates the entire HTTP request from scratch, even forging the Referer header if you were checking that as a security measure.
This is another good reason for using Firefox extensions such as Flashblock and Noscript. As a client, you can protect yourself pretty easily from a lot of these attacks. Noscript also has some nice features which help filter out the more common brands of XSS attacks.
Hence the reason to disable remote 3rd party images in your browser of choice (e.g. Firefox) and never click on 3rd party URLs. See also the Netflix CSRF vulnerability that allowed an attacker to add a movie to a user's queue, move it to the top of the list, and change the shipping address for the user to his own to get free movies. Who here checks the box to stay logged into Netflix? Note that the "add movie to queue" portion still hasn't been fixed.
There may be a lot of comments saying CSRF is so 20006. Well, yes, that is true, but Grossman is probably right in that this year will be a big year for reporting the vulnerabilities (also known as session riding), because almost no Web site has any CSRF protections.
The only thing about a plug-in hybrid that makes more sense than a pure EV is allowing for longer ranges. Why carry around TWO motors and energy storage systems when you can drop all of the weight of one of the systems and use the more efficient one exclusively? Yes, a longer range vehicle is necessary for certain uses, but not for the vast majority of daily commutes. This is of course a pure energy costs comparison. Actual monetary costs may be much closer depending on the amount of long-distance trips required.
Compressed air is not really viable now and is not likely to be viable any time soon. The top speed of a conventional air-powered vehicle is around 60MPH. It takes roughly 7 times as much energy to compress the air required to provide enough power at the wheel as it does to charge the battery of an electric motor to provide the same amount of power at the wheel. The closer a compressed-air container gets to capacity, the more incremental energy it takes to further compress air in the cylinder.
Even if not enough people wanted the cars for GM to continue to produce EV1s, it makes no sense for GM to refuse to sell the cars to the lessee's who BEGGED to buy them and instead crush them; GM could have at least made some of their investment back instead of spending MORE money to haul away the cars and crush them. There was a larger agenda at play than just "not enough people wanted them". If GM was so worried about "subsidizing the ownership" via replacement parts, they could have just offered to bump of the price to make up these costs, which by the way are negligible for electric cars. GM wouldn't even entertain the offers. Really, are you seriously arguing that the millions of dollars offered by the EV1 lessees wouldn't have covered the costs of their legal obligations to the owners to maintain the cars?
You don't even address point 3. GM promised not to crush the cars, then crushed them. The parent wasn't talking about figurative crushing of the EV1 program.
I don't even know what to say to your response to point 5. What exactly is it about California emissions standards that affects other states adversely? How exactly did California "kill" diesel in the US?
It takes a whole lot more training to learn how to service a modern ICE than a simple electric drive train. Different skills, yes. Skills that could be learned from a 50-page training manual, yes. GM could have paid any mechanic $15/hour off the street to service an EV1.
The EV1 absolutely fit the lives of the majority of drivers. It was a marketing failure on the part of GM that was the problem in that regard. GM did the opposite of marketing by actually emphasizing to its customers that the 100-mile range would be an inconvenience when in reality for most people it wouldn't be.
I'm not suggesting that GM is entirely to blame for the mid-90's death of the electric car, and neither was the director of Who Killed the Electric Car? In fact, the director does blame the consumer, in part. However, you have not shown that the points made by the parent have been discounted at all, let alone mostly discounted.
The problem with compressed air is that the energy density is even worse than batteries. Plus, as you approach capacity, the incremental energy required to add more energy to the tank increases exponentially. Converting the air pressure directly to motive power will always be more efficient than converting the energy to electrical then to motive power. Compressed air is inefficient to produce, dangerous to store, and low energy density. It is not currently a viable alternative.
While I certainly agree that you're not making up your $50k on the cost of gasoline anytime soon, you mention incorrectly that the Tesla is going to cost more in maintenance. There is only one moving part in the Telsa motor. No oil changes, no muffler maintenance, spark plugs, etc. etc. etc. Yes, you do have to look into a new battery at some point, but at the 10-year mark you're only down to 50-80% of the original battery life, and by that point the battery technology will be cheaper and better anyway. Possibly supercapacitors will be viable. Subtract out tires and brakes, then tell me that the maintenance of an ICE-based vehicle isn't going to cost you in the neighborhood of $5-$10k (replacement battery cost) over 10 years.
Given its performance, it actually is a very cost-effective sports car. You're not going to find a 4-second 60 for much cheaper than $100k anywhere. The top speed of the Tesla really isn't anything special, but when was the last time you pushed 120 on public roads?
The current high price tag is in large part due to the cost of development. Assuming Tesla gets its technologies and production capacity up to a reasonably large scale, that cost is going to come down quite a bit.
There is not enough available surface on the Roadster to gain even a nominal addition to the range by adding solar panels. Even the car referenced by the parent gains only an additional 20 miles per day with full sun exposure. Current (no pun intended) electric technologies simply do not support an electric car with a 300+ mile daily range. However, that is not to say that an electric car does not make sense for a daily commute. Your solar dollars are better invested in solar plants and static rooftop collectors than installing them on vehicles.
There seems to be a lot of confusion about how this works. You need to understand two things to understand the GHH - first what a 'Google Hack' is in the first place, and second how to create a honeypot to record malicious behavior.
First, a quick summary of Google hacking: Google obviously has a huge cache of URLs. If a vulnerability is published that can be identified by a URI string, then you can simple Google that URI to identify vulnerable hosts. The GHH main page has a list of the current vulnerability signatures that it tracks.
In order to make a honeypot for this malicious behavior, you simply have to set up a Web server to respond appropriately to each of these linked URLs and have it be indexed by Google (not a trival task, but still quite doable). You can then track referring requests from Google by IP address, etc...
In order to defeat this type of tracking, an attacker could strip off the Referer header using an automated tool or a proxy, then route through an Onion router or some other anonymous proxy, but at least the server would still have some metrics to identify the relative freqency of attackers reaching the site through a "Google Hack."
Credit card fraud is not a technical problem. Using the old adage, we cannot apply a technical solution. All of the extra verification proposed implies an added cost that will still not solve the problem - if you require a passphrase or some secondary authentication, thieves will just steal the second factor as well.
The best solution is to shift the responsibility for fraud to those that are responsible for allowing it - the merchants who process card transactions. This is how it is already done, and the fact that plenty of merchants still do business with credit cards proves that the system works, despite the fact that CC companies don't "give a shit."
As a consumer, I'd be perfectly fine with everyone knowing my credit card number because I'm not responsible for fraudulent purchases by law. This is a system that works.
What you should really be upset about it is the system that allows identity theft to run rampant. Though the two are related, there is a fundamental difference between someone else using a credit card you've established in your name and someone else using a credit card that they've established in your name.
The current system is much weaker against this type of activity because the burden of responsibility for fraud is still heavily on the consumer rather than the parties that allow identity theft to be profitable (mainly banks, but to a lesser extent any industry that relies on credit reporting). The solution to this problem is not so clear.
I can't tell if this was supposed to be a joke post or not (apparently the moderators thought so). Assuming you were serious...
Other posters already mentioned the possibility that the anchor text was different from the anchor URL. There are a number of ways that can be accomplished, from blindingly obvious to somewhat subtle. I have seen attacks that take advantage of a bug in IE: If you wrap an anchor tag around an image map, IE displays the URL for the anchor tag, but takes you to the map address when you click the image.
Another possibility is that the link was encoded using an alternate character set. The actual bytes of the string paypal.com can be totally different in UTF-7, UTF-8, etc...
The attackers might have delivered a malicious hosts file to your machine through some other security hole that maps that domain to the attacker's IP.
The example they use is where some secretary gets her boss to sign a document, and then uses his signature on another document which gives her access she shouldn't have. It's a way to forge a digital signature on a document by having them sign another one that you specially crafted.
This is imprecise and can be interpreted in horribly incorrect ways.
The example they use involves a secretary giving a document to her boss in order that he will sign the hash of that document. Beforehand the secretary has prepared another nearly identical document with the same exact hash value that is nevertheless rendered differently by PostScript. She then presents this other document and the boss's signature of the hash of that document, which is identical, in order to gain security clearance that she doesn't have.
Any hash algorithm with computable collisions is vulnerable to this attack. This research is not so important from the perspective that an MD5 collision was found (because this has already been shown several times by other researchers), but that we have to be careful about how we use hash functions.
It should be obvious that we should not simply sign the hash of just any data that comes across our desk - we need to make sure we are absolutely convinced that it is safe to sign that hash because we have fully vetted the contents of the file. In this case, Caesar should have looked at the contents of the.ps file (which contains functional code) to see that it also contained an authorization for Alice to view secret documents. Then he should have fed her to the lions.
The reason why this works is that they are taking advantage of the length-extension property of the hash. This means that if any two documents have the same hash, adding the same bits to the end of the two documents will also have the same hash.
If you really wanted to spread the FUD, you could say that the researchers have published a univeral adapter for MD5 exploits simply by providing two distinct pieces of data with the same hash - a hash collision. With these two pieces of data, you could create ANY two files that could behave differently (executable files, HTML files with JavaScript, Word Documents with macros, etc...) depending on the value of these two colliding pieces of data. You would just need to make sure that both files were identical except for the two sections with the hash collisions. This, in fact, has already been done by previous researchers. The examples are referenced by the authors for EXE files and certificates.
Slashdot Mirror
Land is a finite commodity. If everyone got the same amount, there would only be about 5 acres of land available per person today.
It might not be fair to the teacher to have to pay high taxes on the land, but it's not fair to society to let him keep it for no/low cost when it might be put to better, more productive use for society by someone else.
If he can't afford it, let him sell it to someone who can. If there's no incentive for people to make productive use of capital, the economy stagnates.
While it's true that it's much better to follow the RFC here, just switching to POST doesn't solve the CSRF problem. An attacker could set up a malicious Web page which has a form with all the necessary parameters and a JavaScript to automatically submit it, hence meeting the POST requirement. Similarly, if the client has an older version of Flash or a buggy version which does not obey same-source security principles, the attacker could embed a malicious SWF which creates the entire HTTP request from scratch, even forging the Referer header if you were checking that as a security measure.
This is another good reason for using Firefox extensions such as Flashblock and Noscript. As a client, you can protect yourself pretty easily from a lot of these attacks. Noscript also has some nice features which help filter out the more common brands of XSS attacks.
Hence the reason to disable remote 3rd party images in your browser of choice (e.g. Firefox) and never click on 3rd party URLs. See also the Netflix CSRF vulnerability that allowed an attacker to add a movie to a user's queue, move it to the top of the list, and change the shipping address for the user to his own to get free movies. Who here checks the box to stay logged into Netflix? Note that the "add movie to queue" portion still hasn't been fixed.
There may be a lot of comments saying CSRF is so 20006. Well, yes, that is true, but Grossman is probably right in that this year will be a big year for reporting the vulnerabilities (also known as session riding), because almost no Web site has any CSRF protections.
The only thing about a plug-in hybrid that makes more sense than a pure EV is allowing for longer ranges. Why carry around TWO motors and energy storage systems when you can drop all of the weight of one of the systems and use the more efficient one exclusively? Yes, a longer range vehicle is necessary for certain uses, but not for the vast majority of daily commutes. This is of course a pure energy costs comparison. Actual monetary costs may be much closer depending on the amount of long-distance trips required.
Compressed air is not really viable now and is not likely to be viable any time soon. The top speed of a conventional air-powered vehicle is around 60MPH. It takes roughly 7 times as much energy to compress the air required to provide enough power at the wheel as it does to charge the battery of an electric motor to provide the same amount of power at the wheel. The closer a compressed-air container gets to capacity, the more incremental energy it takes to further compress air in the cylinder.
Mostly has been discounted by whom?
Even if not enough people wanted the cars for GM to continue to produce EV1s, it makes no sense for GM to refuse to sell the cars to the lessee's who BEGGED to buy them and instead crush them; GM could have at least made some of their investment back instead of spending MORE money to haul away the cars and crush them. There was a larger agenda at play than just "not enough people wanted them". If GM was so worried about "subsidizing the ownership" via replacement parts, they could have just offered to bump of the price to make up these costs, which by the way are negligible for electric cars. GM wouldn't even entertain the offers. Really, are you seriously arguing that the millions of dollars offered by the EV1 lessees wouldn't have covered the costs of their legal obligations to the owners to maintain the cars?
You don't even address point 3. GM promised not to crush the cars, then crushed them. The parent wasn't talking about figurative crushing of the EV1 program.
I don't even know what to say to your response to point 5. What exactly is it about California emissions standards that affects other states adversely? How exactly did California "kill" diesel in the US?
It takes a whole lot more training to learn how to service a modern ICE than a simple electric drive train. Different skills, yes. Skills that could be learned from a 50-page training manual, yes. GM could have paid any mechanic $15/hour off the street to service an EV1.
The EV1 absolutely fit the lives of the majority of drivers. It was a marketing failure on the part of GM that was the problem in that regard. GM did the opposite of marketing by actually emphasizing to its customers that the 100-mile range would be an inconvenience when in reality for most people it wouldn't be.
I'm not suggesting that GM is entirely to blame for the mid-90's death of the electric car, and neither was the director of Who Killed the Electric Car? In fact, the director does blame the consumer, in part. However, you have not shown that the points made by the parent have been discounted at all, let alone mostly discounted.
The problem with compressed air is that the energy density is even worse than batteries. Plus, as you approach capacity, the incremental energy required to add more energy to the tank increases exponentially. Converting the air pressure directly to motive power will always be more efficient than converting the energy to electrical then to motive power. Compressed air is inefficient to produce, dangerous to store, and low energy density. It is not currently a viable alternative.
While I certainly agree that you're not making up your $50k on the cost of gasoline anytime soon, you mention incorrectly that the Tesla is going to cost more in maintenance. There is only one moving part in the Telsa motor. No oil changes, no muffler maintenance, spark plugs, etc. etc. etc. Yes, you do have to look into a new battery at some point, but at the 10-year mark you're only down to 50-80% of the original battery life, and by that point the battery technology will be cheaper and better anyway. Possibly supercapacitors will be viable. Subtract out tires and brakes, then tell me that the maintenance of an ICE-based vehicle isn't going to cost you in the neighborhood of $5-$10k (replacement battery cost) over 10 years.
Given its performance, it actually is a very cost-effective sports car. You're not going to find a 4-second 60 for much cheaper than $100k anywhere. The top speed of the Tesla really isn't anything special, but when was the last time you pushed 120 on public roads?
The current high price tag is in large part due to the cost of development. Assuming Tesla gets its technologies and production capacity up to a reasonably large scale, that cost is going to come down quite a bit.
There is not enough available surface on the Roadster to gain even a nominal addition to the range by adding solar panels. Even the car referenced by the parent gains only an additional 20 miles per day with full sun exposure. Current (no pun intended) electric technologies simply do not support an electric car with a 300+ mile daily range. However, that is not to say that an electric car does not make sense for a daily commute. Your solar dollars are better invested in solar plants and static rooftop collectors than installing them on vehicles.
Unfortunately, by trying to help him with the last one, you've made it so he has to go back and do #1 again.
If there has ever been a post to which the old cliche is relevant (step 3: profit), this is it.
It's SETEC Astronomy, not SEATEC. This is important, because it's an anagram of "Too Many Secrets".
SETECASTRONOMY
TOOMANYSECRETS
The reference is from the movie "Sneakers".
Soon you can ask anyone from Brooklyn, too.
I think a better question is when ATMs will start using two factor authentication.
ATMs are already using two-factor: something you have (ATM card) and something you know (PIN). What is it that you want them to be doing instead?
There seems to be a lot of confusion about how this works. You need to understand two things to understand the GHH - first what a 'Google Hack' is in the first place, and second how to create a honeypot to record malicious behavior.
First, a quick summary of Google hacking: Google obviously has a huge cache of URLs. If a vulnerability is published that can be identified by a URI string, then you can simple Google that URI to identify vulnerable hosts. The GHH main page has a list of the current vulnerability signatures that it tracks.
In order to make a honeypot for this malicious behavior, you simply have to set up a Web server to respond appropriately to each of these linked URLs and have it be indexed by Google (not a trival task, but still quite doable). You can then track referring requests from Google by IP address, etc...
In order to defeat this type of tracking, an attacker could strip off the Referer header using an automated tool or a proxy, then route through an Onion router or some other anonymous proxy, but at least the server would still have some metrics to identify the relative freqency of attackers reaching the site through a "Google Hack."
Cornell has a few state schools, but both the Arts and Engineering schools are private. My CS degree was in Eng, my big brother's was in Arts.
I very much doubt this research was funded with a federal or state grant.
Credit card fraud is not a technical problem. Using the old adage, we cannot apply a technical solution. All of the extra verification proposed implies an added cost that will still not solve the problem - if you require a passphrase or some secondary authentication, thieves will just steal the second factor as well.
The best solution is to shift the responsibility for fraud to those that are responsible for allowing it - the merchants who process card transactions. This is how it is already done, and the fact that plenty of merchants still do business with credit cards proves that the system works, despite the fact that CC companies don't "give a shit."
As a consumer, I'd be perfectly fine with everyone knowing my credit card number because I'm not responsible for fraudulent purchases by law. This is a system that works.
What you should really be upset about it is the system that allows identity theft to run rampant. Though the two are related, there is a fundamental difference between someone else using a credit card you've established in your name and someone else using a credit card that they've established in your name.
The current system is much weaker against this type of activity because the burden of responsibility for fraud is still heavily on the consumer rather than the parties that allow identity theft to be profitable (mainly banks, but to a lesser extent any industry that relies on credit reporting). The solution to this problem is not so clear.
I can't tell if this was supposed to be a joke post or not (apparently the moderators thought so). Assuming you were serious...
Other posters already mentioned the possibility that the anchor text was different from the anchor URL. There are a number of ways that can be accomplished, from blindingly obvious to somewhat subtle. I have seen attacks that take advantage of a bug in IE: If you wrap an anchor tag around an image map, IE displays the URL for the anchor tag, but takes you to the map address when you click the image.
Another possibility is that the link was encoded using an alternate character set. The actual bytes of the string paypal.com can be totally different in UTF-7, UTF-8, etc...
The attackers might have delivered a malicious hosts file to your machine through some other security hole that maps that domain to the attacker's IP.
The moral is, never trust links in email.
I always thought 'blog' was onomatopoeia.
I have RTFA and I have to say that having a misspelling on the very first page of the comic didn't do very much for its credibility.
Here's a good mnemonic for remembering how to spell 'separate': just think of the first A being really big, as in 'sepArate.'
And if you can't get your friends to read all nine pages, the 9th is particularly worthwhile. Talk about a stunning portrait of democracy.
The example they use is where some secretary gets her boss to sign a document, and then uses his signature on another document which gives her access she shouldn't have. It's a way to forge a digital signature on a document by having them sign another one that you specially crafted.
This is imprecise and can be interpreted in horribly incorrect ways.
The example they use involves a secretary giving a document to her boss in order that he will sign the hash of that document. Beforehand the secretary has prepared another nearly identical document with the same exact hash value that is nevertheless rendered differently by PostScript. She then presents this other document and the boss's signature of the hash of that document, which is identical, in order to gain security clearance that she doesn't have.
The difference is subtle, but important.
Any hash algorithm with computable collisions is vulnerable to this attack. This research is not so important from the perspective that an MD5 collision was found (because this has already been shown several times by other researchers), but that we have to be careful about how we use hash functions.
.ps file (which contains functional code) to see that it also contained an authorization for Alice to view secret documents. Then he should have fed her to the lions.
It should be obvious that we should not simply sign the hash of just any data that comes across our desk - we need to make sure we are absolutely convinced that it is safe to sign that hash because we have fully vetted the contents of the file. In this case, Caesar should have looked at the contents of the
The reason why this works is that they are taking advantage of the length-extension property of the hash. This means that if any two documents have the same hash, adding the same bits to the end of the two documents will also have the same hash.
If you really wanted to spread the FUD, you could say that the researchers have published a univeral adapter for MD5 exploits simply by providing two distinct pieces of data with the same hash - a hash collision. With these two pieces of data, you could create ANY two files that could behave differently (executable files, HTML files with JavaScript, Word Documents with macros, etc...) depending on the value of these two colliding pieces of data. You would just need to make sure that both files were identical except for the two sections with the hash collisions. This, in fact, has already been done by previous researchers. The examples are referenced by the authors for EXE files and certificates.
To be fair, it should be noted that each of these texts was fully contained in both documents.
Oh, sure, and I'm sitting behind a monitored corporate firewall wondering just what might be on the end of such an URL.
Well, apparently they don't have a problem with your slashdot habit!