driver and device reliability authentication and DRM monoopolisation [LWN.net]

driver and device reliability authentication and DRM monoopolisation

Posted Jul 22, 2003 10:31 UTC (Tue) by copsewood (subscriber, #199)
Parent article: 2003 Kernel Summit: High Availability

This is a very difficult one for a free-software decentralised development model to get right, because it depends upon the trustability of specific hardware and software, both of which are constantly changing. Where you have a single development auditing authority, they can charge for checking and signing something, and of course in the area of centralised systems development such an authority can readily be identified i.e. Microsoft. Even this doesn't totally prevent availability of a driver cryptographically signed as audited and stress tested against particular hardware being used on less reliable cheaper clone hardware, or (which could be much worse) the digital signature being used to squash competition in an otherwise clonable hardware market.

Truly decentralised trust management is an inherently very difficult thing to achieve, which is part of the reason why people are so dependant upon centralised banks to control the thing we call money, despite high charges and terrible service creating a sloping playing field (called economy while significantly misusing the term). A potential danger in the Linux world is a single vendor firstly getting a reputation for signing drivers responsibly, and then progressively using DRM techniques to turn this and connected markets into a rent-seeking monopolistic heirarchy.

(Log in to post comments)

driver and device reliability authentication and DRM monoopolisation

Posted Jul 22, 2003 13:54 UTC (Tue) by ggoebel (guest, #4487) [Link]

> Truly decentralised trust management is an inherently very
> difficult thing to achieve, which is part of the reason why
> people are so dependant upon centralised banks to control the
> thing we call money...

Actually decentralized banking worked quite well before central governments eliminated them. And if you examine the collapse of the corrupt second Bank of the US and the State Banking Era (1837-1862), you'd see that decentralized banking has remerged when trust and efficiency were required.

Open Source gives much the same advantage: trust and effieciency through an open distributed meritocracy. Who cares if you can get signed drivers? What is the signature worth?

Decentralized trust management is in fact easy to achieve and scale. We do it every day. You do it when you ask a friend for a recommendation on a contractor or dentist, write a book review on Amazon, or read Consumer Reports before buying a dish washer.

It is based on reputations and chains of trust. Linus accepts patches from people he trusts or code he himself will examine and vouch for. And likewise down the chain of trust to the person submitting her first patch. And as a direct consequence, bugs get fixed and features added in direct proportion to how much it matters to the people involved. Show me a centralized control process that scales better.

Your warning of danger is misplaced. The primary way a monopoly can form under open source licensing is through merit. Which is why everyone still regularly attempts to merge their forks back in with Linus' kernel. The only other way to gain a monopoly is through fear, which I'd argue is what SCO/Caldera is attempting at the moment.

You should read your Machiavelli. Any single vendor who depends on goodwill to maintain a position of power can lose that goodwill as easily as they gained it. Sure there is inertia to overcome, but even Linus could conceivably be knocked from his roost. And might have been in the not to distant past, if he hadn't started using BitKeeper and improved his ability merge patches faster.

driver and device reliability authentication and DRM monoopolisation

Posted Jul 22, 2003 17:43 UTC (Tue) by iabervon (subscriber, #722) [Link]

I disagree; I think that it would be pretty easy to add support for signed code. Of course, you could just turn it off, but users who want to use signed code wouldn't do that. Signing could be done by anyone, and the users could be made aware in this way of who has tested the code on what; you don't really need decentralized trust in such an application, because customers who want this sort of thing are generally getting support for somebody, trust them, and will ask them to verify anything else they might use. (Or they might have a testing environment themselves, and sign code which passes, and only allow signed code in production).

Isn't that what we use?

Posted Jul 31, 2003 16:20 UTC (Thu) by job (guest, #670) [Link]

But, we already have that!

Drivers for Linux must pass a quite rigorous quality test to become an official driver. Those are signed and distributed together, through the official channels.