sad treacherous computing day

[simo]

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.