I've always thought that Intel's real reason for the ID was to aid in the tracking of stolen chips. If there are other good uses for the ID, I haven't thought of them.
The ID can not be removed by the user (unlike software ID methods) and CAN be activated without user consent.
It is comments like this that led me to ask if you thought the ID gets broadcast all by itself. It matters not if the ID is present or removed, activated or not, unless some software sends the ID. And if you can't trust your software to not send your hardware ID, you can't trust it to not send a crytographically unique ID that it created just for you (which can often be used to achieve the same effect). Yes, disabling the ID can stop malicious software from getting access to the hardware ID (if you choose to actually run the malicious software on your machine), but it can't stop the malicious software from achieving the same results through other means.
Thus, your comments on the easy foiling of software methods also applies to the sending of a hardware ID since it requires software to do the sending.
The PIII ID code could not be removed. And, furthermore, it could be activated without the user's knowlege.
The PIII ID code doesn't broadcast itself, you know. It just exists, much like any other ID that might be available on a machine. It requires you to run some software on your local machine to send the code to someone else, and so, it no more or less private than a software-generated ID.
In other words, trusting your software not to send your hardware ID code is no different than trusting your software not to send a crytographically uniquie ID that was generated for your machine. Having a PIII doesn't make your machine any less (or more) private than having any other microprocessor-based machine.
The only valid issues I've ever seen raised about the PIII's ID code were concerns over some ill-conceived applications that did not properly consider security and/or privacy. However, such issues should be dealt with separately from the existance of the ID (which is not in and of itself a bad thing), since it is possible to do these same bad things without resorting to the use a microprocessor's ID code.
It really surprises me how much FUD is still floating about on this topic, most of which does not appear to have any basis in reality.
If you're going to be using RealJukebox for both the recording and playing of the tunes, you may wish to record using the 96Kbps RealAudio format insead of using 96Kbps MP3 (use their latest beta version of the software). I have read reports that this is very nearly as good as 128Kbps MP3 (and since the free version only supports up to 96Kbps MP3s, you'll get better quality using the RealAudio algorithm, and save disk space as well).
I just wish that RealJukebox would support creating the files in sub-directories, like this: Artist/CD_Name/Track_Name. I like this layout better than putting all the files into a single directory.
What is a shame are the "fast forwad" buttons on the TIVO. I played with an early unit and there was about a 5 sec. lag between hitting FF and it really moving forward. When I pressed an engineer he admitted it was to please the advertisers.
Not so -- the production units have no such delay (I've got one). I was told a much more believable reason for why the early units had this glitch: they didn't have enough memory (probably too much code swapping going on). The problem was apparently fixed before they started shipping.
Slashdot Mirror
Thus, your comments on the easy foiling of software methods also applies to the sending of a hardware ID since it requires software to do the sending.
In other words, trusting your software not to send your hardware ID code is no different than trusting your software not to send a crytographically uniquie ID that was generated for your machine. Having a PIII doesn't make your machine any less (or more) private than having any other microprocessor-based machine.
The only valid issues I've ever seen raised about the PIII's ID code were concerns over some ill-conceived applications that did not properly consider security and/or privacy. However, such issues should be dealt with separately from the existance of the ID (which is not in and of itself a bad thing), since it is possible to do these same bad things without resorting to the use a microprocessor's ID code.
It really surprises me how much FUD is still floating about on this topic, most of which does not appear to have any basis in reality.
I just wish that RealJukebox would support creating the files in sub-directories, like this: Artist/CD_Name/Track_Name. I like this layout better than putting all the files into a single directory.
Not so -- the production units have no such delay (I've got one). I was told a much more believable reason for why the early units had this glitch: they didn't have enough memory (probably too much code swapping going on). The problem was apparently fixed before they started shipping.