Security Researchers Shouldn't Face DMCA Liability While Protecting Users From Faulty DRM
from the no-brainers dept
Longtime Techdirt readers may remember Alex Halderman, who conducted influential research into the problems created by CD-based DRM during his time as a grad student here at Princeton. He's now a professor at the University of Michigan, and he's working on a new project: seeking a DMCA exemption for security research related to defective DRM schemes that endanger computer security. We've seen in the past that DRM schemes can open up security vulnerabilities in users' computers, and Halderman argues that the public would benefit if security researchers could examine DRM schemes without being threatened with litigation under the DMCA for doing so.The DMCA gives the Librarian of Congress the power to grant three-year exemptions for DRM circumventions that are perceived to be in the public interest, and one of the exemptions granted in the 2006 triennial review was for CD-based DRM schemes that create security problems. Alex points out in his filing that the most serious security vulnerabilities created by DRM since that rule-making have come not from CD-based DRM but from video game DRM, which has not been adequately studied by security researchers. A ton of prominent security researchers (including Alex and my mutual advisor, Ed Felten) have endorsed Alex's request, arguing that the threat of DMCA liability hampers their research. We hope the Librarian of Congress is listening. If you live near Palo Alto or Washington, DC, you can sign up to testify about Alex's proposal (or others) by filling out this form.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Reader Comments
Subscribe: RSS
View by: Time | Thread
[ link to this | view in chronology ]
Re:
You flip the light switch, and the light comes on. Needing more in-depth understanding is just wrong! (Damn near unpatriotic!) You should always trust powers greater than yourself (US Gov, Big Corporations). If you flip the switch and the light doesn't come one, just call the help line and some helpful customer service rep will help you in fixing it.
[ link to this | view in chronology ]
Re: Re:
I filp on the switch. The light is suppose to come on, and it doesn't. I check the things I can check (is the bulb burnt? Is the breaker off?) and then I report "the light isn't working". I don't have to rip the house apart to be able to say "the light isn't working".
As for post #2:
1) If you aren't discussing the code, just the end results, there is no DMCA possible. Showing what happens as a result of installing a given DRM product on a computer system is a "eye" thing - report what you can see, right down to changes on the system. If there is a problem you can point to the box and say "the newly installed DRM is making this happen". You don't have to reverse engineer the whole product to find that out.
2) See #1 - if you aren't digging in their code but documenting only results, there should be no issues.
3) Encryption by itself should not be an issue. Again, the intent is to document faults / security holes created, not to reverse engineer the product.
3a) When in doubt, don't use the product.
The issue with this sort of an exemption is that the kindly professor could examine the DRM and understand it, publish a paper on it, when is in turn used by a third party to hack the DRM. They should be documenting the problems, not looking to find new ones.
[ link to this | view in chronology ]
Re: Re: Re:
Well, that's great, but that wouldn't allow you to point to a particular thing and claim that it is the cause for the failure in the light. And that is exactly the intent of research into whether DRM is opening security vulnerabilities. You have to be able to point to something in their code that is causing a problem. Otherwise it would be the equivalent of flipping the switch, seeing the light did not turn on, and claiming the bulb is burnt out. Sure, that COULD be the cause, but the bulb manufacturer (aka the company responsible for the DRM) would claim it could be the fuse, the wiring, a rolling brownout, or any number of other things if you don't do a thorough analysis. And they would be right to do so.
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re:
In addition, since the purpose of DRM is usually to limit the Illegal distribution of content, this "ripping apart" is not violating the purpose. The DMCA probably shouldn't go after the people doing the research that could help their product become better, they should focus more on the people who are using the flaws in their DRM to attack or otherwise compromise peoples computers.
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re:
In actuality the exception shouldn't be necessary, but since companies seem so intent upon abusing the DCMA to make people take down material they find objectionable (even if it isn't illegal), we find people asking for an additional safe harbor. Redundancy, thy name is government.
[ link to this | view in chronology ]
Re:
the tools and techniques used to test security are the same as those used to circumvent it.
you run a debugger and watch stuff move around a systems memory, you run a fuzzer to see how a program deals with arbitrary data, you run sniffers to see what goes over the wire or proxies to catch stuff before it comes in or goes out so you can see what it is or what it does.
the only difference between security research and cracking is what you intend to do with the information that you have gathered. researchers hack stuff and share what they know to improve the security of products while crackers share what they know in order to strip away protections.
[ link to this | view in chronology ]
Re:
No, it's not nearly enough. Security flaws are not intentional "features," and they are often not apparent until after someone has exploited them. If they could be easily observed outside the code, all of Window's many security flaws would have been readily obvious shortly after release.
A better question would be, why is this even a problem? If they use their knowledge to publish software patches for the purpose of circumvention, it would clearly still be illegal, and they could still be prosecuted.
[ link to this | view in chronology ]
Re: Re:
You don't have to disassemble a black box to know what it does. Crap in this end, modified crap out of that end. If you are concerned about a piece of software, don't install it.
I understand the desire to research and rip things apart, just like they would do to a bug or rock or whatever else they might study, and honestly, they can rip the DRM apart all they like - they just can't report it.
More to the point: If they think there is a problem contact the manufacture, offer your services for free (because you would do it for free anyway) and get their permission. I am sure that most companies would love to uncover and fix flaws before they become security nightmares.
[ link to this | view in chronology ]
Re: Re: Re:
you obviously have no clue what the adults are talking about... go back to the playroom.
[ link to this | view in chronology ]
Re: Re: Re:
You are officially insane if you really believe this and have obviously never done research. By that logic, I could completely understand how a car engine works by doing two things: putting in gas, oil, and water and analyzing the sounds, smells, etc that come out. It might work with simple binary systems, but not with complex ones.
If that doesn't convince you, let's consider what will happen once the researchers decide that some DRM causes a problem X. The company responsible for the DRM will simply claim the problem results from the environment in which the DRM operates and there will be nothing the researches can say or do to counter the claim. Of course that will never hap--oh wait except for those e-voting companies... and Sony... but certainly no one else.
[ link to this | view in chronology ]
1) Any type of DRM presentation is probably going to get hit with a DCMA takedown notice right before the conference begins. That has been the history of these things. Typically the conference organizers get jumpy and cancel the presentation, even if the takedown notice is bogus. At least with this protection the presenter would have something to show to the conference organizers.
2) Digging into the problems of a DRM package is probably going to get the owner of the DRM package to claim that part of the package has been reverse engineered, or that the data provided would permit reverse engineering. The only real protection is to explicitly say that this type of research is covered by the exception.
3) If the researcher is going to do a thorough job, some elements of the encryption are probably going to have to be explored. This does not mean the whole system needs to be cracked in all cases, but it is likely. Restricting the researchers is like telling a Doctor that he can examine a patient, but cannot touch them or use any type of x-ray, MRI, cat-scan, blood test, or anything else that lets them look inside the patient. This would work for some types of diagnosis, but there are a lot of things it would simply not work for.
[ link to this | view in chronology ]
A matter of trust...
However if you have any security sense about you you would want to crack and verify that that the software is really only doing what they claim and it should not be a crime to do so.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
vendors gag security researchers all the time
microsoft, cisco, adobe, novell... every vendor has used gag orders at one time or another to silence a researcher who has discovered a fatal flaw.
the real problem with DRM is that it's not real security, and so it doesn't hold up to real security research.
real security research is proven by peer review. you prove something is secure by having people try to break it. you show everyone how it works and invite them to come smash it. if they succeed, then you fix the vulnerability, and if they fail, then you can feel safe that your solution is secure, for now.
the anti-circumvention clause in the DMCA prevents this kind of research and so DRM technologies hide behind legalities. this is why DRM doesn't work and gets owned in a short period of time.
thanks to the sony rootkit fiasco, you now have a legion of researchers who mistrust all implementations of DRM in addition to the people who are interested in circumventing it.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
wha??
[ link to this | view in chronology ]
You have sucked so much corporate cock that the words that come out of your mouth don't make any sense.
And you are a total hypocrite too, you know why? Because copyright law is at this point so absurd that pretty much every one on this planet has infringed copyright at some point, yourself included. At this point you can't defend copyright in its entirety without being a hypocrite.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
All right, the gig is up. This sentence is all the proof we need that you're just a bored troll. I mean, nobody with a pulse could honestly believe such nonsense given how companies have treated security researchers who have uncovered flaws in their software in the past.
You are joking, right?
Right??
[ link to this | view in chronology ]
Maybe he has left to go make noises under some other bridge.
[ link to this | view in chronology ]