DRM as Central Planning

by on January 4, 2007 · 8 comments

The document I discussed in my previous post also provides concrete examples of a point I’ve made before: DRM is the technological equivalent of central planning. In their efforts to prevent piracy, the Windows A/V system is becoming more and more monolithic, with the operating system performing more and more functions that would traditionally be performed by third party software, and prohibiting third party software from overriding those functions. Monolithic software has many of the same flaws that centrally planned economies do: the thousands of third-party software developers out there have local knowledge about what their customers want that Microsoft does not possess. Hence, the more Microsoft centralizes decisions about what A/V features the OS will have, the more likely they’ll screw up and fail to provide needed functionality. That gives you lovely outcomes like this:

As well as overt disabling of functionality, there’s also covert disabling of functionality. For example PC voice communications rely on automatic echo cancellation (AEC) in order to work. AEC requires feeding back a sample of the audio mix into the echo cancellation subsystem, but with Vista’s content protection this isn’t permitted any more because this might allow access to premium content. What is permitted is a highly-degraded form of feedback that might possibly still sort-of be enough for some sort of minimal echo cancellation purposes.

The requirement to disable audio and video output plays havoc with standard system operations, because the security policy used is a so-called “system high” policy: The overall sensitivity level is that of the most sensitive data present in the system. So the instant any audio derived from premium content appears on your system, signal degradation and disabling of outputs will occur.

And, even more frightening, this:

Beyond the obvious playback-quality implications of deliberately degraded output, this measure can have serious repercussions in applications where high-quality reproduction of content is vital. For example the field of medical imaging either bans outright or strongly frowns on any form of lossy compression because artifacts introduced by the compression process can cause mis-diagnoses and in extreme cases even become life-threatening. Consider a medical IT worker who’s using a medical imaging PC while listening to audio/video played back by the computer (the CDROM drives installed in workplace PCs inevitably spend most of their working lives playing music or MP3 CDs to drown out workplace noise). If there’s any premium content present in there, the image will be subtly altered by Vista’s content protection, potentially creating exactly the life-threatening situation that the medical industry has worked so hard to avoid. The scary thing is that there’s no easy way around this – Vista will silently modify displayed content under certain (almost impossible-to-predict in advance) situations discernable only to Vista’s built-in content-protection subsystem.

In previous versions of Windows (and every other sane OS on the planet) if an operating system’s built-in libraries didn’t provided needed functionality (or had “features” that degraded the OS’s functionality), a third-party developer had methods of patching the OS to make it behave in the way required by the developer’s customers. In the brave new world created by the DMCA, such modifications are federal crimes if they in any way modify “technological protection measures,” which in this case is Vista’s entire A/V subsystem. The only way a third-party developer can get a needed “protection” feature in Vista turned off is for them to petition Microsoft to provide the functionality they need. And if Microsoft is too busy or incompetent to add the feature, or they decide that allowing the functionality would conflict with one of its other goals, that developer–and his customers–are out of luck.

This is particularly problematic because often the best ideas come from unexpected sources. Technological platforms are often designed for one use and then find a “killer app” that’s totally different. This kind of open-ended experimentation is hampered when the needs of copy protection require that all possible uses of the system be spelled out in advance by Microsoft’s engineers.

Comments on this entry are closed.

Previous post:

Next post: