The Phoenix Technologies proposal before the T.13 committee, which may pave the way to copy restrictions for users, shouldn't be seen as the son of CPRM, argues Linux ATA/IDE guy Andre Hedrick.
Although the proposal - which has not yet been published outside the open meeting - does not specifically prevent any command sets such as CPRM from applying to fixed hard drives at a later date, Hedrick says the important point is that the owner of the drive could disable the features. And furthermore, it gives users of operating systems that let such features through block them. However, he plans to reserve his final judgement until review of the published document.
Hedrick's primary concern, he says, is that the user has the ability to turn whatever copy restrictions may yet be in the pipeline, off, both at the system level and the OS level:
"It's like those big dogs, you put a muzzle on it. The question is to muzzle or not too muzzle," he told us. "Control over a technology is more important than it existing. If you know it's there, you're empowered."
Ironically says Hedrick, the modified, third revision of the CPRM specification gave users more flexibility in this respect than the Phoenix BIOS proposal.
"For me it didn't matter what it was; or if it was actual CPRM - the fact that it could have a switch to turn it off made me happy." Hedrick was precluded from the vote, standard practice when a member changes jobs between meetings.
Hedrick was invited to modify the CPRM proposal to give programmers a way of ensuring CPRM media could be rejected from fixed hard drives.
However, he says, the revision addresses a critical issue - who "owns" the drive. The latest "generic" feature mode proposal to CPRM specifically addressed concerns about the usage of new features before being presented. It's now impossible for these to slip through the back door without the user or the OS device driver writer knowing about them. In other words, in the future shadowy command sets will be flushed out into the open.
"OS's will be forced to strictly test for support of new, unknown commands and reject all that could not be handled safely. The effect will be to reject all commands that are not published or public, or have known data-phase responses," he says. And that's preferable option than fighting each command set battle, and infinitely more preferable than having these go "underground" in undocumented, vendor unique command sets.
Intel today said Curtis Stevens' proposal met its requirements:
"The Phoenix proposal would serve the same purpose of a generic command that we wanted to do for copy protection," said an Intel spokeman today. "It only activates when you are copying to removable devices and marries that content to that piece of blank media you have."
Phoenix had not returned our request for comment at press time. ®
Bootnote This one comes direct from the Ministry of Irony.
Like so many Register stories, CPRM bypassed the trade press almost entirely en-route to the national and international media, where it made the front page of the San Jose Mercury, and was covered by many national inkies including The Times and The Independent. But look in vain for coverage on Wired, or the CMP networks, and apart from one tragic effort - which failed to mention the boycott - it went ignored by the CNet/ZDNet conglomerate too. That explains the title of our FAQ on the topic.
Well, believe it or not, ZDNet still refuses to tell you anything about CPRM. Today ZDNet reporter Rob Lemos (hi, Rob) turned in a sterling story on the subject, but it was published only on CNet's site, and not by ZDNet News. Keeping the news away from your readers is quite a challenge for news editors, and must merit some lovely glass Anti-Journalism gong all of its own.
Ye gads, how long can they keep it up?