The TPM module is a general purpose encryption store. You can store encryption keys there and ask the chip to perform operations with them. Presumably Apple is using this to verify that the hardware is "blessed" by checking the TPM settings at various times. The whole trusted computing platform calls for booting from firmware that is validated against TPM hashes, then using that to validate each layer (boot loader from disk, etc.) until you get to the full OS. The maintainence of these hashes in the presence of updates may be an issue, or Apple may only go far enough to ensure that the OS will not boot without such a set of checks. Without custom chipsets though the hackers will most likely find a way around this, just as they have done with iTunes and other systems. What this does do is let Apple sue anyone using DMCA that tries it, or even publishes a method for doing it.
The problem with software is 1) you never build the same thing twice, 2) a lot of the support systems do not exist, 3) there is no set of "common assumptions" that hold. In the building industry there are standards "code" that must be met for any project to be done. Those do not exist for software yet. In the building industry there are standards for what a wall is. That does not exist for software yet. In general the flexibility of software creates huge varriances in the results, and there are not enough checks and balances to ensure acceptable results.
If you do "outsource" development to a small team, you want to be a major part of their income to have leverage, but that also exposes you to their failure when your contract ends. You could have a second outside party provide reviews of the code, but in the end quality is hard to verify without an equal sized test team. And, having the test and dev teams not be adversarial is very difficult if you want them to also be independent of each other.
While doing product development in-house is hard, doing custom development for external clients using outside developers is insane. If you have expert in-house developers to oversee the work, and you want to use contract developers to bulk up the team, just make sure your in-house people understand the whole system and are prepared to maintain it.
Slashdot Mirror
No worries. At this point it is mostly conjecture on all our parts. Once the hardware starts shipping, I am sure it will be much better understood.
The TPM module is a general purpose encryption store. You can store encryption keys there and ask the chip to perform operations with them. Presumably Apple is using this to verify that the hardware is "blessed" by checking the TPM settings at various times. The whole trusted computing platform calls for booting from firmware that is validated against TPM hashes, then using that to validate each layer (boot loader from disk, etc.) until you get to the full OS. The maintainence of these hashes in the presence of updates may be an issue, or Apple may only go far enough to ensure that the OS will not boot without such a set of checks. Without custom chipsets though the hackers will most likely find a way around this, just as they have done with iTunes and other systems. What this does do is let Apple sue anyone using DMCA that tries it, or even publishes a method for doing it.
The problem with software is 1) you never build the same thing twice, 2) a lot of the support systems do not exist, 3) there is no set of "common assumptions" that hold. In the building industry there are standards "code" that must be met for any project to be done. Those do not exist for software yet. In the building industry there are standards for what a wall is. That does not exist for software yet. In general the flexibility of software creates huge varriances in the results, and there are not enough checks and balances to ensure acceptable results. If you do "outsource" development to a small team, you want to be a major part of their income to have leverage, but that also exposes you to their failure when your contract ends. You could have a second outside party provide reviews of the code, but in the end quality is hard to verify without an equal sized test team. And, having the test and dev teams not be adversarial is very difficult if you want them to also be independent of each other. While doing product development in-house is hard, doing custom development for external clients using outside developers is insane. If you have expert in-house developers to oversee the work, and you want to use contract developers to bulk up the team, just make sure your in-house people understand the whole system and are prepared to maintain it.