................................. To leave Commie, hyper to http://commie.oy.com/commie_leaving.html ................................. http://www.salon.com/tech/feature/2000/10/03/hacksdmi_fallout/index.html I spoke with half a dozen SDMI project members, all of whom requested anonymity. All hailed from computer, software or other technology-related firms; all were disgusted with SDMI and the so-called solutions the recording industry is pushing. For them, the hack-SDMI challenge is a huge opportunity. Some of SDMI's geekier members are actually rooting for the hackers to bust all the different watermarks. They want to return to square one -- and possibly be forced to come up with new models for music distribution that would be both consumer and artist friendly. For two years, executives at these technology companies have watched in frustration while the record labels have strong-armed the SDMI project to conform to their own ideas of the future of digital music. Although many of the participating technologists say they do want to help build an online music industry, they think that so far SDMI is going about it in entirely the wrong way. In any case, the companies building SDMI-compliant hardware and software music players are in a no-win situation: They will be forced to pay millions in licensing fees for a watermarking system that might not even work, and will undoubtedly anger consumers. And since hardware SDMI compliance is voluntary, there will almost certainly be companies that choose not to comply, putting those that do comply at a disadvantage. If consumers have an option to purchase an entertainment system that doesn't follow SDMI guidelines, why will they opt for an SDMI-compliant system that limits what they can do with their music? http://www.mp3.com/news/234.html Any SDMI software player must interface with the user's sound card through the operating system. The operating system needs to communi- cate with the hardware itself through a device driver, a piece of code provided by the hardware vendor. The interface for creating device drivers on any particular operating system is well-documented and published in order to allow hardware manufacturers to develop new hardware that will work with the existing operating systems. All that needs to be written to bypass all encryption, play limits, and similar mechanisms on a software player is a simple dummy device driver that takes the sound information provided by the program and records it to a file instead of playing it. Such a dummy driver can save the audio stream without loss of fidelity, since it receives the same information that would otherwise be sent to the sound card. Furthermore, since to a program this appears like any other sound device, there is no possible means for detecting this subterfuge without bypassing the operating system. There is no practical way for an SDMI player to counter such an attack. It would be ridiculous to expect the SDMI player to write to the hard- ware directly, since that would require the player to include its own device drivers for all conceivable sound cards. Additionally, reasonably designed operating systems like Windows NT or all unix flavors do not allow a program to directly access hardware devices in order to prevent a user's program from performing illegal or inappropriate operations. Also, since the device driver appears to the operating system just like any other soundcard, there is no means for the SDMI player to determine whether it is writing to a real or fake device. The only option preventing this problem is to have the SDMI player exist as a separate, physical device that takes the encrypted music stream and plays it out directly. Yet how many individuals will accept a separate music output on their computer when most computer speakers only have a single input? How many would be willing to switch cables when they want to stop listening to music and start playing games, or buy "SDMI compatible" soundcards that may be inferior to the one they already own?
