That's the first valid concern I've seen in this whole thread. If that's true then I agree, it's a very very bad thing. On Friday 20 September 2002 23.49, Herman L. Knief wrote:
Actually it goes much further than that. Imagine that you want an ebook for your Palm... Right now, you buy it, you dowload it and you enjoy it. Maybe you decide to copy it to your desktop for safe keeping, or to read it on a larger screen. In the future, if all this stuff gets embedded into PCs, PDAs, etc... you could buy it and download it to your PDA. But, you can forget about copying it to your desktop. You couldn't transfer it to another PDA if you uypgraded... because everything get's a custom embedded key based on the hardware it's originally loaded onto.
Don't even think about buying Music online... because the only device you'd ever be able to listen to a song on, would be the device it get's downloaded to after you buy it. You couldn't move it to your PC or copy to a disk for your car... because your "trusted" app that was used to download it won't decrypt the file for use on another machine.
I'm sure all this makes the MPAA and RIAA very happy... but it screws you as a consumer. So much for consumer rights and fair use.
- Herman
On Fri, 20 Sep 2002, Anders Johansson wrote:
->On Friday 20 September 2002 23.25, Herman L. Knief wrote: ->> It's the difference of so many providers who already use "standard ->> extending technologies" (as M$ likes to put it) that make some web sites ->> only fully functional to IE clients. Now, if they add another layer that ->> say's there has to be a trust relationship before they will server you ->> data... then you are completely screwed if you are not running M$. It ->> goes way beyond some sites using QuickTime or some other format. At least ->> now, some sites are partially non-functional... if this make any progress, ->> sites will become totally non-functional to any non-conforming free ->> thinker. -> ->Well, I could very well be wrong about this. I haven't studied palladium ->nearly enough to make intelligent statements about it. But the way I read the ->white paper I got the impression that it was essentially a hardware ->implementation of ssh/ssl and encrypted file systems. In the scenario you ->describe therefore, it would be far more likely that what would happen is a ->sort of tunnel, similar to ssl, would be established between client and ->server. And that the data would be encrypted using that machines hardware ->encoded key, similar to what we have today with software keys. I can't see ->that that would put any new requirements on the client software, beyond ->having access to a driver/API for the encryption functions in the hardware. -> ->//Anders ->