manu.sporny.org/2013/drm-in-html5/ por
monty_oso el 29-01-2013 23:08 UTC publicado: 30-01-2013 22:40 UTC
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:
www.reddit.com/r/linux/comments/17h3d0/dont_let_microsoft_and_netflix_ etiquetas: drm, wc3, internet, estándar negativos:
1 usuarios:
172 anónimos:
181
Para el que quiera leer algo en castellano: plus.google.com/+LinuxMagazineEdici%C3%B3nenCastellano/posts/YdibQrUZa
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.
edit: 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 <ian@hixie.ch>
Date: Tue, 21 Feb 2012 23:46:46 +0000 (UTC)
To: Adrian Bateman <adrianba@microsoft.com>
cc: Maciej Stachowiak <mjs@apple.com>, "HTML WG (public-html@w3.org)" <public-html@w3.org>, David Dorwin <ddorwin@google.com>, Mark Watson <watsonm@netflix.com>
Message-ID: <Pine.LNX.4.64.1202212343470.11354@ps20323.dreamhostps.com>
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:
> dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media
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 <audio> and <video> 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
ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Las negrillas son mías.
películalicencia 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.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:
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:
> dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media
> 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: (425) 705-9596 Fax: (425) 936-7329
----
It got 10 first level replies.
Publicly Support (domain of e-mail address):
* [microsoft.com](lists.w3.org/Archives/Public/public-html-admin/2013Jan/0102.html) (same link as above)
* [cablelabs.com](lists.w3.org/Archives/Public/public-html-admin/2013Jan/0104.html) [(website)](cablelabs.com/)
* [foliot.ca](lists.w3.org/Archives/Public/public-html-admin/2013Jan/0121.html)
* [ocallahan.org](lists.w3.org/Archives/Public/public-html-admin/2013Jan/0130.html) (supports concept, has issues with impl)
* [irdeto.com](lists.w3.org/Archives/Public/public-html-admin/2013Jan/0134.html) [(website)](irdeto.com/)
* [verimatrix.com](lists.w3.org/Archives/Public/public-html-admin/2013Jan/0135.html) [(website)](verimatrix.com/)
* [nokia.com](lists.w3.org/Archives/Public/public-html-admin/2013Jan/0192.html) [(website)](www.nokia.com/us-en/)
Publicly Oppose:
* [ping.de](lists.w3.org/Archives/Public/public-html-admin/2013Jan/0103.html) [(website)](ping.de/index_eng.html)
* [gmail.com](lists.w3.org/Archives/Public/public-html-admin/2013Jan/0108.html)
* [geekhood.net](lists.w3.org/Archives/Public/public-html-admin/2013Jan/0110.html)
* [hixie.ch](lists.w3.org/Archives/Public/public-html-admin/2013Jan/0149.html) [(website)](hixie.ch/)
The
» ver todo el comentario
From: イアンフェッティ <ifette@google.com>
Date: Tue, 29 Jan 2013 15:30:54 -0800
Message-ID: <CAF4kx8cc8dL=3xnV95N9io24OuvobDG1X4Kezbr3Vmfhcb+OOA@mail.gmail.com>
To: Glenn Adams <glenn@skynav.com>
Cc: "Robert O'Callahan" <robert@ocallahan.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, Paul Cotton <Paul.Cotton@microsoft.com>, "public-html-admin@w3.org" <public-html-admin@w3.org>, "David Dorwin <ddorwin@google.com> (ddorwin@google.com)" <ddorwin@google.com>, Adrian Bateman <adrianba@microsoft.com>, Mark Watson <watsonm@netflix.com>
On Tue, Jan 29, 2013 at 2:50 PM, Glenn Adams <glenn@skynav.com> wrote:
>
> On Tue, Jan 29, 2013 at 3:37 PM, Ian Fette (イアンフェッティ) <ifette@google.com>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.
Leer la conversación que se dio en : lists.w3.org/Archives/Public/public-html-admin/2013Jan/thread.html#msg es una buena forma de informarse.
From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 25 Jan 2013 15:06:21 -0800
Message-ID: <CAAWBYDDMYE3BXXSsA8NOWZe9B5BYt0Lr4o5sCwNoPGnj+=syCw@mail.gmail.com>
To: Glenn Adams <glenn@skynav.com>
Cc: David Singer <singer@apple.com>, "public-html-admin@w3.org" <public-html-admin@w3.org>
On Fri, Jan 25, 2013 at 2:31 PM, Glenn Adams <glenn@skynav.com> wrote:
> On Fri, Jan 25, 2013 at 3:16 PM, Tab Atkins Jr. <jackalmage@gmail.com>
> 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<
» ver todo el comentario
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.
Si Google cagara, seguro que su mierda olía a rosas y sabía a mermelada de fresas. Como sois los fanboys.
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.
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...
#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.
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
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.
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$
Terrible.
No te culpo, estos gilipollas de la industria han creado gente como tú, que asocia descargar e internet con torrent y megaupload.
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.
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
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.
Lo primero debería ser ilegal, y lo segundo creo que puede posibilitar modelos de negocio que serían incluso beneficiosos para nosotros.
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.
"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.
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 (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
dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media