On Mon, 2007-05-07 at 16:28 +0200, Alfred M. Szmidt wrote: > On Mon, 2007-05-07 at 15:52 +0200, Alfred M. Szmidt wrote: > > > This is the exact case I stated, prohibiting others from updating > > their software. It is one thing to _verify_ the binary, and still > > allow it to run, and another to simply say `You're bad! Go away bad > > person!'; and this is exactly what DRM/TC does. Signing binaries is a > > great way to check their integrity, but that doesn't mean that one > > shouldn't be able to run unverifiable binaries. So I still don't see > > how DRM/TC can be a useful thing. > > Let's try to make it clear. I don't want Alfred Szmidt to be able > to get access to my machine and take it over by installing his > malicious kernel or any of his malicious binaries. I, myself, > under my personal control, do you get it? > > This example has nothing to do with TC or DRM. This is how just about > any modern operating system works. I cannot update the kernel on this > machine since I do not have the permission to do so because the kernel > disallows me to do that task, but there is no need for a specially > crippled chip for this task. So I still do not see the use of DRM/TC.
It is an additional measure that can help you in case of bugs. If I have a vulnerability, in a service, that let you get root privileges on a machine, I can still prevent you from changing vital components because of the hardware protection. A reboot will make sure my machine is not compromised because I know you were not able to change vital system components like the kernel as you don't have the signing key I keep offline. > You are confusing two things, hardware and software. TC is purley > hardware based, and TC with DRM is even more evil. Please document yourself a bit before going on. As I said before it's the use you make of a technology that is good or bad, and I agree that using TC/DRM against a user is bad. But this does not make a Fritz chip bad per se. Simo. _______________________________________________ Discussion mailing list [email protected] https://mail.fsfeurope.org/mailman/listinfo/discussion
