Earlier quoted context omitted.
If an open source system can run the CDM and is packaged in a proprietary widget; then I am allowed to take that open source system out of the widget, modify it to behave exactly as if it is still in the widget (so that it can still run the CDM) and redistribute the system to everyone.
It's very hazy. If the userland (running atop of the Linux kernel) is closed source then there's few things you can do. Also, you can't just rip out binaries and redistribute them at will, EULAs usually forbid it.
W3C green-lights adding DRM to the Web's standards
151–160 of 314 posts
Re: W3C green-lights adding DRM to the Web's standards
#152Earlier quoted context omitted.
The W3C is the guardian of the world wide web, a system for disseminating information publicly and globally to all those who may benefit from it. By standardizing DRM for video, they are giving legitimacy to a technical kludge that is designed specifically to prevent the dissemination of information. There are legitimate reasons why someone may wish to save a video to their hard drive, just like they can save an imag…
If I had my way we wouldn't have copyright at all. It seems idiotic to me for the same reasons patents are. But we do, and so just as you say there are "legitimate reasons" why someone may wish to save a video, there are too "legitimate reasons" someone may want to share their work in a protected manner. It's a product. If you don't like it don't buy it. There is no part of this that forces the user to view only DRM…
Although it seems the word "copyright" is also a bit of doublespeak these days. In general it doesn't go out of its way to give authors the right to control how publishers distribute copies any more, it's been co-opted as a system for publishers to deny every individual the the ability to make their own copies for any reason. If you ask me they should call it a copy-block instead of a copy-right.
Re: W3C green-lights adding DRM to the Web's standards
#153Earlier quoted context omitted.
In most DRM systems the information is distributed encrypted. The decryption keys are given to technology developers who have specifically promised to obey the DRM rules, as well as to make their technology hard for users to understand or modify so that the users can't easily undo the restrictions or extract the decryption keys. Hence a browser developer or OS developer or developer of whatever software is in questio…
I see no way how an open source system can implement any effective DRM standard while staying open source. If a proper open source system has a component that enforces DRM, and is functional when I download it, then it includes those keys; but gives me an unconditional right to use and modify it. And I am physically able to modify it, un-implementing those restrictions. If part of the system cannot be modified by me,…
"Open Source" definition does not include any clauses that require hardware manufacturers to provide you encryption and/or signing keys, so you could run your code. GPLv3 and "Free Software" are what you're looking for.
Re: W3C green-lights adding DRM to the Web's standards
#154Earlier quoted context omitted.
This is a bit of an exaggeration, we have had content like this on the web for years with proprietary technologies like flash, silverlight ,activeX and highly obfuscated JS. Not to mention the amount of content locked into walled gardens and proprietary app stores etc. The W3 proposals suggested do not in fact mandate browser vendors implement any DRM scheme to remain 100% standards compliant. This is myth that gets…
Browser vendors don't have to implement any DRM scheme, but they will and sites will use them. What this means in practice is that there will be 100% standards compliant, pure HTML5 websites that can only legally be rendered in specific, proprietary browsers. The stated purpose of HTML5 EME is to make it a criminal offence under the DMCA anti-circumvention clause to develop an unauthorised browser or extension that d…
Re: W3C green-lights adding DRM to the Web's standards
#155Ok, it sounds to me like this is way, way, over blown. First, the DRM is NOT going to be built into the browser it self. It's basically a new name for a plug in system, nothing more. So, to everyone who thinks they can roll their own browser and avoid the DRM, no you will not be able to. It's not bad or good for consumers, at best, it's about the same. It's very simple, studios will not allow you to rent their movies…
Re: W3C green-lights adding DRM to the Web's standards
#156Earlier quoted context omitted.
Open source OSes will probably not have CDMs available, except when prepackaged into a proprietary widget (Android, ChromeOS, B2G is Mozilla decides to play ball)
If an open source system can run the CDM and is packaged in a proprietary widget; then I am allowed to take that open source system out of the widget, modify it to behave exactly as if it is still in the widget (so that it can still run the CDM) and redistribute the system to everyone.
Re: W3C green-lights adding DRM to the Web's standards
#157Earlier quoted context omitted.
"Some content cannot go anywhere without DRM" Why should we care? The web is not supposed to restrict users. If Universal does not like it, they can go somewhere else -- they have the cable TV system with all its restrictions and anti-freedom design.
No, the web is all about restricting users. It's baked into several HTTP error codes (403 and 401 off the top of my head). SSL is also rather popular. I assume you mean that the browser shouldn't restrict users? Like, if I stream a movie from Netflix, I should be able to also save it locally so I can take parts of it to use in my fair use arts project? Sorry. Never going to happen. Forcing this use case that _people…
This is obtuse. The HTTP and HTML specs provide standards for interoperation. Some modes of operation are forbidden for some users, and the specification provides a way for that to be communicated. It sounds like you're taking a whole-system approach to freedom, which is certainly valid (see the AGPL for a "free" response). But it's orthogonal to the issue at hand, which is interoperability. Any client can still implement the specification.
That said, I'm completely at a loss as to how you believe SSL "restricts users".
> I assume you mean that the browser shouldn't restrict users? Like, if I stream a movie from Netflix, I should be able to also save it locally so I can take parts of it to use in my fair use arts project?
The browser should implement an interoperable standard. That standard should be accessible to everyone. Any browser vendor should be able to, once they have properly implemented the specification, stream a movie from Netflix (this is the very thing that EME makes impossible).
> Sorry. Never going to happen. Forcing this use case that _people want_ off into plugins isn't going to make anything more "free".
This does not have to be reality, no matter what vendors say. There's a reason digital restriction management was forced out of the music space: it's ineffective, it's consumer-hostile, and it hinders innovation. Many of us are mad precisely because the vendors played hardball in their negotiations, and the W3C wimped out. Vendors need the web more than the web needs the vendors, but the W3C didn't take an equally hard line back and we're left with a decision that screws everyone but media companies.
> That's like selling a Roku box that can only play Ted and Youtube videos and saying that it's better because it's totally free, and open, and doesn't restrict its users. Well, sure, that is the best kind of correct. But only because you yanked everything that wasn't free. You didn't actually add any value over the standard Roku box that plays Netflix and Amazon.
The problem is, this decision hinders innovation. It is now much harder for a Roku competitor to exist, because before they can get off the ground they have to comply with byzantine demands of old media companies. "totally free, and open, and doesn't restrict its users" is the future of communication and computing (at least technically, politically is a different story). This decision is mired in the past.
Let's circle back to this:
> Forcing this use case that _people want_ off into plugins isn't going to make anything more "free".
This is exactly what EME does. The digital restriction management "extensions" are plugins. They are binary blobs, tied to specific hardware implementations. This regresses the web back to the "best viewed on Windows in IE 2.3" days, where interoperation is dead and cross-platform compatibility is a hippy dream.
And that's why people are mad at the W3C for no longer representing what the web is supposed to be.
Re: W3C green-lights adding DRM to the Web's standards
#158Re: W3C green-lights adding DRM to the Web's standards
#159Isn't this good news for video distributors who haven't converted over to HTML5 (native video support) because of lack of support for DRM?
Distributors may not be happy once they discover that Safari supports FairPlay DRM, Chrome supports Widevine DRM, IE supports WMDRM, Samsung phones support SamDRM, HTC phones couldn't afford to license any DRM, etc.
Edit: The interface between the DRM servers and your backend code isn't standardized either, so content providers still have to do a bunch of DRM-scheme-specific development work. Basically, they standardized just enough to allow sites with DRM to claim they're 100% HTML5, it barely improves interoperability at all.
Re: W3C green-lights adding DRM to the Web's standards
#160Does anyone know if this EME Plugins would be able to access browser data or what kind of data would be available to this plugins ?