I read this article on theregister today:
http://www.theregister.co.uk/content/2/15620.html
Does anyone have any details on this? I presume that the drive
firmware is capable of identifying copy-protected data during
a write. I also presume that nobody on lkml would condone
such a terrible idea. I imagine that this system is pretty
easy to defeat if you can modify the filesystem. Perhaps even
a ROT13 modification to ext2 would be sufficient?
The consequences of being able to corrupt other people's backups
by introducing "copy-protected" data are intriguing...
Paul
> Does anyone have any details on this? I presume that the drive
> firmware is capable of identifying copy-protected data during
> a write. I also presume that nobody on lkml would condone
It seems to be very similar to the DVD stuff, including ideas for play once
only blocks and the like. Pay per read hard disk...
> such a terrible idea. I imagine that this system is pretty
> easy to defeat if you can modify the filesystem. Perhaps even
Its probably very hard to defeat. It also in its current form means you can
throw disk defragmenting tools out. Dead, gone. Welcome to the United Police
State Of America.
> The consequences of being able to corrupt other people's backups
> by introducing "copy-protected" data are intriguing...
I'm just waiting for a few class action law suits against drive manufacturers
when people's backup tools cannot cope
READ and reply to CPRM Account <[email protected]> Only...
It is not worth the kernel traffic to blow appart the issue.
On Thu, 21 Dec 2000, Alan Cox wrote:
> > Does anyone have any details on this? I presume that the drive
> > firmware is capable of identifying copy-protected data during
> > a write. I also presume that nobody on lkml would condone
>
> It seems to be very similar to the DVD stuff, including ideas for play once
> only blocks and the like. Pay per read hard disk...
That is part of the potentially hidden issue is the usage counters.
> > such a terrible idea. I imagine that this system is pretty
> > easy to defeat if you can modify the filesystem. Perhaps even
>
> Its probably very hard to defeat. It also in its current form means you can
> throw disk defragmenting tools out. Dead, gone. Welcome to the United Police
> State Of America.
No. Just blame the MPA (Motion Picture Association) for this level of
paranoia. The object is to follow the money and the fronts that are
hiding real issues.
> > The consequences of being able to corrupt other people's backups
> > by introducing "copy-protected" data are intriguing...
>
> I'm just waiting for a few class action law suits against drive manufacturers
> when people's backup tools cannot cope
Oh, this is one of the issues that I brought up along with many others
during the December Plenary Meeting. For the record, I was able to
intensify the issue by my objections to postpone the adoption for 60 days.
This subject will come up again in February. Since I can only represent
my interest as a counsultant to the T13 Committee, because there is not
organization offically known as "Linux".
I do expect to take a lot of heat on CPRM, but everyone here knows that I
can take as much as I dish it! If you wish to send a note to complain
about the issue, I will carry your points to the meeting.
CPRM Account <[email protected]>
Do not blow torch me or the issue.
Explain why you have issues.
Explain what is a better solution.
For the next point of record, I will be supporting Microsoft's proposal.
It is the only one that will not effect us in a way that could be harmful.
ftp://fission.dt.wdc.com/pub/standards/x3t13/technical/e00163r0.pdf
Additionally, Linux will have to deploy a command filter driver to force
block the use of CPRM taskfile calls by browsers, which is the suspected
method of performing this protected mode of access. The option will be
submitted/included in the next rev of the kernel for v2.5.0 at the time of
its annoucement. The default will be to block the is command set and you
will have to compile the option in to allow the technically correct
command to be accepted.
Lastly, I may end up losing my position on the Committee but hey it is for
a good cause ;-)
Regards,
Andre Hedrick
Linux ATA Development