Why is it that the users of these devices demand that they *not* be able to get the key?
To the extent they do demand that (and it is true by some interpretations), it is so that nobody can see the key. The reason they don't want to be able to see it is so that they won't screw up and accidently expose it to an enemy.
But regarding TCPA, that's a moot point. Outsiders already have the key.
TCPA is not a competitor to the RSA PKI products. If you want products to enhance your security, they are already for sale.
Schemes relying on quantum entanglement are so different from "traditional" Quantum Encryption (which is based more on Heisenberg Uncertainty) that it should really go by a different name. I have seen the entanglement-based approach labelled "Quantum Teleportation", although that term misleadingly creates too-high expectations.
Re the implementation query you have, I think that philosphically, an algorithm cannot be separated from its implementation.
Indeed, it can't be. That's why an "incorrect implementation of algorithim XYZ" is a different algorithim than an error-free version. If you open my door which I left unlocked, you have not disproved any any of the lock-vendor's claims that it is unpickable.
AC: In quantum cryptography (which isn't quite what this article is about), there aren't any data lines to monitor -- the information is transmitted by entanglement.
No, your definitions are off. "Quantum Cryptography" is the use of Heisenberg's Uncertainty principle's guarantee that the whole state of a particle cannot be measured to ensure that a message cannot be intercepted and retransmitted.
The use of quantum entanglement to communicate data has also been proposed, but this is known as Quantum Teleportation. QT, not QC.
Among all of the high-security crypto devices on the market, the devices used by banks, by government agencies, by corporate PKI systems, every single one of them has a master key which is generated inside the device and never, ever divulged.
Can you tell the difference between "never, ever divulged" and "held in a lab in California for use by the MPAA"?
There is no sane comparison between a key which exists ONLY inside the tamper-proof hardware wherein it was created, and a key secretly held in escrow by a 3rd party whose goals might differ dramatically from those of the hardware's current owner.
Why is it that none of those entities, the device makers and the device buyers, want to be able to get those keys out of the devices, to have a copy for "safekeeping"?
That's a misleading question. If the device buyers want additional keys for safekeeping, they have no need to extract them from the device- they can simply request additional copies at the time of purchase. The man holding the key obeys the legal owner of the hardware.
The situation is entirely different with Trusted Computing, because the buyer of a personal computer will not be able to ask the salesman for a printed copy of the key along with purchase. The man holding the key refuses to talk to the legal owner of the hardware.
I've tried repeatedly in the past to get you to understand the intrinsic security value of never-revealed keys, and the fact that the flexibility obtained by extracting keys is practically nil.
"Extracting keys" is not the point. Someone working for the bank has the key at some point and signs their stuff. If no agent of the bank could EVER get the key AT ALL, then they'd move to another hardware vendor.
In fact, although the bank might be happy if the key is destroyed just as soon as the few important things are signed with it, they absolutely wouldn't enjoy the idea of a music executive sitting around with the keys to their data.
Thankfully a scheme like this can't work, too many secrets to keep.
I think it can definitely work, needing only a 20% expansion in the jackbooted-thug workforce to prevent dissemation of hardware-circumvention techniques. Hardware-hacker nerds aren't brave- all it takes is two or three stomped necks, and they slink away.
Simply point out that breaking Trusted Computing helps terrorists, and the police will FIND a way to protect the Security of TCPA, for the Freedom of the Homeland.
Too bad you're still down on 3 and not 5. Came in late I guess. I wish there was a way to flag a post as a reply to 5-10 different erroneous messages at once.
That is really the sole point of genuine contention - whether an owner can know his own master key.
Looking at the other messages on this topic, there is a ton of delusion circulating on that point. The corporate PR departments are earning their paychecks.
It would probably be wise for the various anti-TCPAwebsites to emphasize this one fact more strongly. The Trusted Computing boosters have been quite effective at diverting the conversation to assorted side bonuses like preventing worms and keyloggers, and often well-meaning people who just want to see better designed desktop OSes (more granular permissions, sandboxing, etc) defend TCPA of of ignorance of the fundamental fact that users don't get the key.
It is possible, but not easy. The whole point is that each photon carries 2 bits of those data, and only one bit can be measured before the photon is destroyed. A middleman wouldn't know which of those two bits he needs to transmit. So he must guess, and half the time he gets it wrong, so the data is 50% corrupted, and the reciever knows something is very wrong.
However, if the middleman had previously broken into the reciever's office, he could've copied down the list of which bit on each photon is important, and then he could go back to the spy room and wait to run the attack on the next transmission.
(Of course, if the guy can break into the office, why doesn't he just steal disks while he's there?)
It doesn't attempt to deal with it at all. QC requires you to have a straight "wire" (or diamondlike carbon filament, or other cable) between the sender and reciever. If anyone were to attempt an evasdropping attack, he'd have to be able to touch the wire. And if he can touch it, it's fairly simple for him to cut it in half. Bang, total denial.
It's not a code, because a code could be applied to many scenarios like protecting individual hard drives or internet websites.
In fact, the installation costs of QC make it seem almost totally useless. Who can imagine two people wanting to talk secretly so dearly that they will lay a customized and very expensive new cable between their two offices? It'd have to be a critical military project to justify the expense- except that the military won't want it, because it's too vulnerable to sabotage with a shovel at one point in the middle. (Conventional internet is harder to sabotage, by comparison, because damage can be routed around)
False positive intrusions.
They would have measured the expected error rate, and an intrusion would create an error rate of twice that. It should be noted that when QC "detects eavesdropping", it's not that an "Intruder Detected" lightbulb goes on, but rather you notice that your data flow has stopped entirely, or has been changed to random noise, which means either an intruder or a cable failure.
Reliability without retransmission.
It does not attempt to deal with it. There will be unreliablilty, and it will be addressed with retransmission, as modern network protocols do already.
There simply is no way to perform a "charlie" attack (charlie denoting a third user, after Alice and Bob).
No, there is a way. But most QC advocates skip over that possibility, because the vulnerability only exists before they start going through the usual list of steps.
QC requires sender and reciever to know a list of which attributes of each particle is supposed to be read, and which should be discarded. If the middle-man doesn't have this list, he can't read their data and pass it along, because he doesn't know which of the attribute is the important one on each photon.
But that all assumes he doesn't have the list, which you can't be sure of, because it had to be conveyed by some other channel, which might have been quite vulnerable to spying. An opponent who has the list of significant polarizations can read the message and then retransmitt it just like the original sender did.
The funny part is, QC isn't even a good solution to key distribution.
Furthermore, to use QC for key distribution, you already need to have distributed a shared key beforehand! Search for "secret bit string is agreed to" or "a public, but authenticated, channel" in the QC wikipedia page to see what I mean.
Using QC to make an untamperable communication requires you to already have some other comm channel which is already trusted as untamperable- and if you had that, why not just send the keys on it in the first place? (Possible answer is that you can carry a small key on the first, expensive channel, and then use QC for all your later keys for many years. But it'll be a long long time before QC's cost compares favorably to 5 armed guards escorting a briefcase into a jet plane)
I'm afraid not. In fact, when you push things really really hard, they don't fall over at all. Why, I saw this radio antenna that has 21,000,000 pounds of force applied to it, and not only didn't it fall over, but it zoomed off into the sky and hasn't been seen since.
No, wrong. Why wrong? Because you disprove yourself in the very next sentence:
It uses the encryption system known as the One Time Pad.
If it USES an encryption system, then it IS NOT an encryption system. In the same way, a desktop PC is not a RAM chip, and a Toyota Corolla not a six-cylinder engine.
Quantum "encryption" is no better (or worse) than regular encryption.
True, it's not better than encryption- because QE, as your use of scare-quotes apparently alludes to, is not encryption at all.
a simple oversight in the implementation can render you're algorithm breakable.
That is an inadequate justification for the claim "everything can be hacked". If an oversight in implementation means you can be hacked, it doesn't follow that the algorithm is breakable- but only that you were never really using that algorithm at all.
I wait in both instances, except now my KDE startup takes longer because it's doing other crap in the background.
That will rarely be true.
The extra time is probably unmeasurable, since it's primarily from IO-bound processes, which would have no contention with what you're doing.
When booting Red Hat Linux, it's not abnormal for individual network service processes to halt for more than TWO MINUTES if the network is down and they can't find their domain servers. This improvement will allow the user to login and start finishing work on locally-stored files quicker. I should not have to wait for apache, postfix, and ypbind to finish before I can check my email!
A superior generalization of this idea would be to parellize daemon startup across the board.
I turn on the computer. I go to the bathroom. I get up and go get a drink, and when I come back it's ready to use.
Wrong. You come back and its only ready to login, not really use. You then must wait an additional time period as Gnome / KDE goes through all of it's initialization...
If you could have pre-buffered your login info immediately on power-on, and then went to the beverage fountain, the total delay would come closer to the best-case you imagined.
To the degree that it becomes default Red Hat behavior, it's something that I'm forced to deal with, or at least to actively disable.
That would only be true if you had some reason to ever want to disable this. I surely can't think of anything bad about it.
2) Try Windows XP and tell me how much faster things get done when your system is completely unresponsive.
There are few systems less responsive than Red Hat Linux as it's still loading 10 different network servers, some of which block on DHCP and DNS.
Moving GDM ahead in the startup sequence allows more parrelization. The user can type her password at the same time background daemons are initializing, instead of waiting for all those daemons to finish before the computer becomes interactive. It's better for everyone.
"Never block the UI" is hardly a controversial design rule.
If you hash all application software into the TPM state, no new software can be added without changing the hash. If you hash only selected software, the user can simply use something else, unless you lock down the system to prevent all software installation.
Both true, both irrelevant.
. Please describe the mechanism, based on the features provided by a TCPA TPM.
How about the PSP viewing movies and playing music being innovative?
Movies and pop music have nothing at all to do with games. It's possible they could succeed in the marketplace, but that marketplace is (by definition) not "gaming".
(By a similar token, Apple's ipod and itunes lines might help the profit margins, but the move the company away from being about "computers" any more)
Insufficient to reproduce the gameplay. "Telekinesis" as used here means that objects anywhere on the screen can be immediately targeted by the player.
One could attempt to emulate this effect using either a joystick or a mouse which moves around a cursor to pick the target, but that will irreperably change the gameplay. It is SO much easier to select a position with a touchscreen than with a mouse, and joysticks are even worse.
For an existing example, look at Counter-Strike. It was intented to be played with a mouse, and all the game balancing was made with that assumption. If you play with a joystick, it will be impossibly hard and no fun. If you play with a touch screen, it will be laughably easy and no fun either. (People who enjoy running an aimbot are exceptions, as their notion of "fun" comes from a different convention)
Assuming you are a genius, or at least highly intelligent, then you can teach yourself software CS alone in your home for just $300 worth of textbooks.
To properly learn hardware CE, on the other hand, requires both bulky, expensive lab equipment (or emulators and CAD that are merely expensive), and more importantly, mentoring from someone already in the field. Because of the Free Software movement, there are many professional-level software projects whose development process and changing source code are open for public view, so you can watch and learn whenever you like.
Hands-on experience with hardware design can't be plucked off the internet for free like that, so it's a better way to invest your tuition penny.
You know that Gates used to be a Clinton groupie? He posed for a lot of photo-ops at social events, etc. It was only after he woke up one morning and noticed that his corporation was a gigantic illegal monopoly that he switched over to the party of Big Business.
The only real effect that rule can have is to slow down the rate of salary decreases, not stop it. H1Bs can always be hired for the lower-end of the prevailing scale (for justifiable reasons, such as that their worse English skills make them less productive employees).
Then next year, the prevailing wage has gone down because it now includes all those H1Bs (and local workers competing with them). Over enough time, you reach the same point as if the rule had never existed at all.
AC: But for systems that are switches or teller machines or heart monitors or guidance control systems for a missle or some other device, they use trusted computing for very good reason.
Nope. On those systems, there is no reason for Trusted Computing at all. Only one person will be allowed to install program on them, and she will do it only very rarely- probably just once, in the factory when the missile is built. Mission critical embedded systems like those server exactly one owner; but Trusted Computing is about making PCs also serve corporations aside from the owner of the hardware.
Devices like that don't connect to the public internet, and they don't view media files written by other people. They are a black box, and almost nothing gets in or out.
Trusted Computing is irrelevant to a situation like that, unless the system admin is so dangerously incompetent that he needs an extra failsafe to keep him from installing malware on a warhead.
Linux will not restrict what you can do itself. The kernel will never work against you.
If that's true- and it might be- then Linux will never be able to view the majority of content end-users need to see. Most of the nascent free software world, especially as pertaining to desktop PCs, will be absolutely crippled.
If you buy a video online, any problems you have are the fault of the company from which you bought the video.
Slashdot Mirror
Why is it that the users of these devices demand that they *not* be able to get the key?
To the extent they do demand that (and it is true by some interpretations), it is so that nobody can see the key. The reason they don't want to be able to see it is so that they won't screw up and accidently expose it to an enemy.
But regarding TCPA, that's a moot point. Outsiders already have the key.
TCPA is not a competitor to the RSA PKI products. If you want products to enhance your security, they are already for sale.
quantum entanglements
Schemes relying on quantum entanglement are so different from "traditional" Quantum Encryption (which is based more on Heisenberg Uncertainty) that it should really go by a different name. I have seen the entanglement-based approach labelled "Quantum Teleportation", although that term misleadingly creates too-high expectations.
Re the implementation query you have, I think that philosphically, an algorithm cannot be separated from its implementation.
Indeed, it can't be. That's why an "incorrect implementation of algorithim XYZ" is a different algorithim than an error-free version. If you open my door which I left unlocked, you have not disproved any any of the lock-vendor's claims that it is unpickable.
AC: In quantum cryptography (which isn't quite what this article is about), there aren't any data lines to monitor -- the information is transmitted by entanglement.
No, your definitions are off. "Quantum Cryptography" is the use of Heisenberg's Uncertainty principle's guarantee that the whole state of a particle cannot be measured to ensure that a message cannot be intercepted and retransmitted.
The use of quantum entanglement to communicate data has also been proposed, but this is known as Quantum Teleportation. QT, not QC.
Among all of the high-security crypto devices on the market, the devices used by banks, by government agencies, by corporate PKI systems, every single one of them has a master key which is generated inside the device and never, ever divulged.
Can you tell the difference between "never, ever divulged" and "held in a lab in California for use by the MPAA"?
There is no sane comparison between a key which exists ONLY inside the tamper-proof hardware wherein it was created, and a key secretly held in escrow by a 3rd party whose goals might differ dramatically from those of the hardware's current owner.
Why is it that none of those entities, the device makers and the device buyers, want to be able to get those keys out of the devices, to have a copy for "safekeeping"?
That's a misleading question. If the device buyers want additional keys for safekeeping, they have no need to extract them from the device- they can simply request additional copies at the time of purchase. The man holding the key obeys the legal owner of the hardware.
The situation is entirely different with Trusted Computing, because the buyer of a personal computer will not be able to ask the salesman for a printed copy of the key along with purchase. The man holding the key refuses to talk to the legal owner of the hardware.
I've tried repeatedly in the past to get you to understand the intrinsic security value of never-revealed keys, and the fact that the flexibility obtained by extracting keys is practically nil.
"Extracting keys" is not the point. Someone working for the bank has the key at some point and signs their stuff. If no agent of the bank could EVER get the key AT ALL, then they'd move to another hardware vendor.
In fact, although the bank might be happy if the key is destroyed just as soon as the few important things are signed with it, they absolutely wouldn't enjoy the idea of a music executive sitting around with the keys to their data.
Thankfully a scheme like this can't work, too many secrets to keep.
I think it can definitely work, needing only a 20% expansion in the jackbooted-thug workforce to prevent dissemation of hardware-circumvention techniques. Hardware-hacker nerds aren't brave- all it takes is two or three stomped necks, and they slink away.
Simply point out that breaking Trusted Computing helps terrorists, and the police will FIND a way to protect the Security of TCPA, for the Freedom of the Homeland.
Too bad you're still down on 3 and not 5. Came in late I guess. I wish there was a way to flag a post as a reply to 5-10 different erroneous messages at once.
That is really the sole point of genuine contention - whether an owner can know his own master key.
Looking at the other messages on this topic, there is a ton of delusion circulating on that point. The corporate PR departments are earning their paychecks.
It would probably be wise for the various anti-TCPA websites to emphasize this one fact more strongly. The Trusted Computing boosters have been quite effective at diverting the conversation to assorted side bonuses like preventing worms and keyloggers, and often well-meaning people who just want to see better designed desktop OSes (more granular permissions, sandboxing, etc) defend TCPA of of ignorance of the fundamental fact that users don't get the key.
actually, a MITM would be easy enough
It is possible, but not easy. The whole point is that each photon carries 2 bits of those data, and only one bit can be measured before the photon is destroyed. A middleman wouldn't know which of those two bits he needs to transmit. So he must guess, and half the time he gets it wrong, so the data is 50% corrupted, and the reciever knows something is very wrong.
However, if the middleman had previously broken into the reciever's office, he could've copied down the list of which bit on each photon is important, and then he could go back to the spy room and wait to run the attack on the next transmission.
(Of course, if the guy can break into the office, why doesn't he just steal disks while he's there?)
Denial of service.
It doesn't attempt to deal with it at all. QC requires you to have a straight "wire" (or diamondlike carbon filament, or other cable) between the sender and reciever. If anyone were to attempt an evasdropping attack, he'd have to be able to touch the wire. And if he can touch it, it's fairly simple for him to cut it in half. Bang, total denial.
It's not a code, because a code could be applied to many scenarios like protecting individual hard drives or internet websites.
In fact, the installation costs of QC make it seem almost totally useless. Who can imagine two people wanting to talk secretly so dearly that they will lay a customized and very expensive new cable between their two offices? It'd have to be a critical military project to justify the expense- except that the military won't want it, because it's too vulnerable to sabotage with a shovel at one point in the middle. (Conventional internet is harder to sabotage, by comparison, because damage can be routed around)
False positive intrusions.
They would have measured the expected error rate, and an intrusion would create an error rate of twice that. It should be noted that when QC "detects eavesdropping", it's not that an "Intruder Detected" lightbulb goes on, but rather you notice that your data flow has stopped entirely, or has been changed to random noise, which means either an intruder or a cable failure.
Reliability without retransmission.
It does not attempt to deal with it. There will be unreliablilty, and it will be addressed with retransmission, as modern network protocols do already.
There simply is no way to perform a "charlie" attack (charlie denoting a third user, after Alice and Bob).
No, there is a way. But most QC advocates skip over that possibility, because the vulnerability only exists before they start going through the usual list of steps.
QC requires sender and reciever to know a list of which attributes of each particle is supposed to be read, and which should be discarded. If the middle-man doesn't have this list, he can't read their data and pass it along, because he doesn't know which of the attribute is the important one on each photon.
But that all assumes he doesn't have the list, which you can't be sure of, because it had to be conveyed by some other channel, which might have been quite vulnerable to spying. An opponent who has the list of significant polarizations can read the message and then retransmitt it just like the original sender did.
The funny part is, QC isn't even a good solution to key distribution.
Furthermore, to use QC for key distribution, you already need to have distributed a shared key beforehand! Search for "secret bit string is agreed to" or "a public, but authenticated, channel" in the QC wikipedia page to see what I mean.
Using QC to make an untamperable communication requires you to already have some other comm channel which is already trusted as untamperable- and if you had that, why not just send the keys on it in the first place? (Possible answer is that you can carry a small key on the first, expensive channel, and then use QC for all your later keys for many years. But it'll be a long long time before QC's cost compares favorably to 5 armed guards escorting a briefcase into a jet plane)
If you push it hard enough it will fall over.
I'm afraid not. In fact, when you push things really really hard, they don't fall over at all. Why, I saw this radio antenna that has 21,000,000 pounds of force applied to it, and not only didn't it fall over, but it zoomed off into the sky and hasn't been seen since.
Quantum Cryptography is indeed real cryptography.
No, wrong. Why wrong? Because you disprove yourself in the very next sentence:
It uses the encryption system known as the One Time Pad.
If it USES an encryption system, then it IS NOT an encryption system. In the same way, a desktop PC is not a RAM chip, and a Toyota Corolla not a six-cylinder engine.
Yes and no.
Nope. No and only no.
In other words, QKE leads quite directly to (a) a cipher and (b) a traditional cryptographic system.
The fact that it can bootstrap an encryption system should be a strong sign that it is not itself an encryption system.
IAAGSSTS (I Am A Grad Student Studying This Shit).
If so, then why didn't you correct the actual factual error in her post? (The last sentence is, at best, a misleading wording)
Quantum "encryption" is no better (or worse) than regular encryption.
True, it's not better than encryption- because QE, as your use of scare-quotes apparently alludes to, is not encryption at all.
a simple oversight in the implementation can render you're algorithm breakable.
That is an inadequate justification for the claim "everything can be hacked". If an oversight in implementation means you can be hacked, it doesn't follow that the algorithm is breakable- but only that you were never really using that algorithm at all.
I wait in both instances, except now my KDE startup takes longer because it's doing other crap in the background.
That will rarely be true.
The extra time is probably unmeasurable, since it's primarily from IO-bound processes, which would have no contention with what you're doing.
When booting Red Hat Linux, it's not abnormal for individual network service processes to halt for more than TWO MINUTES if the network is down and they can't find their domain servers. This improvement will allow the user to login and start finishing work on locally-stored files quicker. I should not have to wait for apache, postfix, and ypbind to finish before I can check my email!
A superior generalization of this idea would be to parellize daemon startup across the board.
I turn on the computer. I go to the bathroom. I get up and go get a drink, and when I come back it's ready to use.
Wrong. You come back and its only ready to login, not really use. You then must wait an additional time period as Gnome / KDE goes through all of it's initialization...
If you could have pre-buffered your login info immediately on power-on, and then went to the beverage fountain, the total delay would come closer to the best-case you imagined.
To the degree that it becomes default Red Hat behavior, it's something that I'm forced to deal with, or at least to actively disable.
That would only be true if you had some reason to ever want to disable this. I surely can't think of anything bad about it.
2) Try Windows XP and tell me how much faster things get done when your system is completely unresponsive.
There are few systems less responsive than Red Hat Linux as it's still loading 10 different network servers, some of which block on DHCP and DNS.
Moving GDM ahead in the startup sequence allows more parrelization. The user can type her password at the same time background daemons are initializing, instead of waiting for all those daemons to finish before the computer becomes interactive. It's better for everyone.
"Never block the UI" is hardly a controversial design rule.
If you hash all application software into the TPM state, no new software can be added without changing the hash. If you hash only selected software, the user can simply use something else, unless you lock down the system to prevent all software installation.
Both true, both irrelevant.
. Please describe the mechanism, based on the features provided by a TCPA TPM.
GIYF
Maybe our decendants will pour their intensity and testosterone into mind boggling hardvard level training (not edutainment - bleah)
Did you watch the Sliders episode where that happened? No, it wasn't plausible there either.
How about the PSP viewing movies and playing music being innovative?
Movies and pop music have nothing at all to do with games. It's possible they could succeed in the marketplace, but that marketplace is (by definition) not "gaming".
(By a similar token, Apple's ipod and itunes lines might help the profit margins, but the move the company away from being about "computers" any more)
what about using an auxiliary analog stick?
Insufficient to reproduce the gameplay. "Telekinesis" as used here means that objects anywhere on the screen can be immediately targeted by the player.
One could attempt to emulate this effect using either a joystick or a mouse which moves around a cursor to pick the target, but that will irreperably change the gameplay. It is SO much easier to select a position with a touchscreen than with a mouse, and joysticks are even worse.
For an existing example, look at Counter-Strike. It was intented to be played with a mouse, and all the game balancing was made with that assumption. If you play with a joystick, it will be impossibly hard and no fun.
If you play with a touch screen, it will be laughably easy and no fun either. (People who enjoy running an aimbot are exceptions, as their notion of "fun" comes from a different convention)
Assuming you are a genius, or at least highly intelligent, then you can teach yourself software CS alone in your home for just $300 worth of textbooks.
To properly learn hardware CE, on the other hand, requires both bulky, expensive lab equipment (or emulators and CAD that are merely expensive), and more importantly, mentoring from someone already in the field. Because of the Free Software movement, there are many professional-level software projects whose development process and changing source code are open for public view, so you can watch and learn whenever you like.
Hands-on experience with hardware design can't be plucked off the internet for free like that, so it's a better way to invest your tuition penny.
with a Bush flunky. I feel so dirty.
You know that Gates used to be a Clinton groupie? He posed for a lot of photo-ops at social events, etc. It was only after he woke up one morning and noticed that his corporation was a gigantic illegal monopoly that he switched over to the party of Big Business.
Legally H1Bs MUST be paid the prevailing wage.
The only real effect that rule can have is to slow down the rate of salary decreases, not stop it. H1Bs can always be hired for the lower-end of the prevailing scale (for justifiable reasons, such as that their worse English skills make them less productive employees).
Then next year, the prevailing wage has gone down because it now includes all those H1Bs (and local workers competing with them). Over enough time, you reach the same point as if the rule had never existed at all.
AC: But for systems that are switches or teller machines or heart monitors or guidance control systems for a missle or some other device, they use trusted computing for very good reason.
Nope. On those systems, there is no reason for Trusted Computing at all. Only one person will be allowed to install program on them, and she will do it only very rarely- probably just once, in the factory when the missile is built. Mission critical embedded systems like those server exactly one owner; but Trusted Computing is about making PCs also serve corporations aside from the owner of the hardware.
Devices like that don't connect to the public internet, and they don't view media files written by other people. They are a black box, and almost nothing gets in or out.
Trusted Computing is irrelevant to a situation like that, unless the system admin is so dangerously incompetent that he needs an extra failsafe to keep him from installing malware on a warhead.
Linux will not restrict what you can do itself. The kernel will never work against you.
If that's true- and it might be- then Linux will never be able to view the majority of content end-users need to see. Most of the nascent free software world, especially as pertaining to desktop PCs, will be absolutely crippled.
If you buy a video online, any problems you have are the fault of the company from which you bought the video.
Assigning blame doesn't fix problems.