They're not going to throw out the JVM and rewrite it from scratch between releases. If there are 60 options now, there may be 66 in the next release. That means 90% of the book is still useful and the other 10% is just missing.
On top of that, as the reviewer clearly states "Unlike most computer books, there's a lot of actual discussion in Java Performance, as opposed to just documentation of features.... there are pages upon pages of imposing text, indicating that you actually need to sit down and read it...". So this book is already the kind of book that isn't going to be overturned by one more JVM release. It may contain actual wisdom rather than a list of flags.
I think you can actually make some tentative links. For example, if you have some product that sells very rarely and you take the intersection of the sets of cars that are in the parking lot whenever that product is sold, if that intersection becomes one car, the probability that this is the guy buying that product is probably higher than if you just averaged the sales of the product over all the cars that were ever present during that purchase. After all, if this product X is only purchased a few times a year and the only car that was there each time was car Y, the probability that this guy driving car Y just "happens" to be there every time that purchase happens becomes lower too.
I'm no statistician, but it seems like you could calculate the probability of it being a coincidence versus the probability of there being a relationship, and when the probability of there being a relationship is high enough, you could take the leap and make the assumption. Of course, you'll get false positives, probably many of them, but if you crank your thresholds up high enough it may be a net win.
A simpler way to improve your data would be to ferret out whatever public information you can about the owner of a given license plate. I wouldn't be too shocked if there were ways of getting this information in bulk. After all, you could do the same sort of subset thing with credit card purchases. If I see person A, B, and X on day 1 and person X, Y and Z on day 2, and I see cars a, b and x on day 1 and x, y and z on day 2, the same sort of subsetting operation could get you a bunch of single-element sets. You'd still probably have to have lots of days of information, but when you have 24-hour monitoring times thousands of stores nationwide times tens of thousands of customers per day per store, you quickly develop a pool of information you could sift through like this. And once I know your car is the one with plate X, I know it for keeps: you can stop paying with your cards all you want, I only needed so many repeat instances to figure it out.
Ultimately, it would be easy to get freaked out by all this, but let's remember what this information is used for: to send you coupons you'd actually want to use. That's the whole thing. Dial back the paranoia a bit.
I hate to ruin your argument by pointing out an obvious fallacy, but an iBooks "textbook" stretches the definition of "book" way past the breaking point. I also doubt there are going to be competing implementations of the iBook textbook reader or other bookstores from which to distribute them. You'd certainly miss out on the iBooks marketplace, which one can reasonably assume will be the only meaningful distributor of iBooks books and therefore iPad books.
Complaining about this note in the EULA while ignoring the overall ecosystem is picking the pepper out of the fly shit. If you have a problem with this, you probably have lots of other issues with Apple or iBooks that aren't going to be resolved by fixing this detail. Likewise, if you don't care about those details, you probably don't care about this one either.
Are you going to use this to suddenly rewrite the browser and change everything? Is the Mozilla Corporation trying to force the community to use a new language?
No. The Mozilla Corporation's involvement is at the labs level: the group concerned with doing experiments. The point is to explore ideas. There is currently no plan to incorporate any Rust-based technology into Firefox. ... What are some non-goals? ...To cover the complete feature-set of C++, or any other language. It should provide majority-case features.
The absolutely brazen, bald-faced misinterpretation of what's going on here is stunning. They could not miss the point by more!
First, I'm sorry about being a dick. I think not being able to hit Wikipedia yesterday really soured my mood. Yes, that's what I meant about DAGs, but it was just a dick thing to say.
So, you make a good point, and I'm calm enough to see it today. I still think the article oversells the danger of this bug. We don't use dblink or hotbackup at my site (we're transitioning away from Oracle too). My friend sysadmins for a company that has a much larger clustered Oracle instance, and were using this hotbackup facility. Their DBA noticed the problem a while back and took steps to counteract it. They're also not using dblink.
I suppose there's a lot of personal bias in my perspective here. I haven't had to deal with large corporations with huge, interlinked Oracle instances. For them this could be an issue, but security is a problem that grows exponentially. While applying the patch is something that should be done, I think they can effectively counteract the problem by restricting access to hot backup, maintaining better control over their databases as a whole and reducing use of dblink.
That said, handling anybody's database situation is not an easy task. Where I work, there are only a few hundred employees, but enough of them are engineers and programmers that there are many unaccounted-for databases. Even worse, when a developer sets up a database, they're much less likely to keep it up-to-date as long as it's working. This situation is ripe for this kind of threat, but I say this situation is already bad enough that this is just icing on the cake.
But if you've rooted a machine, that's not much of a barrier.
That's my whole point. You've already rooted the machine. You can do anything. The bug is irrelevant. You can just shut the database down. You can delete the cluster. Anything. This bug has nothing to do with it.
Further, like many exploits, only one person needs to be good enough to develop the exploit. Then it can be packaged in a script that any random can use.
Your pre-packaged exploit is unable to use this bug to root the machine, and furthermore depends on the machine being rooted already to work. Not an exploit.
the attitude "this is too hard" leads to a lot of compromised systems. I've had to clean up too many compromised systems due to that complacency.
In order for this to be a problem, you already have to have failed at setting up a firewall or had compromised security elsewhere. I don't disagree with you in general, I'm just saying, this is not a security vulnerability, by the above.
If what you say was true, such things as stack smashing and SQL injection that compromise systems all the time would never have become a problem.
I most certainly did not say that, and in order for that to be a consequence of my argument there would have to be a dependency on a pre-existing root exploit or other privilege escalation mechanism for stack smashing and SQL injection to work. But there isn't, which is what makes this completely different. You already need to have compromised security to use this bug to compromise security.
If half of you security morons would take enough CS to learn the tiniest bit of graph theory and find out what a DAG is, I wouldn't find myself having this argument constantly.
Every transaction that results in a change will increment the SCN, which is what the article is implying. This is a big part of databasery, so of course there will be unprivileged (i.e. non-admin) users who can increment the SCN through the usual manner of running transactions. My point is that with the ability to run transactions but without the ability to run ALTER DATABASE BEGIN BACKUP (i.e. a non-admin user with write access) it will be hard to beat ALTER DATABASE BEGIN BACKUP at the game of incrementing the SCN. Certainly if you are running that quantity of transactions, odds are good you are already DOSing the database without the SCN soft limit bug even being involved.
This right here is a great example of why I think software security as a field is largely bullshit. The amount of work and luck it would take to "exploit" this is such that by the time you've done it, you've already exploited all sorts of other things, including pre-existing poor security. It's not a security problem. Security is just a great way to get everyone's blood pumping.
I think man-made climate change is real. Unlike all your other talking points, there is actual evidence for it. Do note: your hippie friends play fast and loose with the facts to get bigger donations for their cause. They're building their political program on the back of your upper-class guilt that you'll do anything to alleviate. Fact-check yourself. Things aren't that bad.
I read the article, and I must have missed mention of any other way than through ALTER TABLE BEGIN BACKUP to get the SCN to increment dramatically. I think it would be hard to do a better job than than Oracle's bug, which according to the article could achieve a rate of millions or billions of increments per second, by simply running a trivial transaction in a loop. Could it be done? Maybe, but that could be a lot of work.
Now, my impression is that this is a really obnoxious bug that will bite their highest paying customers disproportionally, but not that this is a particularly onerous security problem. The prerequisites for using this to perform a DOS are pretty big. Oracle's protocols are not particularly open. The SCN is buried in the database pretty deep; there's no way for an admin to directly access it. So you either have to trick an instance into manufacturing large values for you with a loop, or you'd have to reverse engineer the database link protocol. Even assuming you've done that, you having to insert yourself into the database's network. If you can afford enough Oracle licenses to run an Oracle cluster, you're probably paying for Oracle DBAs and systems administrators that know how to operate a firewall. Your Oracle is probably not listening on the public network. I'm saying that in all but the most pathologically embarrassing circumstances, you already have to own machines on this network to take down Oracle this way, which means your security was already breached before you could use this to breach the security.
What's going on here is actually MVCC. The idea here isn't to implement mutual exclusion so much as to ensure that concurrent writes can occur but nobody sees information outside their transaction; each transaction gets an ID assigned to it which is 1 + the previous transaction ID (in an idealized, serializable exclusion state) and your transaction can see any information with your ID or a lower (but committed) transaction ID. Transactions begun after yours can see your effects only after you've committed, and you can't see effects from transactions started after yours, even if they are committed.
Now, it's really only an "attack" if you have both 1) a way to inflate the number quickly and 2) small maximum values. It happens that these conditions are met with Oracle only because there's a bug in the hot backup facility, and the database link facility lets you pump the value across the cluster. This isn't a problem with PostgreSQL, because the version comparison uses modular arithmetic that permits wraparound and the VACUUM facility marks old transactions with an "older than everything" version that is special-cased in the comparison. So if the relationship between MVCC and the bakery algorithm is close, it wouldn't take a very big tweak to make the bakery algorithm resilient against this problem.
I love this idea. So there's some sort of government layer between scientists and their phones, email, blogs, and everything? That they have the infrastructure to cover this up successfully, but can't cover up when one of their own officials does one thing with one other person alone in a room in which they are the only two people? The people they'd be most interested in covering this up from are also the people who are the least likely to believe anything a scientist says anyway.
Absence of evidence is not evidence of absence. It's not pessimism, it's just acknowledging that one example isn't a pattern. To take away from it that the universe is teeming with life is reading just as much into the tiny scrap of evidence we have as saying there is no life. In general, when you can use the same evidence to make two equally strong yet completely contradictory arguments, you're better off just shutting up.
So with Brent as my witness, let's leave it at "well, dude, we just don't know."
Isn't that enough? Isn't it enough motivation for a politician to do something if another politician accuses him of not doing something?
If it's enough to make the party change their minds about who they support, isn't it enough? If it's enough to send reporters scrambling through vault footage of the politician, isn't it enough? If it's enough to get the op-eds, talking heads and callers calling in, isn't it enough?
Slashdot Mirror
They're not going to throw out the JVM and rewrite it from scratch between releases. If there are 60 options now, there may be 66 in the next release. That means 90% of the book is still useful and the other 10% is just missing.
On top of that, as the reviewer clearly states "Unlike most computer books, there's a lot of actual discussion in Java Performance, as opposed to just documentation of features.... there are pages upon pages of imposing text, indicating that you actually need to sit down and read it...". So this book is already the kind of book that isn't going to be overturned by one more JVM release. It may contain actual wisdom rather than a list of flags.
I think you can actually make some tentative links. For example, if you have some product that sells very rarely and you take the intersection of the sets of cars that are in the parking lot whenever that product is sold, if that intersection becomes one car, the probability that this is the guy buying that product is probably higher than if you just averaged the sales of the product over all the cars that were ever present during that purchase. After all, if this product X is only purchased a few times a year and the only car that was there each time was car Y, the probability that this guy driving car Y just "happens" to be there every time that purchase happens becomes lower too.
I'm no statistician, but it seems like you could calculate the probability of it being a coincidence versus the probability of there being a relationship, and when the probability of there being a relationship is high enough, you could take the leap and make the assumption. Of course, you'll get false positives, probably many of them, but if you crank your thresholds up high enough it may be a net win.
A simpler way to improve your data would be to ferret out whatever public information you can about the owner of a given license plate. I wouldn't be too shocked if there were ways of getting this information in bulk. After all, you could do the same sort of subset thing with credit card purchases. If I see person A, B, and X on day 1 and person X, Y and Z on day 2, and I see cars a, b and x on day 1 and x, y and z on day 2, the same sort of subsetting operation could get you a bunch of single-element sets. You'd still probably have to have lots of days of information, but when you have 24-hour monitoring times thousands of stores nationwide times tens of thousands of customers per day per store, you quickly develop a pool of information you could sift through like this. And once I know your car is the one with plate X, I know it for keeps: you can stop paying with your cards all you want, I only needed so many repeat instances to figure it out.
Ultimately, it would be easy to get freaked out by all this, but let's remember what this information is used for: to send you coupons you'd actually want to use. That's the whole thing. Dial back the paranoia a bit.
Thanks for your relevant and interesting insight.
And thus we have the return of Esperanto.
This is the whole point of category theory in mathematics: finding and utilizing large-scale similarities between mathematical disciplines.
I hate to ruin your argument by pointing out an obvious fallacy, but an iBooks "textbook" stretches the definition of "book" way past the breaking point. I also doubt there are going to be competing implementations of the iBook textbook reader or other bookstores from which to distribute them. You'd certainly miss out on the iBooks marketplace, which one can reasonably assume will be the only meaningful distributor of iBooks books and therefore iPad books.
Complaining about this note in the EULA while ignoring the overall ecosystem is picking the pepper out of the fly shit. If you have a problem with this, you probably have lots of other issues with Apple or iBooks that aren't going to be resolved by fixing this detail. Likewise, if you don't care about those details, you probably don't care about this one either.
It's $2. I agree with your point though.
From the Rust Project FAQ:
The absolutely brazen, bald-faced misinterpretation of what's going on here is stunning. They could not miss the point by more!
Isn't that exactly what is meant by "The People" in the name of the suit?
How is SOPA going to stop you from hosting your files yourself?
First, I'm sorry about being a dick. I think not being able to hit Wikipedia yesterday really soured my mood. Yes, that's what I meant about DAGs, but it was just a dick thing to say.
So, you make a good point, and I'm calm enough to see it today. I still think the article oversells the danger of this bug. We don't use dblink or hotbackup at my site (we're transitioning away from Oracle too). My friend sysadmins for a company that has a much larger clustered Oracle instance, and were using this hotbackup facility. Their DBA noticed the problem a while back and took steps to counteract it. They're also not using dblink.
I suppose there's a lot of personal bias in my perspective here. I haven't had to deal with large corporations with huge, interlinked Oracle instances. For them this could be an issue, but security is a problem that grows exponentially. While applying the patch is something that should be done, I think they can effectively counteract the problem by restricting access to hot backup, maintaining better control over their databases as a whole and reducing use of dblink.
That said, handling anybody's database situation is not an easy task. Where I work, there are only a few hundred employees, but enough of them are engineers and programmers that there are many unaccounted-for databases. Even worse, when a developer sets up a database, they're much less likely to keep it up-to-date as long as it's working. This situation is ripe for this kind of threat, but I say this situation is already bad enough that this is just icing on the cake.
That's my whole point. You've already rooted the machine. You can do anything. The bug is irrelevant. You can just shut the database down. You can delete the cluster. Anything. This bug has nothing to do with it.
Your pre-packaged exploit is unable to use this bug to root the machine, and furthermore depends on the machine being rooted already to work. Not an exploit.
In order for this to be a problem, you already have to have failed at setting up a firewall or had compromised security elsewhere. I don't disagree with you in general, I'm just saying, this is not a security vulnerability, by the above.
I most certainly did not say that, and in order for that to be a consequence of my argument there would have to be a dependency on a pre-existing root exploit or other privilege escalation mechanism for stack smashing and SQL injection to work. But there isn't, which is what makes this completely different. You already need to have compromised security to use this bug to compromise security.
If half of you security morons would take enough CS to learn the tiniest bit of graph theory and find out what a DAG is, I wouldn't find myself having this argument constantly.
Every transaction that results in a change will increment the SCN, which is what the article is implying. This is a big part of databasery, so of course there will be unprivileged (i.e. non-admin) users who can increment the SCN through the usual manner of running transactions. My point is that with the ability to run transactions but without the ability to run ALTER DATABASE BEGIN BACKUP (i.e. a non-admin user with write access) it will be hard to beat ALTER DATABASE BEGIN BACKUP at the game of incrementing the SCN. Certainly if you are running that quantity of transactions, odds are good you are already DOSing the database without the SCN soft limit bug even being involved.
This right here is a great example of why I think software security as a field is largely bullshit. The amount of work and luck it would take to "exploit" this is such that by the time you've done it, you've already exploited all sorts of other things, including pre-existing poor security. It's not a security problem. Security is just a great way to get everyone's blood pumping.
I think man-made climate change is real. Unlike all your other talking points, there is actual evidence for it. Do note: your hippie friends play fast and loose with the facts to get bigger donations for their cause. They're building their political program on the back of your upper-class guilt that you'll do anything to alleviate. Fact-check yourself. Things aren't that bad.
I take it you didn't catch the episode of Penn & Teller's "Bulshit" on this one.
(Never seen this word "subborn" before.)
I read the article, and I must have missed mention of any other way than through ALTER TABLE BEGIN BACKUP to get the SCN to increment dramatically. I think it would be hard to do a better job than than Oracle's bug, which according to the article could achieve a rate of millions or billions of increments per second, by simply running a trivial transaction in a loop. Could it be done? Maybe, but that could be a lot of work.
Now, my impression is that this is a really obnoxious bug that will bite their highest paying customers disproportionally, but not that this is a particularly onerous security problem. The prerequisites for using this to perform a DOS are pretty big. Oracle's protocols are not particularly open. The SCN is buried in the database pretty deep; there's no way for an admin to directly access it. So you either have to trick an instance into manufacturing large values for you with a loop, or you'd have to reverse engineer the database link protocol. Even assuming you've done that, you having to insert yourself into the database's network. If you can afford enough Oracle licenses to run an Oracle cluster, you're probably paying for Oracle DBAs and systems administrators that know how to operate a firewall. Your Oracle is probably not listening on the public network. I'm saying that in all but the most pathologically embarrassing circumstances, you already have to own machines on this network to take down Oracle this way, which means your security was already breached before you could use this to breach the security.
What's going on here is actually MVCC. The idea here isn't to implement mutual exclusion so much as to ensure that concurrent writes can occur but nobody sees information outside their transaction; each transaction gets an ID assigned to it which is 1 + the previous transaction ID (in an idealized, serializable exclusion state) and your transaction can see any information with your ID or a lower (but committed) transaction ID. Transactions begun after yours can see your effects only after you've committed, and you can't see effects from transactions started after yours, even if they are committed.
Now, it's really only an "attack" if you have both 1) a way to inflate the number quickly and 2) small maximum values. It happens that these conditions are met with Oracle only because there's a bug in the hot backup facility, and the database link facility lets you pump the value across the cluster. This isn't a problem with PostgreSQL, because the version comparison uses modular arithmetic that permits wraparound and the VACUUM facility marks old transactions with an "older than everything" version that is special-cased in the comparison. So if the relationship between MVCC and the bakery algorithm is close, it wouldn't take a very big tweak to make the bakery algorithm resilient against this problem.
Supporting U2 for the "good" they did instead of the music they made is another thing wrong with the music industry today.
I love this idea. So there's some sort of government layer between scientists and their phones, email, blogs, and everything? That they have the infrastructure to cover this up successfully, but can't cover up when one of their own officials does one thing with one other person alone in a room in which they are the only two people? The people they'd be most interested in covering this up from are also the people who are the least likely to believe anything a scientist says anyway.
Absence of evidence is not evidence of absence. It's not pessimism, it's just acknowledging that one example isn't a pattern. To take away from it that the universe is teeming with life is reading just as much into the tiny scrap of evidence we have as saying there is no life. In general, when you can use the same evidence to make two equally strong yet completely contradictory arguments, you're better off just shutting up.
So with Brent as my witness, let's leave it at "well, dude, we just don't know."
Oh, I'm sorry, did I venture on-topic? Here, let me help you back onto your soapbox.
Why do you think all his friends and co-expatriates nervously suggested he leave sooner rather than later?
That is, of course, merely curtailing another fundamental human right to resettle. Beyond that, it was tried (and didn't work) for the USSR.
$120 * 2 = $240, not $3,000.
Isn't that enough? Isn't it enough motivation for a politician to do something if another politician accuses him of not doing something?
If it's enough to make the party change their minds about who they support, isn't it enough? If it's enough to send reporters scrambling through vault footage of the politician, isn't it enough? If it's enough to get the op-eds, talking heads and callers calling in, isn't it enough?