121–130 of 222 posts
Earlier quoted context omitted.
Plausible sure. anyone using any other plugin is also plausible, though much less likely. The point is since it's not standard Linux and BSD will get the shaft.
Wildvine works on Linux today.
Earlier quoted context omitted.
DRM is fundamentally security by obscurity. Being closed source is the only way to maintain obscurity, and thus the illusion of security.
I disagree. Technologically it is possible to build a content protection system without obscurity, using open source software and open source hardware (and suitable cryptographic bootstrapping). That no one chooses to do so is another matter.
The effect of DRM is to prevent the user from doing things that would otherwise be technically possible, such as copying. Once the software has decrypted the media, it can do whatever it wants with it. It is just so designed that what it wants to do with it is not the same as whatever the user wants to do with it.
Free or open-source software give the right and the ability to the user to modify what the software does. So if a feature is missing (save a backup copy), the user can add it (or pay someone to).
I piece of software cannot at the same time: * be able to decrypt a video * be able to be changed at the users' will * be prevented from doing certain things the user wants.
If you merely write a piece of open-source software that lacks the ability to save a copy, you merely have a missing feature that can be added by anyone who wants to fork it, you are not preventing copying.
If the decryption is done in hardware, the problem is the same, just shifted. If people have the ability to change the hardware, then we're back to square one, and if they don't, then it's not a free/open-source system.
Can EME prevent people from doing 30fps screengrabs of their screen and dump all into an mp4 file using FFmpeg or such? As someone else pointed here: > You can't simultaneously give us the content and not give us the content.
The server can send an encrypted blob to your browser which hands it off to the DRM module which can hand it off to the system's ring -2 PAVP/Trustzone/etc. stuff that only runs signed firmware which passes it encrypted over the PCIe bus to the gfx hardware which passes it encrypted via HDCP2 to the monitor. So in principle fully encrypted paths that can'e be screengrabbed exist. Not all DRM makes use of those compon…
Anyone know if the EFF plans to throw some of their weight behind this particular appeal?
If the W3C does this, it will be time -- regrettably -- to turn away from that organisation and make a completely new one that exists to serve users of the Web rather than those seeking to monetise it. That Tim Berners-Lee has lent his name to this hijacking is shameful.
The only time there has been a half successful splintering off of the W3C was WHATWG, and WHATWG only worked because it was backed by the browser vendors themselves.
W3C takes advantage of the ambiguity of what the EME spec and "standard" DRM is. People unfamiliar with the spec may think it's the end of plug-ins and a spec for a DRM that is somehow open, implementable and cross-browser. It's nothing like it. It's a small JS API that launches the same old, fully closed, proprietary DRM solutions. The NPAPI has been replaced with DMCA-protected interface, and previously separate DR…
I think that is a bit of an exaggeration. First, for some browsers, the DRM scheme is built in, not any kind of plugin architecture. Second, without EME, the state of the art for DRM video was to run the whole playback path through a plugin. Now, only the DRM bit is generally going to be hidden in binary blob (whether plugin or not.) This has some important advantages: * Web content authors can build video players us…
this isn't a pro in my books - i want DRM to be a difficult and cumbersome stack to use. More specifically, i want the end user to go through hassle to obtain the proprietary plugins, so that the end user feels the hurt from DRM. This makes a non-DRM version much more simple to view (just click and play), so that users would vote with their wallet, and use the non-DRM version (and avoid the DRM version).
If making DRM video easy to play for end users is the goal, then yes, web-DRM is doing it. But it will make DRM more prevailent, as end users will have no reason to try avoid DRM, thus, making web less open.
DRM is a non-starter and is in reality defective by design. Pirates have created markets where there were none and are an important part of every entertainment eco-system. It's been that way since the beginning. This is just another in a long string of bad decisions that attempts to give major distribution channels far more control than they deserve or could ever manage responsibly. If you want to make money in enter…
I disagree that it does no harm. I agree with this quote from the article:
"If EME is ratified by the W3C, the FSF expects it to cause a long-term increase in the amount of DRM on the Web, by simplifying the DRM implementation process for streaming services."
Standardization is explicit support and encouragement.
Earlier quoted context omitted.
I think that is a bit of an exaggeration. First, for some browsers, the DRM scheme is built in, not any kind of plugin architecture. Second, without EME, the state of the art for DRM video was to run the whole playback path through a plugin. Now, only the DRM bit is generally going to be hidden in binary blob (whether plugin or not.) This has some important advantages: * Web content authors can build video players us…
> same technology stack (HTML5 video+JS) for DRM-ful video as for DRM-free video this isn't a pro in my books - i want DRM to be a difficult and cumbersome stack to use. More specifically, i want the end user to go through hassle to obtain the proprietary plugins, so that the end user feels the hurt from DRM. This makes a non-DRM version much more simple to view (just click and play), so that users would vote with th…
so you want to make stuff like netflix as much of a PITA as possible? why? why be this vindictive?
Earlier quoted context omitted.
I think that is a bit of an exaggeration. First, for some browsers, the DRM scheme is built in, not any kind of plugin architecture. Second, without EME, the state of the art for DRM video was to run the whole playback path through a plugin. Now, only the DRM bit is generally going to be hidden in binary blob (whether plugin or not.) This has some important advantages: * Web content authors can build video players us…
> same technology stack (HTML5 video+JS) for DRM-ful video as for DRM-free video this isn't a pro in my books - i want DRM to be a difficult and cumbersome stack to use. More specifically, i want the end user to go through hassle to obtain the proprietary plugins, so that the end user feels the hurt from DRM. This makes a non-DRM version much more simple to view (just click and play), so that users would vote with th…