Sorry, the oversimplified version is confusing and misleading.
Text messages aren't sent as an extension to messages that would've been sent anyway. They're sent in contention with very important messages like "you have someone calling you", and if not carefully managed can overwhelm the capacity of the cell tower.
A cell tower's connection to the hard-wired telephone network has one "control channel" and multiple data/voice channels.
SMSes go on this control channel.
This one control channel is shared by everybody in the same cell as you. It carries important messages like "there's a phone call from +1234567890 incoming" or "user +1111111111 wants to call +1234567890".
The control channel has 64kbit/s of bandwidth available and has promises to deliver messages without delay and in order. It's an expensive way to send data compared to internet data routers (which don't promise to deliver anything or in any order).
So sure, back when signalling channels were mostly empty, people thought "why not put text messages on them". They now rue their decision and text messages' massive popularity overwhelms a signalling channel not really designed for them.
It's possible geohot could dump the public key metldr uses for verification, from any new metldr, but he won't be able to take multiple public keys where Sony used the same random number and turn them into the private key used for signing.
We have the signing key right now. We're unlikely ever to get that again.
Is this downgrade also dependent on metldr (or lower) being non-updatable?
Yes.
If geohotz hadn't given us the metldr private key, we could not sign our own firmware.
In that scenario, the lv1 revocation list hack would have been useful. It would allow us to install older Sony-signed firmwares that metldr trusts, but then skip the lv1 check that refuses older firmware. If we knew all private keys but metldr (which fail0verflow did), and Sony came out with an upgrade and we applied it, we could still downgrade at a later time to an official Sony firmware where we knew the private keys, despite the system Sony put in place to stop us doing that.
However, geohotz gave us the metldr private key, so we don't even need that. We just write our own firmware and sign it.
1) True, but doesn't make updating metldr impossible if Sony kept a copy.
2) True, but doesn't make updating metldr impossible if Sony kept a copy.
3) It is, but Sony are happy to make their customers' Windows PCs vulnerable to viruses in the name of DRM (XCP scandal). Even Nintendo were happy to brick Wiis in pursuit of locking out mods.
4) There's no reason why Sony can't have two separate paths: compromised firmware with old keys for offline updates, plus uncompromised firmware with new keys for online updates.
5) If the alternative is games and media publishers abandoning their platform, they now have the incentive to build the necessary infrastructure.
6) There is no currently known way, correct.
7) That's a very large "probably" and whether Sony can recover control of their platform hinges on it. If there's the slightest possibility they can do it, they will.
Hackers can change any new firmware as they wish and sign it again. This work can then be used by anyone who didn't install it.
If you do install any firmware after 3.55 (which Sony haven't released yet), it will likely a knock-out punch that changes all the keys, including metldr, so your PS3 will be impervious to all current softmodding and hardmodding techniques. And Sony will never inadvertently let slip their private keys again.
On the existing hardware a simple NOR/NAND replacement chip used for the initial boot but not the verifying stage can always be used to gain control and run old (thus hacked) loaders.
The revocation list is useless, but it does nothing to help us if metldr is updated with a new key and refuses to run something signed with the old key.
The revocation list's uselessness also does nothing for us today, because we have something even better - the current lv0/lv1/lv2 signing keys. This is what we will soon lose.
allow the old key for a whitelist of known past titles
Depending on how the whitelist was done, couldn't a softmodder just have his code say, "oh, yeah, I'm [some whitelisted game]. So use the old key for me"?
No. The signature verification stars by SHA-1 hash of the executable itself. This is what is "signed".
The whitelist would be a list of SHA-1 hashes.
SHA-1 is still secure, in that it's not possible in any reasonable time to work out which few bytes you would add to the end of your homebrew that would transform your homebrew's SHA-1 hash into one of the hashes on the list.
all Sony need to do is to pull their database...
That assumes that such a database exists, which isn't necessarily true. And if Sony is sending that data over the Internet, it's just a matter of poking around the updating code and listening to the netwiork traffic, and then the hackers could have Sony kindly supply them with the factory key of any system they have an identifyer for.
Not quite. This is what's called a collusion attack, and we don't know if it's possible with the encryption algorithm Sony used, because we don't know what algorithm they used (yet) - we haven't seen bootldr.
It would be nice to have a plaintext of metldr, but we don't have that - only George Hotz does, and even then I suspect he only has some of it, not all of it.
If Sony pre-encrypt all metldrs handed out, and all console-specific keys were random (i.e. not generated based on the serial number), there's no way to map serial number to console-specific key without Sony's database (presuming it exists).
If we can't work out the encryption used on metldr, and we can't get a plaintext of the updated metldr Sony hands out, then we can't reverse their encryption mechanism and therefore work out the console-specific key for any given console.
So, our only hope is to find out where the console specific key is stored, and to become able to extract it in future. Once we have that, we can encrypt our own metldr, which is easily accessible on the flash chip.
Furthermore, if we try and work out the encryption based on large numbers of requests to Sony's update servers, they potentially could detect us and start serving us phony updates, which would scupper our attempts (and would also entirely brick a PS3 if they mistook a genuine PS3 updating)
Sony could potentially stuff the genie back in the bottle.
The first step is a new firmware update, and make it mandatory to be allowed on the PSN. This will force the hand of most actual gamers. Perhaps there's even an option for Sony to force a firmware upgrade without user acceptance - we'll find out soon enough.
The firmware update will start verifying against a new Sony public key, and will only allow the old key for a whitelist of known past titles. So homebrewers can sign anything they like, but this new firmware won't run it.
Sony will start signing new titles with random numbers as well as the private key, so the private key remains private.
There goes softmodding.
"Ah", you say. "What about hardmodding? Because Sony can't update metldr with a firmware update, we can just rewrite the firmware on the flash chip, and metldr will accept our key, so we can change any stage of loading after bootldr/metldr."
But, you neglect that Sony could update metldr. The fail0verflow people said they couldn't, because they reasoned that as metldr is encrypted with a random key that's burned into the console at the factory, Sony couldn't update it en-masse. However, all Sony need to do is to pull their database of "what key was burned into each PS3 at the factory", and add code to their firmware that gets the PS3's serial number, sends it to Sony, and in return gets a firmware update already encrypted for that console.
metldr is only use to load firmware, which Sony never allows downgrades on, so it only needs to accept the new signature on firmware, not the old one. Now homebrewers and pirates are SOL, there's not even a hardhack that'll work.... unless you avoid Sony's network like the plague from this moment on, until modders come up with a fake update that convinces Sony you've upgraded, but you haven't really.
Meanwhile, in the factory, they keep on making PS3s but they change the firmware signing key. That's all that's needed.
But let's use it as a hypothetical. What if a suspect in Sweden, who was involved in publishing U.S. government leaks online, brutally attacked and raped (by all nations' definitions) a Swedish woman and fled to the U.K.?
Hypothetically, Sweden would then immediately press charges against the suspect as they would have solid evidence of wrongdoing. They would attempt to arrest the suspect as soon as possible. They could stop the suspect leaving the country immediately - he certainly couldn't get on a regular plane and leave.
The hypothetical Sweden would not drop the charges the next morning.
The hypothetical suspect would not have to phone the police himself a few weeks later to ask permission to leave the country.
The hypothetical prosecutor would not give that permission.
The hypothetical Sweden wouldn't have an elected politician/lawyer who stands to gain from political stunts and has a history of trying to change the rape laws in Sweden, volunteering to take up a highly disputed case and using a mechanism designed to arrest wanted criminals for no more than an interview, without pressing any charges, meanwhile not bothering to interview the victim who has since gone on holiday because it's his opinion that the victim can't decide if she's been raped, only the state can.
Apart from that, yes hypothetically the UK can extradite the hypothetical suspect.
Better than that. In OpenGL, you say "give me this vendor-specific feature" you get it. Programmers have used this to get at the latest features of chipsets long before they're standardized.
OpenGL programmers are always ahead of DirectX, even in this case where the hardware directly targets future DirectX specs.
It's like using -moz-border-radius, -webkit-border-radius and -khtml-border-radius to get CSS3 rounded borders long before CSS3 is officially released, and yet CSS3 won't be beholden to any one browser's implementation.
Ok, the PS3 was launched on November 11, 2006. [wikipedia.org] Today's date is December 29, 2010. That means that it took over four years to be broken.
No, it took 8 months to be broken.
The Other OS functionality of the PS3 was unilaterally removed by Sony on April 1st 2010. The years before are of no importance, because you could freely boot Linux. Nobody who had the skills to crack the PS3 even bothered to look.
When they removed Other OS, Sony signed their own fucking death warrant.
Re:The writing was idiotic (Spoilers?)
on
Tron: Legacy
·
· Score: 1
#2: You're complaining that some things in the computer world were represented literally instead of metaphorically or as a pixelated analogue. Ah bloo bloo bloo bloo bloo.
The simulated computer world can do anything. ANYTHING. Look at the other computer-simulated-world movie, The Matrix where they hang a lampshade on it; "you think that's air you're breathing?". The characters defy real world physics with impunity.
In the original Tron, and reappearing in this one for nostalgia's sake, there are physics-defying constructs like the two-legged aircraft carrier and the solar sailship. This is what Tron was about - a computer world that is radically different to our own; it doesn't behave like reality because it's not reality.
So, given that, why the fuck do we have data-planes escaping their pursuers by doing stall turns? Something that only happens when you have gravity and air?
It's this schizophrenic mix of physics-ignoring nostalgia with physics-dependent New Content that irks me particularly. It's like there were two directors, one who was trying to copy the original Tron as authentically as possible, and one who was trying to cram in as much CGI physics as possible, and didn't know or care that the Tron world is meant to appear artificial.
The TSA's measures are worse than useless: they actually create a hazard, with long, slow-moving, densely-packed lines full of by-definition unscreened persons--lines that are about the ripest target for a bomb that you can find.
I've been thinking about that for years, but never said anything because I didn't want to give anyone any ideas.
People already have the idea and are making drama out of it. In Iain Banks' Transition, a Christian terrorist blows up a packed security line at the airport while guards up ahead are trying to take some nail clippers off a granny.
But while it's undefended right now, and you're at risk from it, it's not a threat the US needs to guard against, because no Islamists have tried it yet.
You can commit any act of terrorism in the US you like, it won't matter unless you're an Islamist, which is to say you have a beard and a funny hat. You can shoot up your local mall or campus, and that'll just be "a tragedy" and it will be forgotten by the next day, nobody will do anything about it. But if the TV reports a Mooslim even thought about blowing something up, the nation collectively loses its shit, so Something Gets Done, right there and then, no matter how hilariously improbable.
So, why don't Mooslims attack the US? Because most of them aren't terrorists, and the handful that are are either satisfied with what they've wrought so far (remember that Osama achieved his main goal of getting the US military out of Saudi Arabia, he only has one goal left - getting the US money out of Israel), or they're still scratching their heads as to how up the ante after 9/11. Tough job, and it will have to involve getting on a plane with a bomb, because that's what the US public are focused on and fear most.
Terrorists don't score points just on how many people they kill - they could just do a coordinated rampage in some shopping malls to top the 9/11 hiscore - but they score points on how spectacular and audacious their successful plots are. We're still fixated on exploding or hijacked transit, so that's what they have to aim for.
In Israel, however, the terrorists have lower standards. They'd get nationwide media coverage for killing any Israelis at all, so the murderous bastards are everywhere. Left the back door open? BOOM! Didn't eat your greens? BOOM! Terrorist hiding under the broccoli.
When you have a real threat, from groups who will accept any amount of death as a success, not just Bond movie plots, then you need to be far more focused. The US doesn't have a real threat, so it can keep deluding itself with security theater.
Well, this one example does look pretty copied. Sun wrote sun.security.provider.certpath.PolicyNodeImpl - notice it's fully documented, and authored by Seth Proctor and Sean Mullan. It's not part of the standard Jaa library, it's part of the JVM's private implementation, and was released later on as part of OpenJDK.
However, this code isn't central to Android. It's part of the test suite, it doesn't run on any phones.
On the one hand - this looks like a cut and dried infringement. On the other hand, it's a pretty trivial part of the project. Is that the best Oracle can find? If it is, then it's on a par with SCO holding up malloc.h as the "smoking gun".
Programmer time costs more than machine time in almost all cases. Why have programmers reinventing the wheel when you can have a library of well tested code to cover most of what programmers need to write?
Oracle makes 90% of its profits from support contracts renewals. Customers renew to get continued support for whatever Oracle sold them, and to get access to the newer versions. We'd have to ask them to get actual numbers, but say x% renew because they want support/upgrades for Oracle DB, y% renew because they want support/upgrades for some enterprise app, surely z% renew because they want support/upgrades for JVM/Netbeans/some other Java bollocks.
Google hasn't got a case, they used what is now Oracle's trademark to refer to something that isn't the Java language as the Java language. The best Google can do is settle it out of court.
Android uses the Java language. When writing Android applications, you write code in the Java language and compile it, with Sun/Oracle's Java compiler, into Java bytecode.
Then you convert the Java bytecode to Dalvik bytecode and run it on the Dalvik VM with the Harmony class library, which is also Java language code that has been compiled to Java bytecode and converted to Dalvik bytecode.
Note:
"Java language" used correctly, not misrepresented.
"Java Virtual Machine" not used by Google.
Dalvik VM cannot load Java bytecode, ergo doesn't even implement a Java Virtual Machine.
"Java class library" not used by Google.
"Java compatibility test suite" not used by Google. Harmony class library and Dalvik VM would fail that test suite anyway, as they don't fully implement the Java class library not have the ability to load Java bytecode.
Congratulations, you're wrong on all counts! Good job you're not on Oracle's legal team.
Slashdot Mirror
Sorry, the oversimplified version is confusing and misleading.
Text messages aren't sent as an extension to messages that would've been sent anyway. They're sent in contention with very important messages like "you have someone calling you", and if not carefully managed can overwhelm the capacity of the cell tower.
A cell tower's connection to the hard-wired telephone network has one "control channel" and multiple data/voice channels.
SMSes go on this control channel.
This one control channel is shared by everybody in the same cell as you. It carries important messages like "there's a phone call from +1234567890 incoming" or "user +1111111111 wants to call +1234567890".
The control channel has 64kbit/s of bandwidth available and has promises to deliver messages without delay and in order. It's an expensive way to send data compared to internet data routers (which don't promise to deliver anything or in any order).
So sure, back when signalling channels were mostly empty, people thought "why not put text messages on them". They now rue their decision and text messages' massive popularity overwhelms a signalling channel not really designed for them.
It's possible geohot could dump the public key metldr uses for verification, from any new metldr, but he won't be able to take multiple public keys where Sony used the same random number and turn them into the private key used for signing.
We have the signing key right now. We're unlikely ever to get that again.
Is this downgrade also dependent on metldr (or lower) being non-updatable?
Yes.
If geohotz hadn't given us the metldr private key, we could not sign our own firmware.
In that scenario, the lv1 revocation list hack would have been useful. It would allow us to install older Sony-signed firmwares that metldr trusts, but then skip the lv1 check that refuses older firmware. If we knew all private keys but metldr (which fail0verflow did), and Sony came out with an upgrade and we applied it, we could still downgrade at a later time to an official Sony firmware where we knew the private keys, despite the system Sony put in place to stop us doing that.
However, geohotz gave us the metldr private key, so we don't even need that. We just write our own firmware and sign it.
To deny us, Sony now have to alter metldr.
Nice post!
1) True, but doesn't make updating metldr impossible if Sony kept a copy.
2) True, but doesn't make updating metldr impossible if Sony kept a copy.
3) It is, but Sony are happy to make their customers' Windows PCs vulnerable to viruses in the name of DRM (XCP scandal). Even Nintendo were happy to brick Wiis in pursuit of locking out mods.
4) There's no reason why Sony can't have two separate paths: compromised firmware with old keys for offline updates, plus uncompromised firmware with new keys for online updates.
5) If the alternative is games and media publishers abandoning their platform, they now have the incentive to build the necessary infrastructure.
6) There is no currently known way, correct.
7) That's a very large "probably" and whether Sony can recover control of their platform hinges on it. If there's the slightest possibility they can do it, they will.
Hackers can change any new firmware as they wish and sign it again. This work can then be used by anyone who didn't install it.
If you do install any firmware after 3.55 (which Sony haven't released yet), it will likely a knock-out punch that changes all the keys, including metldr, so your PS3 will be impervious to all current softmodding and hardmodding techniques. And Sony will never inadvertently let slip their private keys again.
On the existing hardware a simple NOR/NAND replacement chip used for the initial boot but not the verifying stage can always be used to gain control and run old (thus hacked) loaders.
No. You're referencing this: http://www.youtube.com/watch?v=eVXfgg7otJw#t=31m18
The revocation list is useless, but it does nothing to help us if metldr is updated with a new key and refuses to run something signed with the old key.
The revocation list's uselessness also does nothing for us today, because we have something even better - the current lv0/lv1/lv2 signing keys. This is what we will soon lose.
From the reddit comment:
There is absolutely nothing Sony can do short of updating metldr
Correct. My contention is that Sony can update metldr, over the internet, without revealing its encryption key.
It is probably revocable.
allow the old key for a whitelist of known past titles
Depending on how the whitelist was done, couldn't a softmodder just have his code say, "oh, yeah, I'm [some whitelisted game]. So use the old key for me"?
No. The signature verification stars by SHA-1 hash of the executable itself. This is what is "signed".
The whitelist would be a list of SHA-1 hashes.
SHA-1 is still secure, in that it's not possible in any reasonable time to work out which few bytes you would add to the end of your homebrew that would transform your homebrew's SHA-1 hash into one of the hashes on the list.
all Sony need to do is to pull their database...
That assumes that such a database exists, which isn't necessarily true. And if Sony is sending that data over the Internet, it's just a matter of poking around the updating code and listening to the netwiork traffic, and then the hackers could have Sony kindly supply them with the factory key of any system they have an identifyer for.
Not quite. This is what's called a collusion attack, and we don't know if it's possible with the encryption algorithm Sony used, because we don't know what algorithm they used (yet) - we haven't seen bootldr.
It would be nice to have a plaintext of metldr, but we don't have that - only George Hotz does, and even then I suspect he only has some of it, not all of it.
If Sony pre-encrypt all metldrs handed out, and all console-specific keys were random (i.e. not generated based on the serial number), there's no way to map serial number to console-specific key without Sony's database (presuming it exists).
If we can't work out the encryption used on metldr, and we can't get a plaintext of the updated metldr Sony hands out, then we can't reverse their encryption mechanism and therefore work out the console-specific key for any given console.
So, our only hope is to find out where the console specific key is stored, and to become able to extract it in future. Once we have that, we can encrypt our own metldr, which is easily accessible on the flash chip.
Furthermore, if we try and work out the encryption based on large numbers of requests to Sony's update servers, they potentially could detect us and start serving us phony updates, which would scupper our attempts (and would also entirely brick a PS3 if they mistook a genuine PS3 updating)
This is Sony we're talking about. They don't know the meaning of the word "ethical".
Sony could potentially stuff the genie back in the bottle.
The first step is a new firmware update, and make it mandatory to be allowed on the PSN. This will force the hand of most actual gamers. Perhaps there's even an option for Sony to force a firmware upgrade without user acceptance - we'll find out soon enough.
The firmware update will start verifying against a new Sony public key, and will only allow the old key for a whitelist of known past titles. So homebrewers can sign anything they like, but this new firmware won't run it.
Sony will start signing new titles with random numbers as well as the private key, so the private key remains private.
There goes softmodding.
"Ah", you say. "What about hardmodding? Because Sony can't update metldr with a firmware update, we can just rewrite the firmware on the flash chip, and metldr will accept our key, so we can change any stage of loading after bootldr/metldr."
But, you neglect that Sony could update metldr. The fail0verflow people said they couldn't, because they reasoned that as metldr is encrypted with a random key that's burned into the console at the factory, Sony couldn't update it en-masse. However, all Sony need to do is to pull their database of "what key was burned into each PS3 at the factory", and add code to their firmware that gets the PS3's serial number, sends it to Sony, and in return gets a firmware update already encrypted for that console.
metldr is only use to load firmware, which Sony never allows downgrades on, so it only needs to accept the new signature on firmware, not the old one. Now homebrewers and pirates are SOL, there's not even a hardhack that'll work.... unless you avoid Sony's network like the plague from this moment on, until modders come up with a fake update that convinces Sony you've upgraded, but you haven't really.
Meanwhile, in the factory, they keep on making PS3s but they change the firmware signing key. That's all that's needed.
Even if it means facing the rape charges
There aren't any rape charges. There are no charges. Sweden wants to forcibly extradite him simply to question him. A phone call would do.
But let's use it as a hypothetical. What if a suspect in Sweden, who was involved in publishing U.S. government leaks online, brutally attacked and raped (by all nations' definitions) a Swedish woman and fled to the U.K.?
Hypothetically, Sweden would then immediately press charges against the suspect as they would have solid evidence of wrongdoing. They would attempt to arrest the suspect as soon as possible. They could stop the suspect leaving the country immediately - he certainly couldn't get on a regular plane and leave.
The hypothetical Sweden would not drop the charges the next morning.
The hypothetical suspect would not have to phone the police himself a few weeks later to ask permission to leave the country.
The hypothetical prosecutor would not give that permission.
The hypothetical Sweden wouldn't have an elected politician/lawyer who stands to gain from political stunts and has a history of trying to change the rape laws in Sweden, volunteering to take up a highly disputed case and using a mechanism designed to arrest wanted criminals for no more than an interview, without pressing any charges, meanwhile not bothering to interview the victim who has since gone on holiday because it's his opinion that the victim can't decide if she's been raped, only the state can.
Apart from that, yes hypothetically the UK can extradite the hypothetical suspect.
Minecraft uses LWJGL, the lightweight Java game library, which in turn uses OpenGL.
A better graphics card, or better graphics driver, will render Minecraft better.
Better than that. In OpenGL, you say "give me this vendor-specific feature" you get it. Programmers have used this to get at the latest features of chipsets long before they're standardized.
OpenGL programmers are always ahead of DirectX, even in this case where the hardware directly targets future DirectX specs.
It's like using -moz-border-radius, -webkit-border-radius and -khtml-border-radius to get CSS3 rounded borders long before CSS3 is officially released, and yet CSS3 won't be beholden to any one browser's implementation.
Ok, the PS3 was launched on November 11, 2006. [wikipedia.org] Today's date is December 29, 2010. That means that it took over four years to be broken.
No, it took 8 months to be broken.
The Other OS functionality of the PS3 was unilaterally removed by Sony on April 1st 2010. The years before are of no importance, because you could freely boot Linux. Nobody who had the skills to crack the PS3 even bothered to look.
When they removed Other OS, Sony signed their own fucking death warrant.
#2: You're complaining that some things in the computer world were represented literally instead of metaphorically or as a pixelated analogue. Ah bloo bloo bloo bloo bloo.
The simulated computer world can do anything. ANYTHING. Look at the other computer-simulated-world movie, The Matrix where they hang a lampshade on it; "you think that's air you're breathing?". The characters defy real world physics with impunity.
In the original Tron, and reappearing in this one for nostalgia's sake, there are physics-defying constructs like the two-legged aircraft carrier and the solar sailship. This is what Tron was about - a computer world that is radically different to our own; it doesn't behave like reality because it's not reality.
So, given that, why the fuck do we have data-planes escaping their pursuers by doing stall turns? Something that only happens when you have gravity and air?
It's this schizophrenic mix of physics-ignoring nostalgia with physics-dependent New Content that irks me particularly. It's like there were two directors, one who was trying to copy the original Tron as authentically as possible, and one who was trying to cram in as much CGI physics as possible, and didn't know or care that the Tron world is meant to appear artificial.
Thanks for all that elitist bullshit about how stupid the commoners are
Please go read some Youtube comments and Yahoo! Answers! for an hour.
Hi David,
I'm pretty sure you're in the UK. Here are some of Amazon.co.uk's rivals, who also do delivery:
It's as simple as ordering from Amazon's rivals instead of Amazon. You don't even need to move from your seat!
Isn't internet capitalism grand?
Most companies dont care to cater to their competition, its not fear its logic.
Most companies don't try and control what you can see and do with their products after you've bought them. Apple do. This is what we are criticising.
The TSA's measures are worse than useless: they actually create a hazard, with long, slow-moving, densely-packed lines full of by-definition unscreened persons--lines that are about the ripest target for a bomb that you can find.
I've been thinking about that for years, but never said anything because I didn't want to give anyone any ideas.
People already have the idea and are making drama out of it. In Iain Banks' Transition, a Christian terrorist blows up a packed security line at the airport while guards up ahead are trying to take some nail clippers off a granny.
But while it's undefended right now, and you're at risk from it, it's not a threat the US needs to guard against, because no Islamists have tried it yet.
You can commit any act of terrorism in the US you like, it won't matter unless you're an Islamist, which is to say you have a beard and a funny hat. You can shoot up your local mall or campus, and that'll just be "a tragedy" and it will be forgotten by the next day, nobody will do anything about it. But if the TV reports a Mooslim even thought about blowing something up, the nation collectively loses its shit, so Something Gets Done, right there and then, no matter how hilariously improbable.
So, why don't Mooslims attack the US? Because most of them aren't terrorists, and the handful that are are either satisfied with what they've wrought so far (remember that Osama achieved his main goal of getting the US military out of Saudi Arabia, he only has one goal left - getting the US money out of Israel), or they're still scratching their heads as to how up the ante after 9/11. Tough job, and it will have to involve getting on a plane with a bomb, because that's what the US public are focused on and fear most.
Terrorists don't score points just on how many people they kill - they could just do a coordinated rampage in some shopping malls to top the 9/11 hiscore - but they score points on how spectacular and audacious their successful plots are. We're still fixated on exploding or hijacked transit, so that's what they have to aim for.
In Israel, however, the terrorists have lower standards. They'd get nationwide media coverage for killing any Israelis at all, so the murderous bastards are everywhere. Left the back door open? BOOM! Didn't eat your greens? BOOM! Terrorist hiding under the broccoli.
When you have a real threat, from groups who will accept any amount of death as a success, not just Bond movie plots, then you need to be far more focused. The US doesn't have a real threat, so it can keep deluding itself with security theater.
Well, this one example does look pretty copied. Sun wrote sun.security.provider.certpath.PolicyNodeImpl - notice it's fully documented, and authored by Seth Proctor and Sean Mullan. It's not part of the standard Jaa library, it's part of the JVM's private implementation, and was released later on as part of OpenJDK.
Google have exactly this same code, minus the comments in their copy of Apache Harmony, but it's not in the official Apache Harmony, at least since 2005 (Don't believe me? Run svn log -v http://svn.apache.org/repos/asf/harmony | grep PolicyNodeImpl).
However, this code isn't central to Android. It's part of the test suite, it doesn't run on any phones.
On the one hand - this looks like a cut and dried infringement. On the other hand, it's a pretty trivial part of the project. Is that the best Oracle can find? If it is, then it's on a par with SCO holding up malloc.h as the "smoking gun".
Programmer time costs more than machine time in almost all cases. Why have programmers reinventing the wheel when you can have a library of well tested code to cover most of what programmers need to write?
Oracle makes 90% of its profits from support contracts renewals. Customers renew to get continued support for whatever Oracle sold them, and to get access to the newer versions. We'd have to ask them to get actual numbers, but say x% renew because they want support/upgrades for Oracle DB, y% renew because they want support/upgrades for some enterprise app, surely z% renew because they want support/upgrades for JVM/Netbeans/some other Java bollocks.
Google hasn't got a case, they used what is now Oracle's trademark to refer to something that isn't the Java language as the Java language. The best Google can do is settle it out of court.
Android uses the Java language. When writing Android applications, you write code in the Java language and compile it, with Sun/Oracle's Java compiler, into Java bytecode.
Then you convert the Java bytecode to Dalvik bytecode and run it on the Dalvik VM with the Harmony class library, which is also Java language code that has been compiled to Java bytecode and converted to Dalvik bytecode.
Note:
Congratulations, you're wrong on all counts! Good job you're not on Oracle's legal team.