On Saturday 19 April 2008, Robert Millan wrote:
> You think remote attestation is voluntary, but by its nature it cannot be
> made voluntary. Voluntary means I can refuse to participate without giving
> the challenger any information about my system. However, my refusal to
> participate *IS* already information. In fact, if you add to it another
> piece of information -- namely, the (future) fact that everyone has a
> complete Treacherous stack --, what do you get? Right! You get the
> ability to distinguish who is running your CrapWare 2000[tm] DRM program
> and who isn't.
>
> Which means that in the future (unless computer users reject it outright),
> DRM proponents will have a very powerful tool in order to coerce everyone
> into using the anti-features they put in their programs (which obviously
> nobody *wants* to have, that's why they have to make it so confusing).
I think you're right about TPM, Robert. :-/
I recently acquired a laptop that came with a TPM chip; thankfully I was
aware of what TPM was indended to be used for and had read warnings on the
matter from privacy advocates. The laptop came with Vista preloaded, which
asked a vague [and perhaps intentionally misleading] question, something
along the lines of: "This device has a TPM chip which has not yet been
activated, would you like to activate it now? It will help security if you
do." [To which I answered NO.]
And in the BIOS settings, sure enough there are some TPM feature settings
that are very clearly not to the benefit of the user/owner:
Security Reporting Options: (each below has enable/disable option)
BIOS ROM String Reporting
ESCD Reporting
CMOS Reporting
NVRAM Reporting
SMBIOS Reporting
Clear Security Chip (enable/disable)
Note says: "It will not be possible to access already-encrypted data
after these keys are cleared"
I think it's pretty clear that the intent is to report the above
information to the OS manufacturer rather than to the user or owner.
-- Chris
--
Chris Knadle
[EMAIL PROTECTED]
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
