info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Media Encryption and NPAPI
46 views
Skip to first unread message
Gary Mort
Jul 15, 2014, 10:35:55 PM7/15/14
to
NPAPI is deprecated and should not be used for plug-ins - so I'm curious on what the alternative is for things like encrypted media extensions.
It seems that rather then providing a method for anyone to create plugins for drm enabled media, Firefox is instead providing a single closed sourced implementation based on "DRM requires closed systems to operate as currently required and is designed to remove user control," https://blog.mozilla.org/blog/2014/05/14/drm-and-the-challenge-of-serving-users/
Obviously the above statement is not true, but it seems that instead of providing choice Mozilla has decided to force one solution onto everyone.
DRM protection could be as simple as passing all blocks of media data through a simple circular shift. The only "secret" part of the plugin would be the block size and the rotation size. Sure, such DRM is trivial to break, but then all DRM is eventually trivial to break - so if someone wants mild drm protection they could easily provide a plugin to do so.
However, there does not appear to be an api to provide small compiled bits of code/plugins. Am I missing something or is this really the case?
The ability to have competing DRM mechanisms has, in the past, provided protection from companies that have decided to abuse the need for DRM software to include all sorts of abuses, spyware, trojans, etc.
It seems that rather then providing a method for anyone to create plugins for drm enabled media, Firefox is instead providing a single closed sourced implementation based on "DRM requires closed systems to operate as currently required and is designed to remove user control," https://blog.mozilla.org/blog/2014/05/14/drm-and-the-challenge-of-serving-users/
Obviously the above statement is not true, but it seems that instead of providing choice Mozilla has decided to force one solution onto everyone.
DRM protection could be as simple as passing all blocks of media data through a simple circular shift. The only "secret" part of the plugin would be the block size and the rotation size. Sure, such DRM is trivial to break, but then all DRM is eventually trivial to break - so if someone wants mild drm protection they could easily provide a plugin to do so.
However, there does not appear to be an api to provide small compiled bits of code/plugins. Am I missing something or is this really the case?
The ability to have competing DRM mechanisms has, in the past, provided protection from companies that have decided to abuse the need for DRM software to include all sorts of abuses, spyware, trojans, etc.
Chris Pearce
Jul 16, 2014, 4:19:19 PM7/16/14
to
On 7/16/2014 2:35 PM, Gary Mort wrote:
> NPAPI is deprecated and should not be used for plug-ins - so I'm curious on what the alternative is for things like encrypted media extensions.
https://wiki.mozilla.org/GeckoMediaPlugins
> NPAPI is deprecated and should not be used for plug-ins - so I'm curious on what the alternative is for things like encrypted media extensions.
We will use this for OpenH264 and EME plugins.
> It seems that rather then providing a method for anyone to create plugins for drm enabled media,
approved by us will be allowed to run in Mozilla Firefox builds.
> Firefox is instead providing a single closed sourced implementation
> based on "DRM requires closed systems to operate as currently required and is designed to remove user control," https://blog.mozilla.org/blog/2014/05/14/drm-and-the-challenge-of-serving-users/
>
> Obviously the above statement is not true, but it seems that instead of providing choice Mozilla has decided to force one solution onto everyone.
>
> DRM protection could be as simple as passing all blocks of media data through a simple circular shift. The only "secret" part of the plugin would be the block size and the rotation size. Sure, such DRM is trivial to break, but then all DRM is eventually trivial to break - so if someone wants mild drm protection they could easily provide a plugin to do so.
due to things beyond our control.
> However, there does not appear to be an api to provide small compiled bits of code/plugins. Am I missing something or is this really the case?
Martin Husemann
Jul 17, 2014, 4:35:03 AM7/17/14
to dev-tech...@lists.mozilla.org
Chris Pearce schrieb:
have the ability to opt out.
Thanks!
Martin
> How is this different from what other browser vendors are doing?
It is actually *way* better than what everyone else does, as users still
have the ability to opt out.
Thanks!
Martin
gqu...@gmail.com
Jul 22, 2014, 12:39:26 AM7/22/14
to
> have the ability to opt out.
It's way better because users have to Opt in, if I understand correctly. If we're only giving users the option to opt out that is not different at all from other browser vendors.
hsiv...@hsivonen.fi
Jul 28, 2014, 5:10:04 AM7/28/14
to
On Tuesday, July 22, 2014 7:39:26 AM UTC+3, gqu...@gmail.com wrote:
> > have the ability to opt out.
>
> It's way better because users have to Opt in, if I understand correctly. If we're only giving users the option to opt out that is not different at all from other browser vendors.
Indeed, the plan is for EME-style DRM to be opt-in in Firefox.
> > have the ability to opt out.
>
> It's way better because users have to Opt in, if I understand correctly. If we're only giving users the option to opt out that is not different at all from other browser vendors.
AFAICT, it's opt-out on Chrome OS (the Widevine CDM shows up as a plug-in in the same UI that one would use for turning off Pepper Flash). It seems that there's an opt-out UI in IE11 (I haven't actually tested whether it works), but locating it is quite non-obvious. I failed to locate it on my first two careful attempts! (It's in a menubar menu but the menubar is hidden by default.) I haven't taken the time to examine if Safari has an opt-out UI somewhere.
0 new messages