USB stick isnt better. Your private key has to be transfered to computers main memory all the time you sign or decrypt something because the key is needed by the encryption/sign algorithm.
What is stopping you from designing an USB stick where the encryption/signing happens inside the stick?
The "whitepapers" on both sides (both the rosy red from IBM and the official TCPA FAQ, and the 'black helicopters' version) are nothing but bias.
Read the specification. It might very well be that TCPA was never designed or intended for use as a DRM system. It is however a fact that it provides the primitives required to build a DRM system on top of it.
Why do you think the spec calls for the possibility of informing a 3rd party about the state ("trustworthiness") of the system? Why do you think the spec contains "endorsement keys"? Why do you think the primary private key is locked hard inside the TCPA hardware module?
To whoever wrote those IBM rosyredpapers - get down from that ivory tower. Either fix TCPA so it can't be used for DRM, or stop lying.
- Generates key pairs (a fast DSP) - Stores key pairs - Performs encryption/decryption, only if everything is okay
You forgot: - Allows 3rd party to verify the state of your system.
This is enough for a 3rd party to: - Verify that your hardware and software platform is in a "known good state" - i.e. WinXP2 with MediaPlayer10 running on a real physical machine. - Create keys and encrypt media files so that they can only be decrypted when the computer is in this "known good state".
One of the papers mentions that the TCPA is removable from the system.
Read the spec, not the whitepapers.
The TCPA module in one specific implementation by IBM is mounted on a removable card. A TCPA module might also be hardwired to the motherboard or, at least theoretically, be on a smartcard inserted in the computer.
The answer is, if the cost of encryption is low enough, people will find news reasons to use it.
"Fast crypto" is not an argument for TCPA.
The TCPA module is a low speed hardware implementation of certain crypto algorithms - the current IBM implementation is connected to the rest of the computer on a low speed interface, for crying out loud. Your CPU is a lot faster. High-speed hardware crypto in the shape of PCI cards have been available for a long time.
TCPA is designed to keep anyone from reading the keys, because fundimentally, you can't really trust your PC because you don't know if it's been subverted by some virus or trojan.
It is certainly a lot better to have your computer subverted by the RIAA and MPAA.;-p
If you mean it seriously, and you mean to imply that the TCPA is inherently a bad thing, you obviously didn't read the whitepaper (and thus aren't well suited to present us with a "summary").
*sigh*
The whitepaper is crud. All it says is that "TCPA can be used for good stuff" and "TCPA wasn't primarily designed for DRM, really".
The first statement we already know. We also know that all the good stuff can be solved, or has already been solved by other, less intrusive, systems.
The second statement falls apart when you read the actual specification and realize how the private keys, endorsement keys, nubs and 3rd party verification works. It might not have been designed primarily for DRM, but it is well suited for designing DRM systems on top of.
If you believe otherwise, go read the spec and then quote me chapter and verse how it is impossible to use TCPA for building DRM.
To get you started in your quest - why is there an endorsement key?
One of the founding principals of the TCPA is the "protection" in hardware of the processes running on a system.
No, it isn't. TCPA is about protecting keys, creating a trust metric during system boot and throwing around endorsement keys.
TCPA is: 1) A secure key store, including a hardware implementation of several crypto algorithms. 2) A "trust metric" which tells you whether your BIOS or boot loader has been modified. 3) A way to tell 3rd parties about your "trustworthiness".
That, and nothing else. TCPA doesn't protect processes. It doesn't protect against trojans, virii, macros, buffer overruns and other security problems.
Also note that all the good features with TCPA can be, or have already been, solved by other means (i.e., protected boot and protecting keys).
The bad feature is that TCPA is the scaffolding required to build DRM systems.
So tell me -- did you read the whitepapers mentioned in the article? Or are you simply going by the FUD presented at notcpa.org?
Some of us have read all the TCPA specifications, the TCPA FAQs and the IBM "we're not the bad guys" rosyredpapers.
Seriously, whether you are for or against the TCPA, read the white-papers IBM put together. Note that it has nothing to do with DRM or Palladium,
Bullshit. TCPA provides the scaffolding required to build DRM systems.
and the author of one of the papers says "DRM is stupid, but that's another paper".
I'm not surprised. I suspect that most of the people from IBM and the other companies that are designing TCPA think they are doing a good and necessary job.
They are rocket engineers. However, I am sure that early rocket scientists would come up with a similar whitepaper when people pointed out that this technology obviously would be used for military purposes.
Or go read the specifications yourself. 1) The TCPA is NOT Palladium
TCPA or a similar hardware TCB is required to build systems like Palladium. Are you denying that?
2) It does NOT protect against physical tampering (thus not being well suited for DRM usage)
How many people do you know that have the tools and knowledge to do sideband attacks on hardware?
It would be more correct to say that current TCPA chips are not hardened to military level standards for physical tampering. However, this is just a feature of the manufacturing process and design of the chip itself. I can find nothing in the TCPA spec that makes it impossible to make tamper-hardened TCPA implementations.
3) It doesn't use any cert authority or "code signing" or anything like that. This again is not Palladium, and this is not the XBox.
"This rocket contains no military payload"
TCPA contains functions to attach that payload. If you read the spec and whitepapers carefully, you will see that they don't deny that.
It really is about helping to protect you against crackers or viruses/worms from obtaining your private keys (be it SSH, SSL, PGP, or whatever future application comes up).
Who said that TCPA is all bad? Yes, it can be used for perfectly benevolent purposes (such as protecting small amounts of private data).
However, the good features of TCPA can be achieved by other means - like software sandboxes and software encryption.
And IMO it is good to see IBM on-board. They've already written GPL drivers for Linux, and are showing massive support from the very beginning -- something you rarely see with *any* new specification or proposed standards. Any Linux user should be glad IBM is on-board as well.
Sorry, but no. I like some parts of TCPA, and it can certainly be used for perfectly benevolent purposes.
However, unless you live in an ivory tower, it is bloody obvious that it will be abused.
It's true that nukes need an electrical trigger to explode correctly (otherwise it's just a "dirty bomb"). But the electronics are fairly simple, and must've been designed to function in EMP environments.
True. But once the payload of the bomb goes critical, the electronics has already done its job.
An EMP anti-missile that is able to knock out the electronics inside an ICBM while in-flight turns the big nuke into an expensive unguided container of radioactive material.
Bear in mind that the Mickey Mouse Protection Act, excuse me, Sonny Bono Copyright Extension Act, actually brings US copyright terms in line with the EU.
No, it doesn't. The copyright term for copyrighted works held by private citizens was harmonised by the CTEA. At the same time, the CTEA created a larger disconnect between EU and US copyright law in other areas. Detailed information can be found here
The "harmonisation" argument was, IMHO, an excuse for increasing the corporate copyright term with 20 years in order to save Mickey.
The electric FIELD in the wire moves at nearly the speed of light. The electrons THEMSELVES are barely moving at all!
A lot of people seem confused about that one. I use the following to illustrate what is happening:
An electrical cable is the equivalent of a long rod. When I send electricity through the cable, it is the same as pushing the rod. To send information through the rod, I move my end and you see the movement on your end. The electrons in the cable, just like the rod, doesn't move fast but the signal (movement) is sent through the medium at near light speed.
I sure would hate to be in your shoes right now. Putting yourself in front of a firing squad voluntarely takes guts.
I sent an e-mail to marketing complaining about AMI supporting TCPA, and got the standard reply in return. My answer is below, and I am still waiting for a reply.
Umbertina E. Vezzani wrote:
Hello Laars,
You can already find TCPA-enabled products on the market but they have a different BIOS.
I am perfectly aware of that, and that is why I don't buy IBM laptops any more.
The Security subsystem is intended for those users who want an extra security protection that is valid even outside the OS.
The motherboard and system manufacturers will specify their system features, so I believe you will certainly be able to choose the features you want. I really don't think you will buy a motherboard with a hidden feature or "fritz".
I am not afraid of hidden features. TCPA is merely the scaffolding which enables building "trusted applications"/"trusted clients". What I am afraid of, is how software vendors and the content industry will (ab)use TCPA.
As for the reference to "fritz" - I think Ross Anderson went a little bit over the top in his critisism of TCPA. A much better overview of some of the technical problems with TCPA can be found here (I fully endorse Mr. Arbaugh's suggestions): http://www.cs.umd.edu/~waa/TCPA/TCP A-goodnbad.pdf
TCPA is meant to answer to a demand of security from users, not something else.
What demand exactly? TCPA doesn't solve any of the major security problems.
TCPA only answers the question "has the basic components of this system been changed?", and makes it possible for 3rd parties to verify the state ("trustworthiness") of a system.
The majority of security problems are on the OS or application level - macro/scripting vulnerabilities, virii, buffer overruns and similar. TCPA doesn't provide a solution for any of those. In fact, a software sandbox like Java or running certain applications in vmware virtual machines provides better protection against those real world problems.
What exactly is TCPA supposed to solve? Don't give me some marketing fluff about "enhancing security for the user". I want cold, clear, technical examples of real world security problems that TCPA is supposed to solve.
Also, which users are demanding TCPA? Users want protection against virii and similar, but TCPA doesn't solve those problems. Who are the end users that demand something like TCPA?
I also believe that, if there is a solid foundation to the concerns for privacy people is expecting, the TCPA itself will improve its specification to address those concerns.
So there is a real chance the next revision of the TCPA spec will include proper anonymous certificates a'la Chaum instead of the current "please trust the privacy CA" solution?
It must be noted that AMI has not announced support for Palladium. Palladium is an initiative by an OS entity that is slated for the future.
I know that. I also know that there is considerable disagreement going on between the Palladium and the TCPA proponents.
To be honest, TCPA is a better specification than Palladium. However, TCPA does provide the scaffolding required for building "trusted systems" - i.e., that a 3rd party can control what is happening on my computer. TCPA is a Pandora's box - if abused, it could have a devastating effect on both innovation, privacy and consumer rights.
Regarding the limitations of a system with TCPA I would offer the link below to the public specification for further information on compatibility with different OS's, and hardware. Based on that spec we can tell you that it does not limit the ability to run Linux (or any other open source solution).
How is that supposed to make me feel good? I know that it is possible to disable (most of) TCPA. I know that my computer will continue to work even if the TCPA subsystem tell other computers out there that my computer has zero "trustworthiness".
However, once digital commerce, streaming media and other online content start demanding TCPA enabled clients you are effectively a second rate citizen on the 'net and are locked out of a lot of content if TCPA is disabled on your computer.
So: 1) TCPA does not provide true anonymity (you have to trust the privacy CA). 2) The scaffolding provided by TCPA can be abused by those who want to disable the Turing completeness of computers and instead turn them into locked down interactive content delivery platforms. 3) The market effect will force people to use TCPA and TCPA enabled "trusted clients" even if they don't want to. 4) TCPA is advertised as a security solution, but does not solve most of the real world security problems.
As representatives from EFF Norway told on their press conference today, the EUCD/Infosoc directive leaves room for interpretation..but not nearly enough to make a good law out of it. There is nothing that can be done with 4.2. 6.1-6.3 is fairly set in stone. We have a shot at scaring the *AA from using too intrusive DRM systems if we get a strong implementation of 6.4. Then you have 6.4.4 which is a real snake hiding in the grass (6.4 doesn't apply for interactive works wrapped in an eula).
But a lot of the EUCD is "optional", thus we could then simply drop a lot of the nasty bits and a lot of the crap would thus be removed.
I wish.. The NICE parts (like most of article 5 and parts of 6.4) and are optional. The nasty bits (most notably articles 4.2, 6.1-6.3, 6.4.4) are mandatory.
Sorry that I have to tell you this, but Norway's deal with EU through the EEC deal force Norway to implement a lot of EU directives - including the EUCD.
The Norwegian Department of Culture is expected to release a law proposal in february. If you want to do something about it, join Electronic Frontier Norway.
You believe it's your "right" to listen to a CD on your computer as well as on your CD player
Yes. Copyright law, a reasonable interpretation of the 'fair use' rule and common sense all say that it should not be illegal to do so.
The record company has no obligation to make their CDs compatible with your equipment.
That, on the other hand, is true.
You are confusing two issues - what I am legaly allowed to do, and what I have a right to complain to the manufacturer about.
To take an example - if I bought a DVD record in 1999, I probably wouldn't get anywhere if I complained about the lack of a DVD player for Linux. If I buy a car, it only has a 50HP engine and I was informed about this prior to the purchase then I don't really have any standing to complain either. The products are what the vendor told you that they are at the time of purchase.
However, as long as I stay within the laws regarding car safety et.al. the car producer or the state has no business denying me putting a larger engine in the car. As long as I don't break copyright law, I can do whatever I want to do with the DVD.
Do you also believe it's your right to be able to listen to that CD on a Minidisc player? On a turntable?
Copyright doesn't deny me the right to do so. If I have the tools and time, the record company should have no right to deny me copying the CD to a minidisc. However, I can't go to the record company and complain because I can't put the CD in a minidisc player.
It is those tools that the media companies wants to deny me. That is why my rights are violated.
They tried to pass similar laws years ago when VCRS became popular.
They did? I know that Universal et.al. went all the way to the supreme court to stop Sony from selling the Betamax (a very narrow decision, btw - 5-4 in favour of Sony and time-shifting as fair use), but I was not aware of any proposed laws. Any references?
It is also interesting to read the MPAA propaganda from that time - Valenti calling the VCR the "boston strangler" of the movie industry. Quite incredible how stranglers become cash cows once the content industry finally accepts the technology.
Isn't reverse engineering a company's hardware/cracking encryption a violation of the DMCA?
The DMCA does contain an exemption for reverse engineering. It has, however, never been interpreted by a court of law yet.
Also, the exemption only allows you to circumvent a TPM in order to do RE. Once you make an interoperable program and distribute it you are likely distributing a curcumvention device - which is illegal.
So, the DMCA allows RE but you're screwed if you use the information you figured out to make and distribute interoperable software/hardware.
Advocating illegal activity is pretty unprofessional.
First of all, it is unclear whether it is illegal or not. Secondly, ever heard of public disobedience?
In many ways, 802.11b Access Points give you similar performance to what you would find in a 10BaseT hub
It is actually a bit worse. Bad signal levels, noise, multipath and other issues conspire to make the throughput of the average "11Mbps" 802.11b network lower than you would expect on a regular 10Mbps 10baseT hub with a similar number of clients.
Clients scale back to 1, 2 or 5.5 Mbps if the signal quality is not sufficient for 11. A client sending 1K of data at 1Mbps use the same air-time as a client sending 11K at 11Mbps.
On a shared hub, all clients can 'see' each other, so when two nodes transmit at the same time they detect a collission. On wireless, you can have hidden nodes (both clients can hear the AP, but they can't hear eachother) so you can get collissions but the clients don't know that they collided. To mitigate this problem, you can revert to an RTS/CTS system (AP tells nodes when they can send) but at the cost of lower throughput.
2.4GHz is also becoming crowded. Bluetooth, DECT phones and other equipment also use the same frequencies. This creates more noise and interference.
Etc..
When having more than a few clients, expect aggregate thrughput on 802.11B to be closer to 4-5Mbps than 11.
Sadly, the demise of the EuroDMCA (Directive 2001/29/EC) is not at hand.
The only thing is that the directive was supposed to be implemented in the law of all EU countries before Dec 22. It has not been stopped, it has only been delayed.
So, stop cheering and start writing letters to the press and government.
they'll be all over the newspapers as soft on hackers and terrorists
Ehh.. The Norwegian newspapers have shown more sympathy for Jon than they have for the prosecution. Besides, "terrorist" doesn't produce quite the same knee-jerk reaction in Norway.
Are we at a point where companies are expected not to do things in their best interests? DRM, if implemented well, could be a painless thing.
No.
It is impossible for client-side DRM and "fair use" to coexist.
Any client-side DRM that wants to control the number of copies made, must make it impossible to convert the 'content' to non-DRM-protected formats.
It is impossible to make a DRM that makes it possible for you to have free, uncontrolled, personal use (and I define personal as your private sphere. Putting something on Gnutella is _not_ personal use, but reading an eBook you have bought on the platform and with the software of your choice is.).
I certainly don't condone the copyright infringement that is happening on P2P networks today, but at the same time I think that DRM is the wrong solution.
Slashdot Mirror
USB stick isnt better. Your private key has to be transfered to computers main memory all the time you sign or decrypt something because the key is needed by the encryption/sign algorithm.
What is stopping you from designing an USB stick where the encryption/signing happens inside the stick?
RTFA
RTFspec!
The "whitepapers" on both sides (both the rosy red from IBM and the official TCPA FAQ, and the 'black helicopters' version) are nothing but bias.
Read the specification. It might very well be that TCPA was never designed or intended for use as a DRM system. It is however a fact that it provides the primitives required to build a DRM system on top of it.
Why do you think the spec calls for the possibility of informing a 3rd party about the state ("trustworthiness") of the system? Why do you think the spec contains "endorsement keys"? Why do you think the primary private key is locked hard inside the TCPA hardware module?
To whoever wrote those IBM rosyredpapers - get down from that ivory tower. Either fix TCPA so it can't be used for DRM, or stop lying.
TCPA is basically this:
- Generates key pairs (a fast DSP)
- Stores key pairs
- Performs encryption/decryption, only if everything is okay
You forgot:
- Allows 3rd party to verify the state of your system.
This is enough for a 3rd party to:
- Verify that your hardware and software platform is in a "known good state" - i.e. WinXP2 with MediaPlayer10 running on a real physical machine.
- Create keys and encrypt media files so that they can only be decrypted when the computer is in this "known good state".
One of the papers mentions that the TCPA is removable from the system.
;-p
Read the spec, not the whitepapers.
The TCPA module in one specific implementation by IBM is mounted on a removable card. A TCPA module might also be hardwired to the motherboard or, at least theoretically, be on a smartcard inserted in the computer.
The answer is, if the cost of encryption is low enough, people will find news reasons to use it.
"Fast crypto" is not an argument for TCPA.
The TCPA module is a low speed hardware implementation of certain crypto algorithms - the current IBM implementation is connected to the rest of the computer on a low speed interface, for crying out loud. Your CPU is a lot faster. High-speed hardware crypto in the shape of PCI cards have been available for a long time.
TCPA is designed to keep anyone from reading the keys, because fundimentally, you can't really trust your PC because you don't know if it's been subverted by some virus or trojan.
It is certainly a lot better to have your computer subverted by the RIAA and MPAA.
If you mean it seriously, and you mean to imply that the TCPA is inherently a bad thing, you obviously didn't read the whitepaper (and thus aren't well suited to present us with a "summary").
*sigh*
The whitepaper is crud. All it says is that "TCPA can be used for good stuff" and "TCPA wasn't primarily designed for DRM, really".
The first statement we already know. We also know that all the good stuff can be solved, or has already been solved by other, less intrusive, systems.
The second statement falls apart when you read the actual specification and realize how the private keys, endorsement keys, nubs and 3rd party verification works. It might not have been designed primarily for DRM, but it is well suited for designing DRM systems on top of.
If you believe otherwise, go read the spec and then quote me chapter and verse how it is impossible to use TCPA for building DRM.
To get you started in your quest - why is there an endorsement key?
One of the founding principals of the TCPA is the "protection" in hardware of the processes running on a system.
No, it isn't. TCPA is about protecting keys, creating a trust metric during system boot and throwing around endorsement keys.
TCPA is:
1) A secure key store, including a hardware implementation of several crypto algorithms.
2) A "trust metric" which tells you whether your BIOS or boot loader has been modified.
3) A way to tell 3rd parties about your "trustworthiness".
That, and nothing else. TCPA doesn't protect processes. It doesn't protect against trojans, virii, macros, buffer overruns and other security problems.
Also note that all the good features with TCPA can be, or have already been, solved by other means (i.e., protected boot and protecting keys).
The bad feature is that TCPA is the scaffolding required to build DRM systems.
So tell me -- did you read the whitepapers mentioned in the article? Or are you simply going by the FUD presented at notcpa.org?
Some of us have read all the TCPA specifications, the TCPA FAQs and the IBM "we're not the bad guys" rosyredpapers.
Seriously, whether you are for or against the TCPA, read the white-papers IBM put together. Note that it has nothing to do with DRM or Palladium,
Bullshit. TCPA provides the scaffolding required to build DRM systems.
and the author of one of the papers says "DRM is stupid, but that's another paper".
I'm not surprised. I suspect that most of the people from IBM and the other companies that are designing TCPA think they are doing a good and necessary job.
They are rocket engineers. However, I am sure that early rocket scientists would come up with a similar whitepaper when people pointed out that this technology obviously would be used for military purposes.
Or go read the specifications yourself.
1) The TCPA is NOT Palladium
TCPA or a similar hardware TCB is required to build systems like Palladium. Are you denying that?
2) It does NOT protect against physical tampering (thus not being well suited for DRM usage)
How many people do you know that have the tools and knowledge to do sideband attacks on hardware?
It would be more correct to say that current TCPA chips are not hardened to military level standards for physical tampering. However, this is just a feature of the manufacturing process and design of the chip itself. I can find nothing in the TCPA spec that makes it impossible to make tamper-hardened TCPA implementations.
3) It doesn't use any cert authority or "code signing" or anything like that. This again is not Palladium, and this is not the XBox.
"This rocket contains no military payload"
TCPA contains functions to attach that payload. If you read the spec and whitepapers carefully, you will see that they don't deny that.
It really is about helping to protect you against crackers or viruses/worms from obtaining your private keys (be it SSH, SSL, PGP, or whatever future application comes up).
Who said that TCPA is all bad? Yes, it can be used for perfectly benevolent purposes (such as protecting small amounts of private data).
However, the good features of TCPA can be achieved by other means - like software sandboxes and software encryption.
And IMO it is good to see IBM on-board. They've already written GPL drivers for Linux, and are showing massive support from the very beginning -- something you rarely see with *any* new specification or proposed standards. Any Linux user should be glad IBM is on-board as well.
Sorry, but no. I like some parts of TCPA, and it can certainly be used for perfectly benevolent purposes.
However, unless you live in an ivory tower, it is bloody obvious that it will be abused.
It's true that nukes need an electrical trigger to explode correctly (otherwise it's just a "dirty bomb"). But the electronics are fairly simple, and must've been designed to function in EMP environments.
True. But once the payload of the bomb goes critical, the electronics has already done its job.
An EMP anti-missile that is able to knock out the electronics inside an ICBM while in-flight turns the big nuke into an expensive unguided container of radioactive material.
Bear in mind that the Mickey Mouse Protection Act, excuse me, Sonny Bono Copyright Extension Act, actually brings US copyright terms in line with the EU.
No, it doesn't. The copyright term for copyrighted works held by private citizens was harmonised by the CTEA. At the same time, the CTEA created a larger disconnect between EU and US copyright law in other areas. Detailed information can be found here
The "harmonisation" argument was, IMHO, an excuse for increasing the corporate copyright term with 20 years in order to save Mickey.
The electric FIELD in the wire moves at nearly the speed of light. The electrons THEMSELVES are barely moving at all!
A lot of people seem confused about that one. I use the following to illustrate what is happening:
An electrical cable is the equivalent of a long rod. When I send electricity through the cable, it is the same as pushing the rod. To send information through the rod, I move my end and you see the movement on your end. The electrons in the cable, just like the rod, doesn't move fast but the signal (movement) is sent through the medium at near light speed.
Please post a response as soon as you have one from AMI.
I'm kind of hoping that Brian will answer it.
Brian,
P A-goodnbad.pdf
I sure would hate to be in your shoes right now. Putting yourself in front of a firing squad voluntarely takes guts.
I sent an e-mail to marketing complaining about AMI supporting TCPA, and got the standard reply in return. My answer is below, and I am still waiting for a reply.
Umbertina E. Vezzani wrote:
Hello Laars,
You can already find TCPA-enabled products on the market but they have a different BIOS.
I am perfectly aware of that, and that is why I don't buy IBM laptops any more.
The Security subsystem is intended for those users who want an extra security protection that is valid even outside the OS.
The motherboard and system manufacturers will specify their system features, so I believe you will certainly be able to choose the features you want. I really don't think you will buy a motherboard with a hidden feature or "fritz".
I am not afraid of hidden features. TCPA is merely the scaffolding which enables building "trusted applications"/"trusted clients". What I am afraid of, is how software vendors and the content industry will (ab)use TCPA.
As for the reference to "fritz" - I think Ross Anderson went a little bit over the top in his critisism of TCPA. A much better overview of some of the technical problems with TCPA can be found here (I fully endorse Mr. Arbaugh's suggestions):
http://www.cs.umd.edu/~waa/TCPA/TC
TCPA is meant to answer to a demand of security from users, not something else.
What demand exactly? TCPA doesn't solve any of the major security problems.
TCPA only answers the question "has the basic components of this system been changed?", and makes it possible for 3rd parties to verify the state ("trustworthiness") of a system.
The majority of security problems are on the OS or application level - macro/scripting vulnerabilities, virii, buffer overruns and similar. TCPA doesn't provide a solution for any of those. In fact, a software sandbox like Java or running certain applications in vmware virtual machines provides better protection against those real world problems.
What exactly is TCPA supposed to solve? Don't give me some marketing fluff about "enhancing security for the user". I want cold, clear, technical examples of real world security problems that TCPA is supposed to solve.
Also, which users are demanding TCPA? Users want protection against virii and similar, but TCPA doesn't solve those problems. Who are the end users that demand something like TCPA?
I also believe that, if there is a solid foundation to the concerns for privacy people is expecting, the TCPA itself will improve its specification to address those concerns.
So there is a real chance the next revision of the TCPA spec will include proper anonymous certificates a'la Chaum instead of the current "please trust the privacy CA" solution?
It must be noted that AMI has not announced support for Palladium. Palladium is an initiative by an OS entity that is slated for the future.
I know that. I also know that there is considerable disagreement going on between the Palladium and the TCPA proponents.
To be honest, TCPA is a better specification than Palladium. However, TCPA does provide the scaffolding required for building "trusted systems" - i.e., that a 3rd party can control what is happening on my computer. TCPA is a Pandora's box - if abused, it could have a devastating effect on both innovation, privacy and consumer rights.
Regarding the limitations of a system with TCPA I would offer the link below to the public specification for further information on compatibility with different OS's, and hardware. Based on that spec we can tell you that it does not limit the ability to run Linux (or any other open source solution).
How is that supposed to make me feel good? I know that it is possible to disable (most of) TCPA. I know that my computer will continue to work even if the TCPA subsystem tell other computers out there that my computer has zero "trustworthiness".
However, once digital commerce, streaming media and other online content start demanding TCPA enabled clients you are effectively a second rate citizen on the 'net and are locked out of a lot of content if TCPA is disabled on your computer.
So:
1) TCPA does not provide true anonymity (you have to trust the privacy CA).
2) The scaffolding provided by TCPA can be abused by those who want to disable the Turing completeness of computers and instead turn them into locked down interactive content delivery platforms.
3) The market effect will force people to use TCPA and TCPA enabled "trusted clients" even if they don't want to.
4) TCPA is advertised as a security solution, but does not solve most of the real world security problems.
With kind regards,
Lars Gaarden
It would probably take close to a year to read the thing!
And imagine the horrors of running a non-journaled fs.
"Due to an unscheduled fsck, the computer lab will be unavailable for the next month"
As representatives from EFF Norway told on their press conference today, the EUCD/Infosoc directive leaves room for interpretation ..but not nearly enough to make a good law out of it. There is nothing that can be done with 4.2. 6.1-6.3 is fairly set in stone. We have a shot at scaring the *AA from using too intrusive DRM systems if we get a strong implementation of 6.4. Then you have 6.4.4 which is a real snake hiding in the grass (6.4 doesn't apply for interactive works wrapped in an eula).
But a lot of the EUCD is "optional", thus we could then simply drop a lot of the nasty bits and a lot of the crap would thus be removed.
I wish.. The NICE parts (like most of article 5 and parts of 6.4) and are optional. The nasty bits (most notably articles 4.2, 6.1-6.3, 6.4.4) are mandatory.
Yes, yup, ja, right, correct!
Sorry that I have to tell you this, but Norway's deal with EU through the EEC deal force Norway to implement a lot of EU directives - including the EUCD.
The Norwegian Department of Culture is expected to release a law proposal in february. If you want to do something about it, join Electronic Frontier Norway.
You believe it's your "right" to listen to a CD on your computer as well as on your CD player
Yes. Copyright law, a reasonable interpretation of the 'fair use' rule and common sense all say that it should not be illegal to do so.
The record company has no obligation to make their CDs compatible with your equipment.
That, on the other hand, is true.
You are confusing two issues - what I am legaly allowed to do, and what I have a right to complain to the manufacturer about.
To take an example - if I bought a DVD record in 1999, I probably wouldn't get anywhere if I complained about the lack of a DVD player for Linux. If I buy a car, it only has a 50HP engine and I was informed about this prior to the purchase then I don't really have any standing to complain either. The products are what the vendor told you that they are at the time of purchase.
However, as long as I stay within the laws regarding car safety et.al. the car producer or the state has no business denying me putting a larger engine in the car. As long as I don't break copyright law, I can do whatever I want to do with the DVD.
Do you also believe it's your right to be able to listen to that CD on a Minidisc player? On a turntable?
Copyright doesn't deny me the right to do so. If I have the tools and time, the record company should have no right to deny me copying the CD to a minidisc. However, I can't go to the record company and complain because I can't put the CD in a minidisc player.
It is those tools that the media companies wants to deny me. That is why my rights are violated.
They tried to pass similar laws years ago when VCRS became popular.
They did? I know that Universal et.al. went all the way to the supreme court to stop Sony from selling the Betamax (a very narrow decision, btw - 5-4 in favour of Sony and time-shifting as fair use), but I was not aware of any proposed laws. Any references?
It is also interesting to read the MPAA propaganda from that time - Valenti calling the VCR the "boston strangler" of the movie industry. Quite incredible how stranglers become cash cows once the content industry finally accepts the technology.
Isn't reverse engineering a company's hardware/cracking encryption a violation of the DMCA?
The DMCA does contain an exemption for reverse engineering. It has, however, never been interpreted by a court of law yet.
Also, the exemption only allows you to circumvent a TPM in order to do RE. Once you make an interoperable program and distribute it you are likely distributing a curcumvention device - which is illegal.
So, the DMCA allows RE but you're screwed if you use the information you figured out to make and distribute interoperable software/hardware.
Advocating illegal activity is pretty unprofessional.
First of all, it is unclear whether it is illegal or not. Secondly, ever heard of public disobedience?
Oh great.
Striped array with no parity is exactly what I want to use on consumer grade IDE HDs. </sarcasm>
For that price, I'd expect RAID5.
In many ways, 802.11b Access Points give you similar performance to what you would find in a 10BaseT hub
It is actually a bit worse. Bad signal levels, noise, multipath and other issues conspire to make the throughput of the average "11Mbps" 802.11b network lower than you would expect on a regular 10Mbps 10baseT hub with a similar number of clients.
Clients scale back to 1, 2 or 5.5 Mbps if the signal quality is not sufficient for 11. A client sending 1K of data at 1Mbps use the same air-time as a client sending 11K at 11Mbps.
On a shared hub, all clients can 'see' each other, so when two nodes transmit at the same time they detect a collission. On wireless, you can have hidden nodes (both clients can hear the AP, but they can't hear eachother) so you can get collissions but the clients don't know that they collided. To mitigate this problem, you can revert to an RTS/CTS system (AP tells nodes when they can send) but at the cost of lower throughput.
2.4GHz is also becoming crowded. Bluetooth, DECT phones and other equipment also use the same frequencies. This creates more noise and interference.
Etc..
When having more than a few clients, expect aggregate thrughput on 802.11B to be closer to 4-5Mbps than 11.
Sadly, the demise of the EuroDMCA (Directive 2001/29/EC) is not at hand.
The only thing is that the directive was supposed to be implemented in the law of all EU countries before Dec 22. It has not been stopped, it has only been delayed.
So, stop cheering and start writing letters to the press and government.
But the DMCA isn't a copyright law.
But the non-circumvention parts of the DMCA came from the 1996 WIPO Copyright Treaty.
they'll be all over the newspapers as soft on hackers and terrorists
Ehh.. The Norwegian newspapers have shown more sympathy for Jon than they have for the prosecution. Besides, "terrorist" doesn't produce quite the same knee-jerk reaction in Norway.
Are we at a point where companies are expected not to do things in their best interests? DRM, if implemented well, could be a painless thing.
No.
It is impossible for client-side DRM and "fair use" to coexist.
Any client-side DRM that wants to control the number of copies made, must make it impossible to convert the 'content' to non-DRM-protected formats.
It is impossible to make a DRM that makes it possible for you to have free, uncontrolled, personal use (and I define personal as your private sphere. Putting something on Gnutella is _not_ personal use, but reading an eBook you have bought on the platform and with the software of your choice is.).
I certainly don't condone the copyright infringement that is happening on P2P networks today, but at the same time I think that DRM is the wrong solution.