I'm sure it's great to repeat cliche lines when it comes to economics and computer science, and I know it's super popular with the recent quant economics and stock market debacle. But it'd be kind of nice if people knew what a Nash equilibrium is in the first place. If I use a Nash equilibrium strategy, it doesn't matter *how* you change your behaviour, you can't benefit from it. Think minimax algorithm in zero-sum games.
This is a perfectly sound mathematical concept, in a mathematical sense it's as true as anything else in mathematics. And this is an important and interesting result we found about it. There's no need to label anybody as "geeks addicted to a single theory". It's the same as saying that we "need to stop being addicted to believing that 1+1 equals 2 and start dealing with people".
Our applications of the theory can be more or less successful, and any application of game theory to anything as complicated as economics can only be an approximation. But there's no need to spit on this result because of that.
The key difference is that with IMG tag the attacker can only get the user's browser to make GET requests, whereas this attack enables POST requests as well. Any reasonably well-designed online banking application should not be exploitable via GET requests.
Also, the attack vector here is different compared to a "regular" CSRF through XSS. Which one is more practical is open to debate.
Erm, no, you're getting it wrong. What this attack means is that the attacker gets the ability to make arbitrary requests for resources on behalf of the user.
So no, it doesn't mean that the attacker can now serve you malicious web pages that will appear to be coming from your bank's web site. What it does mean is that once you go to a secure page on your bank site, the attacker can instruct the bank to transfer money from your account to his, without you ever knowing. This is kind of similar to the IMG tag attack but it's more difficult to defend against.
Huh? Dude, look at the second video, he's cutting the turn short by riding on his inside ski. That's a classic Hermann Maier right there! Doesn't get much ballsier than that...
Actually that was the very first thought that went through my mind after reading the summary.
But I have to confess that the idea is not mine; I remember reading about it around a year ago, on this very site, in a comment posted by the most prolific Slashdot member of all. For better or for worse, still no place like/.
I fail to see how it matters for this particular locking purpose. Please explain what are the gains of scenario 1 gain over scenario 2 from a malicious user perspective:
Mallory makes some changes; another user makes other changes to the same document and saves it before Mallory does. Priory to posting her changes back, Mallory retrieves the new hash, and changes the form value accordingly, thus cleverly escaping your locking mechanism
Mallory makes some changes; another user makes other changes to the same document and saves it before Mallory does. Mallory posts the form normally, gets notified that the document has been changed in the meantime and clicks "save anyway"
On the surface, JS is a really nice language, but it really has a fair share of warts which will bite you. And yes, I'm aware that Javascript is neither DOM nor CSS. For those interested, Bob Ippolito (the author of MochiKit) wrote the best "Javascript sucks" article I've ever read.
Back when Google was running the first round of the Android programming challenge, a lot of excitement was generated by an augmented reality app called Enkin. To everybody's surprise, it didn't make it into the first round of finals, and seemd to disappear from sight. Turns out that Google had some other plans for them.
I did see one AR app in action on a G1, but I don't remember what it was called. The results were so-so... Hit and miss, sometimes it would get the buildings right, sometimes it wouldn't. But AR is definitely a very appealing possibility, and it'll probably improve very quickly. All the basic bits seem to be there.
In the same way, a process can grow and grow, but as soon as it completes (you close a tab in the browser), the memory will go back to the operating system so other processes can use it. But if the process does not complete because it uses threads to build those same tabs, then the process will continue to take up that memory.
Huh? It will only continue to take up the memory if the thread leaks memory. If the thread manages its local memory properly, then after it finishes, the process will only take up the shared memory + local memory for every active thread. Or, to use your analogy, the house will shrink.
Now, if you're contending that proper memory management is not entirely trivial, I agree
This guy has a set of opera keybindings which resemble vim. Works pretty well too. The only thing missing would be form field editing with vim bindings.
And the fact that he missed the obvious cool name of "vimoperator";)
Don't know much about history
Don't know much of biology
But I do know
I'll infect you
With a new strain
Of homebrewed flu
What a wonderful world
This will be
Slashdot Mirror
Wrong. Your HTTP headers don't end up on your Twitter "blog" (or whatever it's called), they end up on the attacker's.
And as for banks not having a public messaging feature, is Citibank big enough for you?
https://banking.citibank.com/JoinOurOnlineForum/UserGuide.aspx
But once again, do note that the page where the user's credentials end up doesn't need to be public; it just has to be accessible by the attacker.
I'm sure it's great to repeat cliche lines when it comes to economics and computer science, and I know it's super popular with the recent quant economics and stock market debacle. But it'd be kind of nice if people knew what a Nash equilibrium is in the first place. If I use a Nash equilibrium strategy, it doesn't matter *how* you change your behaviour, you can't benefit from it. Think minimax algorithm in zero-sum games.
This is a perfectly sound mathematical concept, in a mathematical sense it's as true as anything else in mathematics. And this is an important and interesting result we found about it. There's no need to label anybody as "geeks addicted to a single theory". It's the same as saying that we "need to stop being addicted to believing that 1+1 equals 2 and start dealing with people".
Our applications of the theory can be more or less successful, and any application of game theory to anything as complicated as economics can only be an approximation. But there's no need to spit on this result because of that.
Heck, an elephant needs a thicker skin if he's going to deal with the LKLM crowd.
The key difference is that with IMG tag the attacker can only get the user's browser to make GET requests, whereas this attack enables POST requests as well. Any reasonably well-designed online banking application should not be exploitable via GET requests.
Also, the attack vector here is different compared to a "regular" CSRF through XSS. Which one is more practical is open to debate.
Erm, no, you're getting it wrong. What this attack means is that the attacker gets the ability to make arbitrary requests for resources on behalf of the user.
So no, it doesn't mean that the attacker can now serve you malicious web pages that will appear to be coming from your bank's web site. What it does mean is that once you go to a secure page on your bank site, the attacker can instruct the bank to transfer money from your account to his, without you ever knowing. This is kind of similar to the IMG tag attack but it's more difficult to defend against.
Hm, you'd better have that checked at l'Hospital.
Huh? Dude, look at the second video, he's cutting the turn short by riding on his inside ski. That's a classic Hermann Maier right there! Doesn't get much ballsier than that...
Actually that was the very first thought that went through my mind after reading the summary.
But I have to confess that the idea is not mine; I remember reading about it around a year ago, on this very site, in a comment posted by the most prolific Slashdot member of all. For better or for worse, still no place like /.
The very best comment from the blog:
I had no idea Pez had a "Fashion Week" dispenser line.
Awshumz.
It's not just the disk space, it's also the memory. With shared libraries, you only have to load the code into memory once.
Honey, is that you?
Free as in beer or free as in freedom?
And they installed FreeBSD on it?
I fail to see how it matters for this particular locking purpose. Please explain what are the gains of scenario 1 gain over scenario 2 from a malicious user perspective:
I'm mad as hell and I'm not going to use the ribbon anymore!
On the surface, JS is a really nice language, but it really has a fair share of warts which will bite you. And yes, I'm aware that Javascript is neither DOM nor CSS. For those interested, Bob Ippolito (the author of MochiKit) wrote the best "Javascript sucks" article I've ever read.
You mean something like this?
So you're saying they sped their program up by a factor of 100 by replacing a quadratic algorithm with an algorithm for an NP-complete problem?
You don't need add Bruce Schneier to a trustee list. The Universe hardcodes him inside it, at a (cryptography secure) pseudo-random location.
Actually the other FA says:
The SMS vulnerability allows an attacker to run software code on the phone that is sent by SMS over a mobile operator's network.
So it's not really GP's fault.
Imagine a compiler that would eat any typo. Missing brackets, braces, semicolons, object-function separators, completely meaningless semantic messes.
Must... resist... must... resist...PHP! Bloody PHP! Bloody E_NOTICE!
Oh dear, there goes my karma...
Back when Google was running the first round of the Android programming challenge, a lot of excitement was generated by an augmented reality app called Enkin. To everybody's surprise, it didn't make it into the first round of finals, and seemd to disappear from sight. Turns out that Google had some other plans for them.
I did see one AR app in action on a G1, but I don't remember what it was called. The results were so-so... Hit and miss, sometimes it would get the buildings right, sometimes it wouldn't. But AR is definitely a very appealing possibility, and it'll probably improve very quickly. All the basic bits seem to be there.
In the same way, a process can grow and grow, but as soon as it completes (you close a tab in the browser), the memory will go back to the operating system so other processes can use it. But if the process does not complete because it uses threads to build those same tabs, then the process will continue to take up that memory.
Huh? It will only continue to take up the memory if the thread leaks memory. If the thread manages its local memory properly, then after it finishes, the process will only take up the shared memory + local memory for every active thread. Or, to use your analogy, the house will shrink.
Now, if you're contending that proper memory management is not entirely trivial, I agree
This guy has a set of opera keybindings which resemble vim. Works pretty well too. The only thing missing would be form field editing with vim bindings.
And the fact that he missed the obvious cool name of "vimoperator" ;)
Don't know much about history Don't know much of biology But I do know I'll infect you With a new strain Of homebrewed flu What a wonderful world This will be