On 30/12/2008, Arne Babenhauserheide <arne_...@web.de> wrote: > Am Dienstag 30 Dezember 2008 12:43:45 schrieb Michal Suchanek: > > > Yes, it does. But with DRM content protection it is not the system > > what makes the computer useless but the services or devices outside of > > the computer that would require a particular version of the system. I > > do not see how you can prevent this by the system itself or any > > license except by disallowing to run any not-free-enough (lgpl, gpl > > <3, bsd, non-free) application on the system altogether. > > > The system provides something to the applications from outside which allows > these applications to find out the version of the system. > > If this something is free, I can still tell the applications that my system > hasn't changed, and they continue to run, regardless of their licensing. > > That something is then rougly speaking a part of the API of my system. > > If that something isn't free, a part of my systems API isn't free, and since > that something can be used to check the version of any part of my system it > must not be unfree if any part of the system is free.
You need a special hardware to verify the integrity of the system, and I can imagine that in a modular system the hardware driver might work without modifications to the system - think one of the initial servers loaded with the mach kernel. The driver itself need not be non-free, it would just reveal what version (or more precisely the exact bitwise checksum) of the system is running regardless of the actual version. > > > > In this case the code change would not make the system cease to work, > > it would render some applications (which must be non-free to perform > > their function and thus not part of the system) unusable on the > > system. > > > Now please think a step further. What happens if running that application is > the primary function of the system? > > (Take any application, and somewhere in the world you'll find someone who > almost exclusively uses that application) If you distributed the system preinstalled on a camera, and the imaging software on the camera would refuse access to your pictures unless a verified version of the system is running then you can argue it's the primary function. However, for a general purpose system a random application malfunctioning cannot be blamed on the system. Otherwise no system would be allowed ;-) > > > > > It is designed to make it hard for the admin of the system to decide > > > whether DRM should be effective on his own system. > > > > > > I thought I said that often enough. > > > > Probably not that clearly then. I fail to see how a system design can > > make a decision hard. It may come with poor documentation but that's > > all it can do in this regard. > > > ThatTaking that decision means configuring / changing your system to allow or > not to allow DRM to be effective. > > And the system design can make acting on the decision hard, just like code > obfuscation makes it hard to fix bugs. > > If I have to rewrite a nontrivial part of the system to make DRM ineffective, > then the system is clearly designed for allowing effective DRM, and so it is > treacherous. > The Coyotos system is probably not complete enough at this point to argue about the challenge of implementing a capability for accessing all memory. I would think that adding a 'debug' capability that allows you reading (and writing if you wish so) all storage is not too difficult if it is not already present for debugging purposes. However, matching the memory to actual objects might be more challenging depending on the way capabilities to the objects are implemented. Still you need a debugger for that on any other system, too. If you do not use hardware cryptography you can also shut down the system and examine it offline (because of the persistence) which is not possible with currently common systems and makes poking at things actually easier because you get a consistent snapshot. Thanks Michal
