Opinions are diverging on how to fight CPRM, the stealth copy control mechanism that promises to "firewall Napster at your PC", in the words of a Sony executive.
IBM withdrew its proposal to the T.13 hard drive standards committee last week, and Phoenix's generic proposal was introduced and rejected. It's on the agenda for the next T.13 ATA committee meeting in April.
Yesterday, EFF co-founder John Gilmore, whose call to arms did much to galvanise users against CPRM on hard drives issued his analysis of the Phoenix proposal.
Gilmore wants members of the public to join the T.13 standards committee. And while acknowledging that the Phoenix proposal is innocuous ("there is nothing controversial in this new proposal - there is nothing in at all,") it may be a Trojan Horse for "secret" standards, he writes.
But Linux ATA driver guru and T.13 committee member Andre Hedrick, who has watched CPRM for several months, strongly disagrees.
His concern is to ensure that CPRM doesn't go underground, he says, into the nether world of undocumented "Vendor Unique" commands used by manufacturers, which are far more difficult to identify and that could criminalise attempts to break it. He wants it above ground, identified, and where folks can see it.
You didn't ask for it, but here it is anyway
Regardless of what T.13 decides to ratify, CPRM could yet be commonplace in hard disks in the future, implemented through the back door of "Vendor Unique" commands, Hedrick argues. And the task of finding out where CPRM is coming from would permanently impair the performance of non-CPRM operating systems. Like a Smash the Hippo Game, only with an infinite number of Hippos.
And he adds, there's really nothing to stop vendors doing this. Much of what your hard drive can really do is not considered or ratified by T.13. This ain't the Supreme Court: it only sets down lowest common denominator interoperability standards. The rest is a free for all.
Hedrick's issued his own "suggestion" to the T.13 mailing list, promising to give away a command parser that bounces unknown new commands, so obliging a CPRM-vigilant OS to track and reject all such command sets. His threat poses a dilemma for drive manufacturers which may be inclined to sneak CPRM in through the back door: they'll effectively lose the Linux market. Hedrick's parser will include trap-doors for vendors who try to circumvent known command sets, too.
Gilmore argues that a cabal of drive vendors want to include copy control specifications in the ATA spec, but are sneaking it in through the back door:
"If a market-dominating group of disk drive makers; computer companies like IBM, Intel, Toshiba, and Hitachi; and movie and record companies all want to go off into a smoke-filled room and define their own set of exclusionary copy-protection specs, they need to pretend they're meeting to define a standard in an accredited standards organization like T13. This proposal is their smoke-screen."
" It's just a scam to give the T13 committee "plausible deniability" so they can vote for CPRM. Well, now the secret is out and it doesn't look so plausible anymore. If they really wanted to support arbitrary "generic" functionality, they should design something that would handle more than a single custom function per disk drive."
Hedrick argues that the unknown command sets not ratified by T.13 could be the real Trojan Horse, and he wants to find a way to find and stop them:-
"I will share and give away a command-parser model that will allow any HOST OS to reject commands that it does not know how to match the data-phase returns. Remember that the SPEC are the rules how to talk to devices as we have all been told, but the HOST has every right and duty to restrict the execution of unknown commands. Additionally, should attempts be made to bypass this method of access filter, then we add complete taskfile register parsers and finally content tracking of all commands that return memory info that is outside of the registered and found user-space LBA's."
In addition, he says, the proposal would allow Linux programmers to use existing "Vendor Unique" commands.
Firewalling the firewall
Hedrick and Gilmore appear to agree on almost everything: they both strenuously object to CPRM, and they both want to allow programmers and users of free software operating systems maximum control over such restrictive technologies. That's a pretty basic philosophical unity.
There's a crucial difference, though. Gilmore's logic is based on the faith that public pressure will bounce CPRM out of a standards committee for good. Hedrick holds a perhaps more cynical view - he knows the terrain inside out - that the committee itself can't make or break CPRM. And so he's plotting a doomsday scenario, where CPRM has snuck into drives, and Linux programmers and users need some ammunition with which to fight it. Again, that's a complementary, not an adversarial view.
From where we sit, though, these guys need each other, and they need to get talking. ®
For all our CPRM stories, and a handy FAQ too click here.