Ah. I think I see what you mean. The key phrase is "The diversity of interests represented in any large political body makes such an approach relatively ineffective" - in other words, in the US, voters in different parts of the nation may want very different things. That's much less true pretty much everywhere else in the world, which might well explain why the US system is so different.
In a pure democracy, the voters in different parts of the US would have to negotiate directly with one another. That's implausible, so you have a representative democracy, and the representatives negotiate with one another.
When you put it that way, it actually makes sense.... it still isn't how democracy was *first* designed to work, which is what I was originally thinking of - but it seems fair to say it is how American democracy was designed to work, and that's what I should have been thinking of.:-)
No, it's not how democracy is designed to work. The decision to support or oppose a policy is supposed to be based on whether the policy is a good one, not on whether or not you can get support for one of your policies in return.
The US is unusual in this respect, I believe, though presumably not unique. Whether the more usual system (party line voting) is any better is open to question; I prefer it, but that's presumably just because it's what I'm used to.
Actually the article confuses two unrelated security issues. Microsoft said they weren't planning to do anything about the counter-mitigation technique, which may allow an attacker to bypass ASLR in IE on 32-bit Windows. The cookie-stealing vulnerability will presumably be patched in due course.
It isn't a vulnerability, it's a counter-mitigation technique. So 32-bit Windows isn't as effective at mitigating unknown vulnerabilities as 64-bit Windows; nothing new there.
No, those are two unrelated issues. There's an exploit against IE that allows an attacker to steal localhost cookies. This affects both 32-bit and 64-bit Windows, and will presumably be patched in due course. Then there's a new counter-mitigation technique, which only affects IE on 32-bit Windows, and which Microsoft apparently aren't planning to fix. That one might allow an attacker, in possession of an exploit that potentially allows code execution, to run code when the mitigation would otherwise have made it impossible - but it is only a counter-mitigation technique, not a vulnerability in and of itself.
I'm not sure IE7 even includes the mitigations that this technique defeats. If you run old software, you're more exposed to bugs - nothing new about that.
Those are two unrelated exploits. The advisory on the first exploit doesn't mention ASLR, the white paper on the counter-mitigation technique doesn't mention cookies.
These are two unrelated issues - a vulnerability which affects machines that have web servers running on localhost, and a counter-mitigation technique that affects IE running on 32-bit Windows. Those machines are probably affected by both issues, but the first will probably be patched in due course and the second isn't an exploit as such but a method of making other exploits more effective.
There are a number of mitigation techniques that either don't exist or aren't as effective on 32-bit Windows. I don't think this one is necessarily a game-changer.
The vulnerability described in the first link appears to be completely unrelated to the vulnerability discussed in the second link. One is a straightforward information exposure vulnerability, the other is a counter-mitigation technique that bypasses ASLR.
I've checked the detailed reports, too; neither "ASLR" nor "mitigation" appear in the first report, and neither "cookies" nor "localhost" appear in the second report. They're from different people and different organizations. Apart from the fact that they both affect IE, they've got nothing to do with one another.
"If I develop a product such a film that people are interested in seeing, then I have a right to charge a fee to let them see it."... of course, so long as you maintain possession. As soon as you sell someone a copy, what right do you have to prevent them from copying it again, if they are capable of doing so?
(If I sell someone a hammer, I don't get to charge them on a per-nail basis for the rest of eternity!)
"That's how copyright benefits society"... YES. Copyright exists because it was believed that the benefit to society (more art) would outweigh the costs. But if that is no longer true, then copyright should be abolished. And I believe we're rapidly reaching that point.
"A machine that can make apples can be copyrighted, apples cannot."... now you're just arguing in circles. *Why* can't apples be copyrighted? Why would it be ethical to copy apples, but not films?
"If someone needs a hole dug and you dig it for them,"... but that's not how copyright works. Of course an artist can refuse to work unless someone agrees in advance to pay them for it. You don't need copyright for that.
"If someone has a product that you want"... if the artist *literally* has the product, then of course they can charge you for it. But if I can obtain the same product from someone else - because they purchased it from the artist *and then made a copy* - then the analogy falls down.
The problem is that you're trying to pretend that an abstract concept - a series of zeros and ones - must be treated as though it had a real, concrete existence, must be someone's "property". And that's simply not true. It is *convenient* for us to treat an abstract work of art as if it were concrete, and to assign a limited form of ownership to it on that basis - but it is not *mandatory*.
Nonsense. There's no ethical justification for copyright other than its benefit to society. You're not automatically entitled to government protection simply because without it your business model doesn't work.
If we one day develop a machine that can duplicate, say, apples, we're not going to demand that everybody pay the person who grew the original apple before they eat one of the duplicates. So why should we pay the person who recorded the song before we listen to a copy of it?
(It's more complicated than that, of course; artists have invested time and money into their work precisely because we promised them they would be paid for it, so it wouldn't be ethical to simply abolish copyright outright. We'd have to have some sort of grandfather clause and/or compensation. And its not likely to happen anyway, because the people that benefit most from corporate welfare schemes such as copyright have too much influence. But it's important to realize where copyright came from if we're going to resist even more encroachments on our personal rights.)
Copyright exists for the benefit of society, not because artists have "a right to be paid". (They have a right to "demand to be paid", since that's just free speech, but society is entitled to say "sod off" in reply.)
We're rapidly approaching the point where "sod off" is the most sensible reply - copyright is increasingly working against society rather than for it. This incident is just another brick in the wall.
Not so. My main Windows server suffered serious problems when first deployed - not so long ago - which we eventually tracked down to the use of TRIM on the iSCSI drives.
Granted the issues were mainly DoS rather than data loss, it was still a serious problem.
But i does have to be positive if a is an array, and that's the only case that matters in this context - the point being that the language could still implement arrays by defining a[i] as meaning *(a+i), even if pointer arithmetic was constrained to be unsigned.
I don't think the distinction is necessarily unimportant just because it is fuzzy. But I don't feel all that strongly about it.
As for signed pointer arithmetic: a[i] isn't really a good example because i has to be positive. But I was wrong anyway - I was thinking about things like this but now that I look at it again, the language really does need to let you subtract pointers and get a negative answer - the real problem in that example is the silly implicit conversion from signed to unsigned.
My point is that if (hypothetically speaking) the next specification of C left all that stuff out, it would still be a useful language. *Less* useful, but not useless.
(I don't need size_t because I can use ULONG_PTR. Signed pointer arithmetic is best avoided IMO, but if you force me to do it I have LONG_PTR. If there were no standard library, there would probably be an implementation-defined replacement for va_list, but if not, I can do without it; if necessary, I can always pass an array of pointers. No problem.)
Not at all. I have a number of C programs that (quite deliberately) do not use the standard library at all.
Having the standard C library - so that at least some parts of your code don't need to be rewritten for each operating system - is certainly convenient, but it is far from essential.
Exactly - though I think there may be some truth to the criticism that string theory shows no signs of getting anywhere.
The thing is that we don't currently have a single coherent theory that explains all the experimental results we have to date, even if we were to ignore complicating factors like Dark Matter. The Standard Model explains everything we can see in a particle accelerator, and GR explains most of what we see on a large scale, but there's no theory that does both. That's what string theory was supposed to do, and perhaps one day it will.
The successful development of such a theory would be a legitimately big deal, in my opinion, even if it doesn't predict anything different enough to the Standard Model in the one regime, or to GR in the other, that we can test it yet.
Slashdot Mirror
So, what information was leaked? Seems like a fairly relevant point, odd that it wasn't mentioned.
Mandatory xkcd: https://xkcd.com/915/
Ah. I think I see what you mean. The key phrase is "The diversity of interests represented in any large political body makes such an approach relatively ineffective" - in other words, in the US, voters in different parts of the nation may want very different things. That's much less true pretty much everywhere else in the world, which might well explain why the US system is so different.
In a pure democracy, the voters in different parts of the US would have to negotiate directly with one another. That's implausible, so you have a representative democracy, and the representatives negotiate with one another.
When you put it that way, it actually makes sense. ... it still isn't how democracy was *first* designed to work, which is what I was originally thinking of - but it seems fair to say it is how American democracy was designed to work, and that's what I should have been thinking of. :-)
No, it's not how democracy is designed to work. The decision to support or oppose a policy is supposed to be based on whether the policy is a good one, not on whether or not you can get support for one of your policies in return.
The US is unusual in this respect, I believe, though presumably not unique. Whether the more usual system (party line voting) is any better is open to question; I prefer it, but that's presumably just because it's what I'm used to.
No more so than before. :-)
The mitigations that this research affects weren't introduced until 2014 anyway.
Actually the article confuses two unrelated security issues. Microsoft said they weren't planning to do anything about the counter-mitigation technique, which may allow an attacker to bypass ASLR in IE on 32-bit Windows. The cookie-stealing vulnerability will presumably be patched in due course.
It isn't actually a bug, but a limitation of the mitigation technique. There's isn't any simple way to fix it.
It isn't a vulnerability, it's a counter-mitigation technique. So 32-bit Windows isn't as effective at mitigating unknown vulnerabilities as 64-bit Windows; nothing new there.
No, those are two unrelated issues. There's an exploit against IE that allows an attacker to steal localhost cookies. This affects both 32-bit and 64-bit Windows, and will presumably be patched in due course. Then there's a new counter-mitigation technique, which only affects IE on 32-bit Windows, and which Microsoft apparently aren't planning to fix. That one might allow an attacker, in possession of an exploit that potentially allows code execution, to run code when the mitigation would otherwise have made it impossible - but it is only a counter-mitigation technique, not a vulnerability in and of itself.
I'm not sure IE7 even includes the mitigations that this technique defeats. If you run old software, you're more exposed to bugs - nothing new about that.
Those are two unrelated exploits. The advisory on the first exploit doesn't mention ASLR, the white paper on the counter-mitigation technique doesn't mention cookies.
These are two unrelated issues - a vulnerability which affects machines that have web servers running on localhost, and a counter-mitigation technique that affects IE running on 32-bit Windows. Those machines are probably affected by both issues, but the first will probably be patched in due course and the second isn't an exploit as such but a method of making other exploits more effective.
There are a number of mitigation techniques that either don't exist or aren't as effective on 32-bit Windows. I don't think this one is necessarily a game-changer.
The vulnerability described in the first link appears to be completely unrelated to the vulnerability discussed in the second link. One is a straightforward information exposure vulnerability, the other is a counter-mitigation technique that bypasses ASLR.
I've checked the detailed reports, too; neither "ASLR" nor "mitigation" appear in the first report, and neither "cookies" nor "localhost" appear in the second report. They're from different people and different organizations. Apart from the fact that they both affect IE, they've got nothing to do with one another.
"If I develop a product such a film that people are interested in seeing, then I have a right to charge a fee to let them see it." ... of course, so long as you maintain possession. As soon as you sell someone a copy, what right do you have to prevent them from copying it again, if they are capable of doing so?
(If I sell someone a hammer, I don't get to charge them on a per-nail basis for the rest of eternity!)
"That's how copyright benefits society" ... YES. Copyright exists because it was believed that the benefit to society (more art) would outweigh the costs. But if that is no longer true, then copyright should be abolished. And I believe we're rapidly reaching that point.
"A machine that can make apples can be copyrighted, apples cannot." ... now you're just arguing in circles. *Why* can't apples be copyrighted? Why would it be ethical to copy apples, but not films?
"If someone needs a hole dug and you dig it for them," ... but that's not how copyright works. Of course an artist can refuse to work unless someone agrees in advance to pay them for it. You don't need copyright for that.
"If someone has a product that you want" ... if the artist *literally* has the product, then of course they can charge you for it. But if I can obtain the same product from someone else - because they purchased it from the artist *and then made a copy* - then the analogy falls down.
The problem is that you're trying to pretend that an abstract concept - a series of zeros and ones - must be treated as though it had a real, concrete existence, must be someone's "property". And that's simply not true. It is *convenient* for us to treat an abstract work of art as if it were concrete, and to assign a limited form of ownership to it on that basis - but it is not *mandatory*.
Nonsense. There's no ethical justification for copyright other than its benefit to society. You're not automatically entitled to government protection simply because without it your business model doesn't work.
If we one day develop a machine that can duplicate, say, apples, we're not going to demand that everybody pay the person who grew the original apple before they eat one of the duplicates. So why should we pay the person who recorded the song before we listen to a copy of it?
(It's more complicated than that, of course; artists have invested time and money into their work precisely because we promised them they would be paid for it, so it wouldn't be ethical to simply abolish copyright outright. We'd have to have some sort of grandfather clause and/or compensation. And its not likely to happen anyway, because the people that benefit most from corporate welfare schemes such as copyright have too much influence. But it's important to realize where copyright came from if we're going to resist even more encroachments on our personal rights.)
The ones who want to make money won't. So what?
Copyright exists for the benefit of society, not because artists have "a right to be paid". (They have a right to "demand to be paid", since that's just free speech, but society is entitled to say "sod off" in reply.)
We're rapidly approaching the point where "sod off" is the most sensible reply - copyright is increasingly working against society rather than for it. This incident is just another brick in the wall.
Not so. My main Windows server suffered serious problems when first deployed - not so long ago - which we eventually tracked down to the use of TRIM on the iSCSI drives.
Granted the issues were mainly DoS rather than data loss, it was still a serious problem.
Relevant.
But i does have to be positive if a is an array, and that's the only case that matters in this context - the point being that the language could still implement arrays by defining a[i] as meaning *(a+i), even if pointer arithmetic was constrained to be unsigned.
I don't think the distinction is necessarily unimportant just because it is fuzzy. But I don't feel all that strongly about it.
As for signed pointer arithmetic: a[i] isn't really a good example because i has to be positive. But I was wrong anyway - I was thinking about things like this but now that I look at it again, the language really does need to let you subtract pointers and get a negative answer - the real problem in that example is the silly implicit conversion from signed to unsigned.
My point is that if (hypothetically speaking) the next specification of C left all that stuff out, it would still be a useful language. *Less* useful, but not useless.
(I don't need size_t because I can use ULONG_PTR. Signed pointer arithmetic is best avoided IMO, but if you force me to do it I have LONG_PTR. If there were no standard library, there would probably be an implementation-defined replacement for va_list, but if not, I can do without it; if necessary, I can always pass an array of pointers. No problem.)
Copyright exists to benefit society. How does it benefit society for APIs to be copyrightable?
Not at all. I have a number of C programs that (quite deliberately) do not use the standard library at all.
Having the standard C library - so that at least some parts of your code don't need to be rewritten for each operating system - is certainly convenient, but it is far from essential.
Exactly - though I think there may be some truth to the criticism that string theory shows no signs of getting anywhere.
The thing is that we don't currently have a single coherent theory that explains all the experimental results we have to date, even if we were to ignore complicating factors like Dark Matter. The Standard Model explains everything we can see in a particle accelerator, and GR explains most of what we see on a large scale, but there's no theory that does both. That's what string theory was supposed to do, and perhaps one day it will.
The successful development of such a theory would be a legitimately big deal, in my opinion, even if it doesn't predict anything different enough to the Standard Model in the one regime, or to GR in the other, that we can test it yet.