Microsoft, Netflix y Google quieren agregar DRM a HTML5 [ENG]

El mecanismo pretender no tener que hacer uso de plugins para transmitir vídeo con DRM (digital restrictions management). Las personas que están a favor dicen que esto simplificara la transmisión de vídeo y que permitirá alcanzar a los servicios de streaming alcanzar mas plataformas. Los que se oponen dicen que estas medidas no lograran detener la "piratería" y añadirán una complejidad innecesaria a los navegadores. Vía reddit: http://www.reddit.com/r/linux/comments/17h3d0/dont_let_microsoft_and_netflix_get_drm_in_html5/

[#8 Desactivado]

El DRM no es bueno, es lo siguiente. Te compras una película licencia para reproducir una película, la intentas ver en un monitor / proyector que no está certificado y no te dejan. Vas a The Pirate Bay, la vuelves a descargar en FullHD y listo. Supongo que ya os podéis imaginar donde irá el directamente esta persona cuando quiera descargar otra película.

[#32 Desactivado]

#8 ya os podéis imaginar donde irá el directamente esta persona cuando quiera descargar otra película.

Obviamente si lo que quiere es descargarla, irá a internet, independientemente de si quiere verla o no

Ya, ya sé que donde pones descargar querías poner ver, pero es que me ha hecho gracia.

[#37 leader]

#32 Esto... DRM en web. ¿Sabes que también se puede pagar por descargar una película de internet? ¿Sabes que hay sitios web donde hay películas, música, series y demás de pago?

No te culpo, estos gilipollas de la industria han creado gente como tú, que asocia descargar e internet con torrent y megaupload.

[#41 Desactivado]

#37 o te has confundido al citarme, o no has entendido para nada mi comentario.

[#42 leader]

#41 No me he confundido al citarte, aunque no descarto no haberte entendido

Lo que quería decir. Cuando #8 habla de "comprar una película" creo que habla de comprarla en internet y descargarla. Cuando el usuario vea que tiene mil trabas para ver esa película, irá a The pirate Bay y la volverá a descargar en FullHD y gratis, sin tantas complicaciones.

Cuando vuelva a querer descargar una película, no volverá a comprarla, irá directamente a The Pirate Bay, que es donde le resulta más compatible con su monitor y le ponen menos trabas (Sin DRM).

Por eso no entiendo tu comentario de que volverá a "internet". Me parecía que asociabas "descargar" a piratería.

Aunque puede que haya entendido mal.

[#44 Desactivado]

#42 bueno, bah, muchas vueltas le estamos dando a entender o no los comentarios de los otros , y total, al final estamos todos de acuerdo.

Ah, te aclaro por si acaso una cosa (lo de han creado gente como tú), que conste que yo he comprado cosas por internet para descargar. Es más, una vez compré un libro con DRM, sabiendo que lo tenía y simultáneamente descargándome ese mismo libro con el DRM ya quitado por otro lado (de hecho no sé si descargué el que no tenía DRM antes o después de comprar, fue cosa de 1 minuto o 2 de diferencia). Lo hice así porque me pareció justo el precio, y además que fue compra directa al autor (bueno, a través de amazon), sin editorial por en medio quedándoselo casi todo (bueno, amazon quedándose algo). Curiosamente en amazon estaba el mismo libro mucho más caro vendido por la editorial

[#5 Desactivado]

Inocentes criaturitas... me pregunto cómo es posible que personas que han tenido la capacidad de fundar empresas tan lucrativas sean, sin embargo, tan tontas como para pensar que pueden poner puertas al campo. DRM en la web??? Por el amor de Dick, tardaron nada y menos en reventar el cifrado de los blue ray en una época que poca gente tenía lectores. ¿Cuánto se piensan que van a tardar en reventar algo a lo que puede acceder cualquiera sin hardware adicional?

[#27 GoDie]

#5 Bueno lo de los blu-ray fue por una cagada, y además MONUMENTAL en manejar la clave, si no seria bastante improbable que nadie lo descifrara

[#33 llorencs]

#5 El problema es que pretendan imponerlo

[#38 Brucen]

#5 Aquí como siempre en meneame somos los más listos. ¿Crees que estas empresas no lo saben? pero quién te crees que les provee del material audiovisual que luego van a transmitir? pues la industria audiovisual. Y estas últimas son las que "luchan" contra la piratería con cualquier medio al alcance, aunque no valga para nada. Las grandes empresas que mencionas al final acaban cediendo para poder ofrecer algo a los usuarios. Conste que estoy en contra del DRM pero puedo entender las razones de por qué ceden.

[#2 Desactivado]

Curioso, porqué se menciona a Microsoft y a Netflix en el titular modificado en castellano respecto al original, pero no a Google que es el tercero que lo ha propuesto y que se menciona en la noticia. Me parece un poco parcial dejar a Google fuera, si se modifica el titular al menos se puede hacer poniendo todo.

Para el que quiera leer algo en castellano: https://plus.google.com/+LinuxMagazineEdici%C3%B3nenCastellano/posts/YdibQrUZa4h

[#4 monty_oso]

#2 Corregido.

[#6 Desactivado]

#4 Mejor así, gracias.

[#7 monty_oso]

#2 Ya que tengo la oportunidad de hacer de abogado del diablo lo haré citando uno de los comentarios que leí en reddit:

fiftyorange

Hixie, Google's rockstar web standards guy and the editor of the HTML spec, was the one who refused to put DRM in the HTML5 spec. Probably worth pointing out.

editado:

http://lists.w3.org/Archives/Public/public-html/2012Feb/0274.html

He says, and I quote:

I believe this proposal is unethical and that we should not pursue it.

El correo al que se hace referencia:

From: Ian Hickson
Date: Tue, 21 Feb 2012 23:46:46 +0000 (UTC)
To: Adrian Bateman
cc: Maciej Stachowiak , "HTML WG ([e-mail])" , David Dorwin , Mark Watson
Message-ID:

On Tue, 21 Feb 2012, Adrian Bateman wrote:
>
> We have been collaborating on an API to enable encrypted media in HTML
> that we think can be implemented in all browsers and support any
> container/codec and content encryption solution without making major
> changes to the HTML Media element specification. We think it solves most
> use cases without being overly large or complex.
>
> We'd like to get people's feedback on the proposal. It is posted here:
> http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html

I believe this proposal is unethical and that we should not pursue it.


> Many content providers and application developers have said they can't
> use and because HTML lacks robust content protection.

The proposal above does not provide robust content protection, so it
would not address this use case even if it wasn't unethical.

--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

Las negrillas son mías.

[#10 monty_oso]

#2 #7 #9 Al parecer mis anteriores entradas se referían a opiniones aisladas de algunos empleados de Google como parece indicar este correo:

From: イアンフェッティ
Date: Tue, 29 Jan 2013 15:30:54 -0800
Message-ID:
To: Glenn Adams
Cc: "Robert O'Callahan" , "Tab Atkins Jr." , Paul Cotton , "[e-mail]" , "David Dorwin ([e-mail])" , Adrian Bateman , Mark Watson

On Tue, Jan 29, 2013 at 2:50 PM, Glenn Adams wrote:

>
> On Tue, Jan 29, 2013 at 3:37 PM, Ian Fette (イアンフェッティ) wrote:
>
>> Robert, I agree with your objectives and personally would support them
>> but I don't support the objection as I don't believe that advancement to
>> FPWD should be a time for people to demand resolution on particular issues.
>> LC or CR sure, but not on FPWD. It's a procedural thing for me.
>
>
> What is the official Google position on EME? Does Google intend to deploy
> EME in Chrome? Has Google determined which CDMs it will initially support?
>

The official position is that Google supports publication of EME as a FPWD.
We have added the APIs to Chrome and are working on early implementations
with content providers to try and flush out issues and provide more data
and implementation experience to the process.

[#11 monty_oso]

#10 enlace al correo: http://lists.w3.org/Archives/Public/public-html-admin/2013Jan/0202.html

[#9 monty_oso]

#2 gmail.com no apoya esto.

Cito otro comentario de reddit:

OmnipotentEntity

Sorry, I went back to the mailing list for this particular issue and here's the most recent e-mail string on this particular topic:

http://lists.w3.org/Archives/Public/public-html-admin/2013Jan/0102.html

> This is a Call for Consensus (CfC) to publish as a First Public Working Draft (FPWD) the following Encrypted Media Extensions document:

> https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media-fpwd.html

> Silence will be taken to mean there is no objection, but positive responses are encouraged. If there are no objections by Wednesday January 30, this resolution will carry.

> Considerations to note:

> - As a First Public Working Draft, this publication will trigger patent policy review.

> - As a Working Draft publication, the document does not need not be complete, to meet all technical requirements, or to have consensus on the contents.

> /paulc
HTML WG co-chair

> Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: [phone] Fax: [phone]

----

It got 10 first level replies.

Publicly Support (domain of e-mail address):

* [microsoft.com](http://lists.w3.org/Archives/Public/public-html-admin/2013Jan/0102.html) (same link as above)
* [cablelabs.com](http://lists.w3.org/Archives/Public/public-html-admin/2013Jan/0104.html) [(website)](http://cablelabs.com/)
* [foliot.ca](http://lists.w3.org/Archives/Public/public-html-admin/2013Jan/0121.html)
* [ocallahan.org](http://lists.w3.org/Archives/Public/public-html-admin/2013Jan/0130.html) (supports concept, has issues with impl)
* [irdeto.com](http://lists.w3.org/Archives/Public/public-html-admin/2013Jan/0134.html) [(website)](http://irdeto.com/)
* [verimatrix.com](http://lists.w3.org/Archives/Public/public-html-admin/2013Jan/0135.html) [(website)](http://verimatrix.com/)
* [nokia.com](http://lists.w3.org/Archives/Public/public-html-admin/2013Jan/0192.html) [(website)](http://www.nokia.com/us-en/)

Publicly Oppose:

* [ping.de](http://lists.w3.org/Archives/Public/public-html-admin/2013Jan/0103.html) [(website)](http://ping.de/index_eng.html)
* [gmail.com](http://lists.w3.org/Archives/Public/public-html-admin/2013Jan/0108.html)
* [geekhood.net](http://lists.w3.org/Archives/Public/public-html-admin/2013Jan/0110.html)
* [hixie.ch](http://lists.w3.org/Archives/Public/public-html-admin/2013Jan/0149.html) [(website)](http://hixie.ch/)

The full discussion can be found here:

http://lists.w3.org/Archives/Public/public-html-admin/2013Jan/thread.html#msg102

The blog post in question was also submitted to the mailing list:

http://lists.w3.org/Archives/Public/public-html/2013Jan/0172.html

And it got these replies:

http://lists.w3.org/Archives/Public/public-html/2013Jan/0177.html

> While I would normally ignore such blog posts, since this was sent to the
WG and is presented as a "technical review", I feel the need to warn
members that it is riddled with inaccurate statements and comparisons,
misunderstandings of the spec, and assumptions by the author. If you choose
to read it, please do so with a critical eye.

----

http://lists.w3.org/Archives/Public/public-html/2013Jan/0179.html

> Perhaps you could point out a few of the inaccurate statements? Or a few
of the comparisons that led me to the erroneous conclusions in the post?
Or tell me what am I misunderstanding?

> Editor's of specifications usually do that kind of thing. They don't
ignore technical input, even if it is a blog post. They especially don't
ignore input if it is one of their colleagues attempting to do a
critical read of the specification they put together.

> I've authored and edited a number of W3C specifications over the years.
I know how to read them. I read your specification, carefully, and my
blog post outlines the conclusions I came to. So, if somebody that has
actually built DRM systems and has plenty of experience writing
specifications came to all of these erroneous conclusions, how much of a
chance does the rest of the world have at understanding what you're
attempting to accomplish?

> Let me be crystal clear. I would be delighted if this specification
figured out how to create an open and inter-operable DRM ecosystem that
was simple to implement, that was fair to content creators and viewers
alike, and that would work across all browsers on all platforms. Really,
I would.

> The specification that is in front of us doesn't do that, so I pointed
out why it doesn't do that. I would like you to tell me exactly why I am
wrong so that I can become a supporter of your specification. Ignoring
me is not going to make the problems with your specification go away.

----

http://lists.w3.org/Archives/Public/public-html/2013Jan/0180.html

> You appear to misunderstand the scope/goals of the EME spec. Defining "an
open and inter-operable DRM ecosystem" is not in scope. The EME abstract
[1] makes this clear, so it is clear that you start your comments based on
a false assumption.

> The issue of content key protection is also clearly marked out of scope
[2], so your comments on protection of key secrets are similarly based on a
false assumption.

> I'd suggest you carefully reread the abstract and other statements in EME
that clearly delineate the scope of this spec, and reformulate your
comments accordingly.

----

http://lists.w3.org/Archives/Public/public-html/2013Jan/0189.html

> Very well said, Glenn.

> Manu, I had started writing a detailed reply, but there were just so many
issues that I chose a simple reply of caution. I welcome technical input
and suggestions, but there are few suggestions for improving
the specification among the theme that content protection is impossible so
we shouldn't bother. Such a discussion or personal opposition are fine, but
they should not be presented as a technical review of
a specification. Constructive technical input from a colleague generally
doesn't include hyperbole and statements like "Wow, what a fantastically
bad idea." and "So. Bad." It appears you had formed an opinion before even
reading the specification:
https://plus.google.com/102122664946994504971/posts/4aHTBBfxRfW ("This is
awful..." followed by "I haven't read through the spec yet...")

> If you are truly interested in improving the specification and would like
to start another thread focused on technical feedback (preferably on
public-html-media where most technical discussion is occurring), I'd be
happy to discuss your concerns.

----

http://lists.w3.org/Archives/Public/public-html/2013Jan/0211.html

> I was trying to be clear about what I would like to see, not the problem
that the specification is attempting to solve, which continues to be
stated in vague terms. That statement above wasn't the basis for my
technical analysis, I state the basis in the blog post.

> What problem is the specification attempting to solve? I'm not being
facetious, I am trying to understand.

> I didn't assume content key protection was in scope. I know what the
spec text says. I'm asserting that the spec should say /something
substantial/ about content key protection. At least let folks know that
transmitting keys in the clear is a horrible security practice and that
they should never use Simple Decryption.

> The spec marks content key protection out-of-scope and then it goes on
to transmit decryption keys in the clear. That seems incredibly backwards.

> The only protection mechanism that is actually spec'd is this:

> https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#simple-decryption

> The key isn't protected at all, it's transmitted in the clear. My
assumption is that this is done to get around the "multiple
inter-operable implementations" requirement at W3C. However, the
"protection" mechanism provided in that section basically reinvents TLS
(but in a way that is not secure at all) and it is REQUIRED to be
implemented by browser manufacturers.

> Alternative: Have the browser generate a random token that could be
tracked by the license server to ensure that a single clear-key can't be
reused by another User Agent. This solution has it's own problems, but
it isn't that much more complicated than what's already in the spec and
it would at least provide some level of "protection" against decryption
key copying. It wouldn't be that difficult to implement this and it
would provide more security than the no-op that is "Simple Decryption".

> I did read the abstract, multiple times. I also read the specification
multiple times. You have not presented any information in this e-mail
that I didn't know when I wrote the blog post. The blog post remains
unchanged.

> I'm trying to understand why the technical points I raised in the blog
post are wrong. When I say something like:

> Not having a key protection mechanism for the Simple Decryption feature
makes the system open to attack.

> and you reply with:

> Key protection is out of scope!

> That doesn't address the point I am making. To address the point I'm
making, you'd have to do at least one of the following:

> 1. Fix key protection in the Simple Decryption mechanism.
> 2. Take Simple Decryption out of the spec.
> 3. Don't make Simple Decryption a required feature.

----

And it continues on like that, it should be noted that one of the guys arguing against the blog author had a google.com email address.

Esta es la repuesta de gmail.com que a mi parecer resume algunos de los problemas mas importantes de este intento de agregar DRM a HTML5:

From: Tab Atkins Jr.
Date: Tue, 22 Jan 2013 12:25:25 -0800
Message-ID:
To: Paul Cotton
Cc: "[e-mail]" , "David Dorwin ([e-mail])" , Adrian Bateman , Mark Watson

On Tue, Ja

[#3 majestad]

Añadir restricciones de derechos a una plataforma abierta por definición. Con dos cojones, al más puro estilo mega corporation.

[#24 Frippertronic]

#3 Ya se quieren cargar al HTML5 antes de que comience a andar en serio (porque si lo hacen, no triunfará)

#20 Tienes razón, debían de haber dicho complejidad INNECESARIA. ¿ahora mejor? El resto de cosas que citas aportan un valor adicional, que hace que le precio (la complejidad) sea menor que el beneficio. El DRM, no sólo no aporta valor adicional, sino que, de hecho, resta valor (por definición). Creo que comprenderás la diferencia.

[#47 PythonMan8]

#3 Lo de "restricciones de derechos" es una poyez que se sacó de la manga Richard Stallman. DRM significa "Digital Right Management" y es un sistema para evitar la copia ilegal de contenido sin el consentimiento del autor y/o distribuidor que tiene los derechos de explotación. El DRM es un sistema que el que quiere lo utiliza y el que no no. Si tu quieres publicar tus videos sin DRM nadie te obliga a ponerlo, pero si el vecino por que le sale de la punta del cipote sí quiere publicarlo con DRM está en su derecho. Los retrasados mentales que lo quieren todo gratis por que les sales de los huevos lo que tienen que hacer irse a tomar por culo.

Por cierto, no sé que puta manía es esa de mezclar "Linux" contra el DRM. Que yo sepa Linus Torvald nunca ha sugerido a nadie que se piratee las Windows. Cuando programa Linux y lo deja libre, lo hace porque a él le sale de la punta del cipote. Y si Mierdasoft quiere cobrar por Windows, está en su derecho (aunque eso no le exculpa de sus prácticas ilegales de monopolio, razón por la cual habría que cerrar la empresa y meter a sus dirigentes en prisión durante 20 años )

Sólo espero que Firefox se incorpore al grupo y podamos tener al fin un sistema transparente y eficaz para ver contenido de pago sin más que utilizar un navegador y sin instalar software adicional.

[#48 monty_oso]

#47

"Sólo espero que Firefox se incorpore al grupo y podamos tener al fin un sistema transparente y eficaz para ver contenido de pago sin más que utilizar un navegador y sin instalar software adicional. " Si lees mis comentarios veras que segura siendo necesario usar software adicional.

"El DRM es un sistema que el que quiere lo utiliza y el que no no." No siempre, por ejemplo el DRM de HDMI no es opcional. Ese DRM por ejemplo evita que yo pueda gravar lo que transmite mi cámara fotográfica por ese medio.

[#50 monty_oso]

#47 Muchos creemos que "Digital Right Management" es un eufemismo que oculta la verdadera función de de estas tecnologías.

Algunas personas piensan que el lenguaje modifica las opiniones de la gente, si esto es cierto vale la pena intentar que el lenguaje exprese las posiciones políticas que uno considera correctas. El llamar al DRM digital restrictions management no es muy diferente a los esfuerzos por evitar el uso de la palabra negro en favor de el prefijo afro o intentar hacer el lenguaje mas incluyente con lo femenino.

Esto no se trata del "todo gratis", se trata de tener control sobre lo que hace la electrónica que uno compra, se trata de conveniencia (pocas tecnologías han hecho tanto en contra de la conveniencia como el DRM, por ejemplo la incompatibilidad entre dispositivos), se trata de evitar que la cultura se pierda por la obsolescencia de ciertos formatos (http://www.economist.com/node/21553410), se trata de que la persona que paga por algo tenga un producto de calidad (las limitaciones que impone el DRM no afectan a los que usan copias no autorizadas)

Mas información acerca del DRM: www.defectivebydesign.org/ www.eff.org/issues/drm

[#31 nusuario]

oye #18, premio a la inocencia e ingenuidad 2013. todavia no te has dado cuenta que el DRM es una herramienta de una nueva "filosofia corporativa" que consiste en quitarte tus derechos y ordeñarte el resto de tu vida?

mira a tu alrededor, esto mismo ya lo hacen con las televisiones y los modulos CI+ que te impiden grabar lo que ves en la television (tranquilo que cuando digital+ lo implemente vas a tener el placer). o no te dejan saltarte la publicidad de los programas que grabas, o te dejan reproducirlo solo un par de dias. tu ya no controlas tus propios aparatos, estos les consultan a ellos si te dejan hacer lo que tu quieres o no. y no son teorias, ya esta ocurriendo, y ahora quieren hacer lo mismo con la web. y son los mismos que no te dejan ejercer tus derechos poniendo medidas anti-copia a las peliculas y CD's a pesar de pagarles una tasa de compensacion. es una historia continuada de abusos y tu defiendes sus herramientas

y ahora que mencionas los "alquileres", muchos no ven que el negocio ya no es conseguir una venta, es que contrates servicios. el movil te lo dan, pero tu pagas todos los meses. la impresora tambien porque vas a necesitar siempre tinta. y despues vinieron las capsulas de cafe. hasta microsoft se ha dado cuenta y quiere sacar tajada ofreciendo la nueva version de office como suscripcion anual en vez de compra (que si dejas de pagar ya puedes darte por jodido). porque no quieren tener que convencerte una y otra vez de que les des dinero, quieren ordeñarte de forma continuada y tenerte agarrado por los huevos para que no dejes de pagarles. y por eso el DRM es cojonudo. para ellos

[#43 elhumero]

#31 Palladium. Año 2003 ya se avisaba. Y nos siguen llamando paranoicos.

[#15 Desactivado]

Es hora de empezar a abandonar los servicios de Google, lo de dont be evil empieza a ser un lejano recuerdo

[#14 oxelo]

Google tu antes molabas, de los demás no me sorprende.

[#12 monty_oso]

Este tema es complejo y hay muchas cosas que considerar.

Leer la conversación que se dio en : http://lists.w3.org/Archives/Public/public-html-admin/2013Jan/thread.html#msg102 es una buena forma de informarse.

[#35 morzilla]

Ahora que parecía que "el futuro de la Web está aquí y es open source" intentan meternos un "estándar" para introducir plugins no estándar, no interoperables y de código cerrado. Es obvio, pero incluso el promotor de este DRM en Netflix reconoce que esta funcionalidad no puede ser implementada en open source al 100% y que los navegadores open source tendrían que delegar en plugins cerrados o en el firmware de ciertos dispositivos de hardware: http://lists.w3.org/Archives/Public/public-html/2012Feb/0280.html

Terrible.

[#36 morzilla]

#16 Restringe de forma extrema el sistema operativo, el navegador e incluso el hardware desde donde puedes acceder a dicho contenido (GOTO #35). Es un giro de 180º, en dirección totalmente opuesta a la filosofía de estandarización e interoperabilidad de HTML5.

[#45 Krun]

Vamos a ver, estoy tan en contra del DRM como casi todos vosotros, pero creo que con esto se estan sacando las cosas de quicio.

Lo de "poner DRM al HTML5" es un poco sensacionalista. No se trata de ponerle DRM al HTML5, sino de que HTML5 sea compatible con tecnologías DRM que luego cada proveedor de contenidos ya decidirá libremente utilizar o no. El objetivo de esto es que los proveedores que quieran utilizar DRM no tengan que utilizar plugins como flash u otros propios, y que el usuario pueda acceder a esos contenidos sin necesidad de instalar nada más (que siempre es peor en términos de rendimiento y con posibles problemas de seguridad)

El resultado en la web va a ser exactamente el mismo. Las empresas que quieran utilizar DRM, van a utilizar DRM tanto si esto prospera como si no. Ahora mismo lo hacen utilizando flash, y si esto se acaba llevando a cabo, lo seguirán haciendo sin utilizar flash. Seguiremos comiendonos la mierda infecta del DRM pero al menos nos libramos de esa mierda infecta que es flash de una vez por todas.

Resultado para el proveedor: Todo igual sólo que ahora no tiene que utilizar otro plugin
Resultado para el usuario: Todo igual sólo que ahora no tiene que utilizar otro plugin

La propuesta dice: "This proposal extends HTMLMediaElement providing APIs to control playback of protected content. The API supports use cases ranging from simple clear key decryption to high value video (given an appropriate user agent implementation). License/key exchange is controlled by the application, facilitating the development of robust playback applications supporting a range of content decryption and protection technologies."

Lo cual evidentemente posibilita una implementación más directa de DRM sin recurrir a otros plugins.

¿Google ha dejado de ser guay? Para mi los que realmente tienen la culpa del DRM abusivo son los proveedores que utilizan DRM abusivo. Dificultar a estas empresas el uso del DRM mediante la necesidad de utilizar plugins no les va a hacer cambiar de opinión al respecto ni es una buena acción para los usuarios. Podemos irnos al otro extremo y pedir que los navegadores no sean compatibles con estas tecnologías, y lo que pasaría sería que los proveedores harían aplicaciones propias para soportar el DRM en lugar de poder acceder por web.

Al final, aún comiendonos todo el DRM, nos beneficiamos si la compatibilidad se hace de acuerdo a todos los estandares posibles y teniendo que instalar las menos aplicaciones posibles. Esta parte para mi tiene todo el sentido del mundo, aunque el DRM en si no.

[#46 Krun]

#45 También quiero añadir que no todo el DRM es el demonio. Una cosa es que te compres un blu-ray y no lo puedas ver en el reproductor que a ti te de la gana porque necesitas claves, y otra es que si alquilas una película por internet te controlen que solo la veas el tiempo por el que has pagado.

Lo primero debería ser ilegal, y lo segundo creo que puede posibilitar modelos de negocio que serían incluso beneficiosos para nosotros.

[#51 pawer13]

#45 #46 y ahora pensad cómo puede el software libre ser compatible con DRM en HTML5...esas páginas no se podrían ver desde firefox o chromium porque cualquiera podría coger el código fuente, crear una versión sin DRM y listo. El DRM es malo en un estándar sí o sí. Si quieren DRM, que sigan usando flash

[#52 Krun]

#51 Pero es que no se trata de ponerle DRM a una web, sino que los elementos multimedia incrustables (musica, video) tengan capacidad de ir cifrados posibilitando el DRM. Por eso todo esto apesta a sensacionalismo, porque en ningún momento se va a poner DRM al HTML.

[#53 pawer13]

#52 ¿El navegador reproducirá el vídeo? Entonces sigues diciendo lo mismo que yo he dicho, es el navegador el que tiene que limitar las acciones del usuario. Ahora mismo puedo pinchar sobre un vídeo y darle a "grabar como".

[#54 Krun]

#53 hasta donde se, funciona cifrando el video y recibiendo las claves solo si el usuario tiene permiso para acceder al contenido. Se puede hacer una implementación de código abierto perfectamente.

https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media-fpwd.html

[#55 pawer13]

#54 Claro que se puede; es más, un algoritmo de cifrado para que sea seguro debe ser público. Ser capaz de cifrar y descifrar información es una funcionalidad útil. Pero cualquier desarrollador pillará esa implementación libre y añadirá la funcionalidad extra de "Grabar como" (que grabará el vídeo ya descrifrado y así podré ver la película cuando me de la gana). El DRM sirve para limitar funcionalidades, y el código libre sirve para que cualquiera pueda añadir funcionalidades. Sigo opinando que Firefox o Chromium no implementarán esas limitaciones.

[#1 monty_oso]

Mas información acerca del DRM: https://www.eff.org/issues/drm

[#25 Desactivado]

Cómo era la noticia de Stallman de hace unas horas...? Ah si, que Google molaba y Facebook era el diablo.. Pos va a ser que aquí todos se mueven por intereses...

[#26 Desactivado]

#25 Sin sacar sus palabras de contexto, decía que Google no era tan mezquina como Facebook. Se limitan a guardar apariencias e ir de rollo molón new age.

[#40 snd]

Me cago en dios... que empleados tiene Google. Me quito el sombrero ante ellos.

[#30 fuynfactory]

ya hablan de DRM me paso al XHTML 2.0...

[#13 monty_oso]

http://lists.w3.org/Archives/Public/public-html-admin/2013Jan/0173.html

From: Tab Atkins Jr.
Date: Fri, 25 Jan 2013 15:06:21 -0800
Message-ID:
To: Glenn Adams
Cc: David Singer , "[e-mail]"

On Fri, Jan 25, 2013 at 2:31 PM, Glenn Adams wrote:
> On Fri, Jan 25, 2013 at 3:16 PM, Tab Atkins Jr.
> wrote:
>> It is very likely, given the explicitly admitted low
>> chance of interoperable DRM standards, that there will be extended
>> incompatibilities between browsers on non-free OSes as well for a long
>> time.
>
> Perhaps, but that is not relevant.

I fail to see how it is irrelevant.


> On the other hand, EME provides
> mechanisms that improve interoperability that can eventually reduce use of
> non-interoperable DRM components. You appear to oppose EME because it
> doesn't remove all such interoperability issues at one blow.

The existing most common DRM mechanism on the web (Flash) is already
at least as interoperable as any DRM module hooked up through the EME
spec mechanisms will ever be. Furthermore, it works today.

Let's take all the media distributors in this thread at their word for
a moment. Let's pretend that they have nothing but the average
person's best interests at heart, and it really is true that those
nasty ol' pirates will happily bankrupt them if they ever ship video
unencrypted. Can someone please explain how the stuff in the EME spec
is better than the existing DRM solutions on the web? More
importantly, if we assume that there is some technical benefit, can
someone please attempt to justify how that benefit is sufficiently
large to outweigh the technical cost to implementors of permanently
adding this new code to the web platform, and to authors and users who
will have to bear through an extended period of bad interop, assuming
we ever do achieve interop and don't just settle into a no-one-wins
stalemate like we have with audio/video codecs?

We have rejected awesome ideas that have literally zero downsides
for authors and users before, solely because we don't think they are
sufficiently good to justify burdening the future with the
additional code weight. This is clearly not in that category - it
is unarguably a mixed bag, and so the good must be correspondingly
greater. So far, the actual justifications for the technology have
been *nowhere near* sufficient to make this argument, as far as I can
tell. Everyone recognizes that DRM doesn't actually work, and no
matter what you do, the media will be available DRM-free on
filesharing networks soon after release (or quite often, before
official release). This is *at most* a picket fence that some people
honor out of a sense out of respect.

We've done this sort of thing before - one of the justifications for
the WOFF1 format was that it wasn't TrueType, so if people downloaded
it from a website they couldn't put it straight into their fonts
folder and expect it to work. However, *that was not the sole
benefit*. WOFF1 also compressed better than TTF, and font size is an
important issue, so that was a valuable benefit.

So far as I can tell, there is no such valuable benefit here. There's
only a threat - the threat that, if one browser defects and implements
the EME stuff, a bunch of media distributors will choose to only ship
videos with that DRM module, so no other browser will be able to play
them and they'll lose market share. This isn't a benefit to anyone
except potentially the media distributors.

So, why are we even arguing about this again?

~TJ

[#49 monty_oso]

Mas información acerca del DRM: http://www.defectivebydesign.org/

[#39 Desactivado]

ah, pero google no era chupiguay?

[#28 Zeioth]

Con las alternativas que existen hoy en dia lo va a usar quien yo me se si lo llegan a implantar.

[#20 Desactivado]

Claro que DRM agregará complejidad a los navegadores... Con ese mismo argumento, quitemos HTML, CSS, Javascript y que los navegadores solo visualicen texto plano... Ya verás tú qué poca complejidad!

[#22 Desactivado]

#16 #18 #20 Técnicamente es una gran gilipollez. Si lo puedes ver, lo puedes grabar y otras personas lo pueden ver sin DRM. El hecho de que intenten ponértelo más difícil agregando una nueva "feature" a ciertos navegadores no puede impedirlo, solo hacerlo un poco más engorroso a los "bueno videntes".

[#23 Desactivado]

#20 le quitas eso y le instalas esto: http://gopher.floodgap.com/overbite/ y te queda el navegador nuevo para navegar por gopher.

[#34 Patrañator]

Sí aquí los políticos se atrevieron a "ponerle DRM" a nuestra Constitución Española en la última reforma que hicieron, sin perjuicio para ellos, no veo porque no se va a intentar hacer con todo lo demás.
Con la nueva redacción de la Constitución, más le vale al ciudadano disponer de dinero, si quiere ver reales y efectivos sus D€RECHO$

[#29 diku4n]

que le pongan DRM a la biblia

[#16 Desactivado]

Aquí no se está hablando de copias de seguridad de material multimedia en soporte físico, que es donde el DRM recorta libertades, aquí se está hablando de proteger material accesible mediante streaming.

Es un material del que solamente adquieres los derechos de reproducción durante un periodo de tiempo determinado, no como con la compra de soportes físicos que adquieres los derechos a perpetuidad.

No mezclemos el derecho de copia de seguridad con la protección de contenido multimedia. Yo no veo ningún problema con que se protejan los alquileres streaming con DRM, estas pagando por una reproducción o un número de reproducciones durante 24 horas, no estas adquiriendo la propiedad como cuando se compraban cintas o DVDs. Si quieres comprar el derecho de una reproducción y luego piratear el contenido eso es un delito.

El DRM es este caso no es restrictivo.

[#17 Desmond]

#16 Jajajaja, claro hombre, si lo propone Google, entonces el DRM es bueno.

Si Google cagara, seguro que su mierda olía a rosas y sabía a mermelada de fresas. Como sois los fanboys.

[#18 Desactivado]

#17 Que yo sepa tanto Netflix, Hulu, Microsoft, Apple y Amazon tienen negocios de alquiler de streamning mucho más potentes que el de Google. En ningún momento me he referido a google y cuando hablo de alquileres por streaming no es precisamente el primero que me viene a la cabeza, pues está a años luz de los lideres.

Estoy hablando de la diferencia entre el DRM en discos físicos que has comprado y de los que tienes el derecho de copia privada y el DRM en alquileres, que solo tienes el derecho a visualizarlo y nada más, por lo cual el DRM no priva tus derechos en ese caso.

[#21 Toranks]

#18 El soporte físico estorba, es mucho mejor tener online algo para cuando quieras verlo, pero eso no significa que tengamos que pagar cada vez que queramos ver algo.
Pero qué coño digo, si yo hace años que hago boicot completo y absoluto a la industria audiovisual/videojueguil...
Puertas al campo, lo dicho...

[#19 odolgose]

#17 La verdad que tú llames fanboy a nadie suena a broma. A mala broma sin ninguna gracia.