Portada
mis comunidades
otras secciones
#1:
... y así es como un gran standard se convierte en una mierda.
#7:
Y me pregunto ¿Cuál es el problema? Las distribuidoras dadas a usar DRM lo seguirán haciendo, y además, esto puede abrir un nuevo horizonte donde el contenido que obtienes comprado puede verse en cualquier lugar, siendo un estandar, te quitas lo que hace más jodido a los DRM actuales, usar una herramienta del distribuidor para disfrutar del contenido.
A mi, no me parece mala idea, el DRM no es malo de por si, el problema ha sido como se ha implementado hasta ahora. Si el DRM me permite portar los contenidos a cualquier plataforma, pues adelante.
Recordad que este propuesta no es para joder el HTML5, sino para extender la funcionalidad que ya tiene.
A mi, no me parece mala idea, el DRM no es malo de por si, el problema ha sido como se ha implementado hasta ahora. Si el DRM me permite portar los contenidos a cualquier plataforma, pues adelante.
Recordad que este propuesta no es para joder el HTML5, sino para extender la funcionalidad que ya tiene.
#3:
Don´t be evil...
...que ya lo seré yo por ti.
...que ya lo seré yo por ti.
#34:
ALT1040? Permitidme que deje madurar el asunto unos días.
Edito - Primer párrafo del borrador:
No "DRM" is added to the HTML5 specification, and only simple clear key decryption is required as a common baseline.
Lo dicho.
Edito - Primer párrafo del borrador:
No "DRM" is added to the HTML5 specification, and only simple clear key decryption is required as a common baseline.
Lo dicho.
#61:
Añado para #7 y #26 por si no les ha quedado claro de #14 y #15 lo que dice el documento:
http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html
8.5. Content and Key Protection
Can I ensure the content key is protected without working with a content protection provider?
No. Protecting the content key would require that the browser's media stack have some secret that cannot easily be obtained. This is the type of thing DRM solutions provide. Establishing a standard mechanism to support this is beyond the scope of HTML5 standards and should be deferred to specific user agent solutions. In addition, it is not something that fully open source browsers could natively support.
http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html
8.5. Content and Key Protection
Can I ensure the content key is protected without working with a content protection provider?
No. Protecting the content key would require that the browser's media stack have some secret that cannot easily be obtained. This is the type of thing DRM solutions provide. Establishing a standard mechanism to support this is beyond the scope of HTML5 standards and should be deferred to specific user agent solutions. In addition, it is not something that fully open source browsers could natively support.
#31:
Resumamos lo que pasa hoy en día.
Te compras un libro en pdf con DRM de Adobe. Bien, olvídate de visualizarlo en tú navegador preferido. Olvídate también de verlo en el Acrobat. Has de bajarte el Adobe Ebook Reader, que en muchos sistemas operativos no va y muchos lectores de libros no lo soportan.
Pagas por ciertos cursos cuyos videos tienen DRM. Te obligan a verlos en uno de los softwares compatibles, normalmente Windows Media (adiós tablets, linux, macs), Quicktime (la de basura que instala es increible y tampoco va en todos los sistemas ni máquinas) o Real Video (con su bonito rootkit de regalo)
Y así con cientos de contenidos algunos de los cuáles directamente instalan cosas sin que nos enteremos.
Bien, eso ya está pasando y son lentejas, las tomas o las dejas.
¿Cuál es la mejora que aporta un estándar de DRM? Pues son obvias, pero ver #23 por si hay algún despistado
El único problema que plantea un estándar de DRM lo es realmente para los propietarios de contenidos que quieran utilizarlo: habiendo uno solo van a tener a miles de programadores en todo el mundo centrados en romperlo/trucarlo, y no creo que resistiese mucho tiempo.
Te compras un libro en pdf con DRM de Adobe. Bien, olvídate de visualizarlo en tú navegador preferido. Olvídate también de verlo en el Acrobat. Has de bajarte el Adobe Ebook Reader, que en muchos sistemas operativos no va y muchos lectores de libros no lo soportan.
Pagas por ciertos cursos cuyos videos tienen DRM. Te obligan a verlos en uno de los softwares compatibles, normalmente Windows Media (adiós tablets, linux, macs), Quicktime (la de basura que instala es increible y tampoco va en todos los sistemas ni máquinas) o Real Video (con su bonito rootkit de regalo)
Y así con cientos de contenidos algunos de los cuáles directamente instalan cosas sin que nos enteremos.
Bien, eso ya está pasando y son lentejas, las tomas o las dejas.
¿Cuál es la mejora que aporta un estándar de DRM? Pues son obvias, pero ver #23 por si hay algún despistado
El único problema que plantea un estándar de DRM lo es realmente para los propietarios de contenidos que quieran utilizarlo: habiendo uno solo van a tener a miles de programadores en todo el mundo centrados en romperlo/trucarlo, y no creo que resistiese mucho tiempo.
#6:
¿Y entonces para qué demonios queremos HTML5? Tantos esfuerzos en sacar un nuevo estándar, universalizar, liberar, hacer público, independizarse (no sólo de Adobe y su Flash) y les falta tiempo para patentarlo encima. Anda y que se compren una cabra y se la lleven a la playa.
#23:
#19 Es junk cuándo tienes que instalar algo para poder disfrutar de lo que has pagado, muchas veces sin enterarte de que te instalan y como va afectar eso a tu máquina. Es junk cuando te compras algo con DRM y no puedes usarlo porque tu máquina o SO no lo soportan. Es junk que termines con 200 sistemas DRM instalados que pueden interferir en ciertas tareas o volverte el SO inestable. Es junk que muchos vengan con rootkits y/o que llamen a casa. Un estándar abierto evitaría todos esos problemas.
Comentarios
... y así es como un gran standard se convierte en una mierda.
#1 Y la integridad y la imagen de una compañia como Google. Con esto y lo que viene a principios del mes que viene, se acabó eso de don't be evil.
#1 No creas, que un standard incorpore la posibilidad de un sistema de cifrado-pass para comunicación/autentificación de un sitio web es un avance (¿Quien no ha sufrido/sufre deficiencias en trámites con la "administración"?) , y si un estandar como HTML5 lo incorporara seria un paso (algo coñazo, you known), pero un paso más, es algo así como el certificado digital de mierda que te permite interactuar en tu administración electrónica, luego nos quejamos de vicio.
#8 xHTML2 no es HTML5, tu deja que se estandarice el HTML a los tiempos que corren, que el xHTML ya tendra su momento :_)
Don´t be evil...
...que ya lo seré yo por ti.
Y me pregunto ¿Cuál es el problema? Las distribuidoras dadas a usar DRM lo seguirán haciendo, y además, esto puede abrir un nuevo horizonte donde el contenido que obtienes comprado puede verse en cualquier lugar, siendo un estandar, te quitas lo que hace más jodido a los DRM actuales, usar una herramienta del distribuidor para disfrutar del contenido.
A mi, no me parece mala idea, el DRM no es malo de por si, el problema ha sido como se ha implementado hasta ahora. Si el DRM me permite portar los contenidos a cualquier plataforma, pues adelante.
Recordad que este propuesta no es para joder el HTML5, sino para extender la funcionalidad que ya tiene.
#7 El principal peligro que ya exisitía con H264 es que podría llegar a suceder lo que dice #14
#26 GOTO #15
Añado para #7 y #26 por si no les ha quedado claro de #14 y #15 lo que dice el documento:
http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html
8.5. Content and Key Protection
Can I ensure the content key is protected without working with a content protection provider?
No. Protecting the content key would require that the browser's media stack have some secret that cannot easily be obtained. This is the type of thing DRM solutions provide. Establishing a standard mechanism to support this is beyond the scope of HTML5 standards and should be deferred to specific user agent solutions. In addition, it is not something that fully open source browsers could natively support.
#61 Léete lo que tú mismo has puesto:
"Establishing a standard mechanism to support this is beyond the scope of HTML5 standards and should be deferred to specific user agent solutions. In addition, it is not something that fully open source browsers could natively support."
Traducido:
"Establecer un mecanismo estandar que soporte esto está más allá del objetivo de los estándares de HTML5 y debería ser llevado a cabo por una aplicación específica. Además, esto no es algo que pueda ser soportado nativamente por navegadores de código completamente abierto."
Las negritas despistan del mensaje que, según mi patético inglés, realmente quieren dar.
#64 Te dice que lo van a tener que implementar terceros privativos y que no puede ponerse de ningún modo usando software libre.
#65 No sé si soy yo, pero a mí me da a entender que todo lo que van a hacer se podrá implementar en un navegador de código abierto.
"Protecting the content key would require that the browser's media stack have some secret that cannot easily be obtained. This is the type of thing DRM solutions provide. Establishing a standard mechanism to support this is beyond the scope of HTML5 standards"
"Este tipo de cosas son las que las soluciones con DRM llevan. Establecer un mecanismo para esto está fuera del alcance de HTML5"
Si estoy equivocado y tienes una explicación para tontos, dámela por favor, porque sigo sin ver dónde dice que no se puede implementar en un navegador de software libre.
#66 Puede que sea yo el que lo entienda mal, te explico lo que yo entiendo, por si entre los dos sacamos algo en claro:
Dice que no puedes implementar su chuminada sin un tercero que meta un secreto en el código, por lo que no puede ser software libre, tiene que ser secreto y por lo tanto nadie puede ver el código fuente.
Dice que no se podrá soportar su chuminada en los estándares, de lo que entiendo que se dará una especificación genérica pendiente de ese secreto en la implementación.
Según leo yo, esto va a ser un poco como lo de llevar flash. Firefox te viene sin flash, en cambio chrome lleva una implementación privativa de flash. Imagino que habrá que tener a un "Adobe" implementando su "encrypted-media" para que los navegadores opensource puedan usarlo.
¿Te imaginas que en el estándar de HTML5 incluyan la obligación de tener flash pero sin que los navegadores libres lo puedan implementar? Pues me parece que es lo que nos están metiendo.
#67 No me lo he leído entero, pero sí gran parte. Según dice en el punto 6, el cifrado, digamos "básico" sí que podría hacerlo cualquier navegador libre y permitiría que el cifrado fuera independiente de la plataforma, al ir incorporado en el estandar.
Ahora lo que yo creo: viendo quién está en el asunto (Netflix y Google mayormente), me da a mí que lo que quieren es otra cosa. No quieren DRM, quieren cifrar las contraseñas, para así ahorrarse desarrollar programas para distintas plataformas: todo dependería del navegador. Netflix desde el navegador comprobaría tus credenciales usando el cifrado, ahorrándose los complementos externos. A Google le da la posibilidad de hacer lo mismo con Youtube, cifrarlo para hacer "usuarios premium", que no tengan publicidad, acceso a contenido exclusivo, etc.
Ya digo, es sólo una teoría mía, pero tiene la pinta de que es más o menos esto lo que quieren.
#69 Good point. No había leído 6
#7 #66 #67 #68 http://www.nacionred.com/neutralidad-de-la-red/google-y-microsoft-quieren-un-sistema-anticopia-en-cada-navegador-de-internet
No se puede implementar en un navegador Open Source: modificas el código, compilas tu navegador y hop!, sistema crackeado.
Este sistema es el que usaba Sony con PSN y mira cómo le fue: consideró que la PS3 era inviolable y basó la seguridad en esa premisa. La seguridad de qué contenidos puedes ver o no debe estar en el lado del servidor. En el lado del cliente no sirve para limitar a lo que puedes acceder, sirve para limitar cómo lo puedes usar (que no puedas ver el vídeo y quedarte una copia en el disco duro, o pasarlo a tu móvil/tablet para verlo más adelante, por tomar algunos ejemplos)
#74 Cualquier cosa que se vea en tu pantalla y se escuche en tu tarjeta de sonido es copiable. Es la historia de nunca acabar, ellos inventando métodos anti-copia y los crackers reventando sus algoritmos. Las ultimas victimas han sido BlueRay y HDMI.
#77 Si, y todo el mundo volviendo a bittorrent. Y?
De los llenos del cine, a la subida exponencial del P2P
De los llenos del cine, a la subida exponencial de...
borrowbits.com#78 Si ofrecen un servicio barato para ver peliculas en cualquier navegador, ya sea en el ordenador, la tele o el movil y es barato ¿Cual es el problema?
¿No decís que el problema es que no hay oferta?
No pretenderás que todo el mundo gaste su dinero para crear contenidos y luego tu lo consumas gratis.
El DRM no es obligatorio, lo usarán quienes quieran proteger sus contenidos, quien quiera darlo gratis como tambien ocurre ahora no usará ni DRM ni nada, pero hay que dar la opción de elegir.
#79 "Decís"? No se donde has visto que yo dijese nada acerca de mi postura personal acerca de las descargas, así que por favor, no me metas en ningún grupo. Mi argumento solo gira en torno a la inutilidad de esta carrera, nunca habrá un ganador. Lo que se ve y se escucha en tu equipo siempre sera susceptible de ser copiado y compartido, desde un punto de vista tecnológico.
Si quieres mi opinión, creo que si en vez de invertir en esos caros sistemas bajaran los precios de la música y el cine compensarían los menores ingresos con ese ahorro.
#61 Normal, el DRM se basa en que su código no es público, pero se puede implementar como plugin.
Como era previsible nadie a contestado a la pregunta de #7
La repito, ¿cuál es el problema? ¿Cuál la desventaja?
Recordad que este propuesta no es para joder el HTML5, sino para extender la funcionalidad que ya tiene.
#c-7" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/1539934/order/7">#7 ésa es una excusa parecida, por ejemplo, a la que empleaban en su día los chicos de Micro$oft, al iniciar con Visual J# su campaña de acoso y derribo al estándar Java...
#c-52" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/1539934/order/52">#52 ¿Honestamente piensas que esta noticia y el caso de Visual J# tienen algo que ver o alguna similitud?
Para #7. El problema es cualquier cosa que lleve DRM.
ALT1040? Permitidme que deje madurar el asunto unos días.
Edito - Primer párrafo del borrador:
No "DRM" is added to the HTML5 specification, and only simple clear key decryption is required as a common baseline.
Lo dicho.
Voto sensacionalista, porque creo que el titular induce a error.
¿Alguien puede hacer el favor de leerse la noticia? Lo único que haría esa implementación sería dar la posibilidad de usar tecnologías con DRM directamente en el navegador. No sería, en ningún caso, como dice #34, una implementación de DRM, sino que da la facilidad para aquellos que quieran usar algo con DRM, de manera que no tienen que tirar de complementos externos.
El estandar en cuanto al resto seguiría igual y tú podrías colgar video utilizando el tag de video sin problema alguno y sin DRM.
Soy anti-DRM y anti-patentes como el que más (no hay más que ver mis comentarios), pero de lo que dice la implementación a lo que dice el artículo...
Y, por si alguien lo dudaba, yo también estoy en contra de esto.
¿Y entonces para qué demonios queremos HTML5? Tantos esfuerzos en sacar un nuevo estándar, universalizar, liberar, hacer público, independizarse (no sólo de Adobe y su Flash) y les falta tiempo para patentarlo encima. Anda y que se compren una cabra y se la lleven a la playa.
#6 ¿Qué tiene que ver que algo sea un estándar con que permita DRM o no? AES es un estándar, libre, público y todo lo que te apetezca, pero eso no implica que lo que cifres con el tenga porque serlo, sino que alguien que quiera descifrarlo, conociendo la clave evidentemente, podrá hacerlo con cualquier implementación del mismo.
Que HTML5 incluya propiedades para el uso de DRM lo único que implicará es que si quieres ver algún contenido que lo lleve puedas escoger con que navegador que soporte el estándar hacerlo, no como Flash que usas Flash o te aguantas.
Vamos, hay estándares que hasta te cobran una pasta simplemente por leer el documento del mismo, y sino pásate por la web de la ISO.
#12 Leyendo a algunos parece que nos van a poner una pistola en el pecho para que consumamos contenidos con DRM o algo...
google empieza a enseñar las orejas de lobo
... y esto es lo que pasa cuando hasta google se agacha para que le de la RIAA por el cacas.
Supongo que nadie se ha parado a leer el documento, total el titular pone DRM + Google + Microsoft, es un éxito asegurado.
This proposal extends HTMLMediaElement to enable playback of protected content. The proposed 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. No "DRM" is added to the HTML5 specification, and only simple clear key decryption is required as a common baseline.
#43 Yo sí lo he leído y me sigue pareciendo una trampa para tontos.
Más suposiciones.
A tomar por culo el HTLM5. Una pena, no lo había mirado todavía, pero parecía que era un gran avance para unificar todas las funcionalidades necesarias para hacer una aplicación web.
Está bien que Google nos recuerde de vez en cuando que es una multinacional sin escrúpulos como todos las demás.
PD: Don't be evil....
Demasiado tarde para votar errónea.
No se por qué, pero cada vez que publican un artículo en ALT1040 parece que se va a desatar el apocalipsis.
#68 Se llama SENSACIONALISMO, y ALT1040 son expertos en eso. Al final, el sensacionalismo atrae muchas visitas.
#68 Pues yo he podido
Al final tanto hablar y no abandonaremos Flash jejeje.
Pues a mí me parece bien. Actualmente hay servicios que no se ofrecen, o que se ofrecen mediante la descarga de asquerosos plugins binarios (lo que prácticamente descarta que se puedan ofrecer para Linux). Y esto se debe a que no hay una tecnología estándar para comercializar tus productos/servicios electrónicos (como por ejemplo, videojuegos de pago para el navegador...)
Si se aplica y estandariza DRM, en el peor de los casos me quedaré tal y como estoy ahora: sin acceder a esos servicios por no estar dispuesto a pagar lo que me pidan. En el mejor de los casos, tendré acceso a esos nuevos servicios porque considero que me compensa pagar... Incluso cualquiera de nosotros podrá ofrecer sus pequeños servicios/software online y ganar unas perrillas.
Me he molestado en leer la especificación: http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html
Y aparece lo siguiente en el texto: 'No "DRM" is added to the HTML5 specification, and only simple clear key decryption is required as a common baseline.'
Vamos que el borrador lo que propone es un módulo de encriptación que se maneja mediante javascript. Y la encriptación que usarán, aunque todavía no se sabe, será algún algoritmo abierto y conocido, como los que se usan en SSL.
No se quién ha tergiversado la noticia, pero he votado errónea por razones evidentes. Tengo mis dudas en que el borrador se materialice en algo, porque esto mismo se puede hacer con https, aunque con menos control. O con el control que quieras implementando los algoritmos de encriptación en javascript, aunque sería muy lento.
DRM = JUNK!
#19 Es junk cuándo tienes que instalar algo para poder disfrutar de lo que has pagado, muchas veces sin enterarte de que te instalan y como va afectar eso a tu máquina. Es junk cuando te compras algo con DRM y no puedes usarlo porque tu máquina o SO no lo soportan. Es junk que termines con 200 sistemas DRM instalados que pueden interferir en ciertas tareas o volverte el SO inestable. Es junk que muchos vengan con rootkits y/o que llamen a casa. Un estándar abierto evitaría todos esos problemas.
Resumamos lo que pasa hoy en día.
Te compras un libro en pdf con DRM de Adobe. Bien, olvídate de visualizarlo en tú navegador preferido. Olvídate también de verlo en el Acrobat. Has de bajarte el Adobe Ebook Reader, que en muchos sistemas operativos no va y muchos lectores de libros no lo soportan.
Pagas por ciertos cursos cuyos videos tienen DRM. Te obligan a verlos en uno de los softwares compatibles, normalmente Windows Media (adiós tablets, linux, macs), Quicktime (la de basura que instala es increible y tampoco va en todos los sistemas ni máquinas) o Real Video (con su bonito rootkit de regalo)
Y así con cientos de contenidos algunos de los cuáles directamente instalan cosas sin que nos enteremos.
Bien, eso ya está pasando y son lentejas, las tomas o las dejas.
¿Cuál es la mejora que aporta un estándar de DRM? Pues son obvias, pero ver #23 por si hay algún despistado
El único problema que plantea un estándar de DRM lo es realmente para los propietarios de contenidos que quieran utilizarlo: habiendo uno solo van a tener a miles de programadores en todo el mundo centrados en romperlo/trucarlo, y no creo que resistiese mucho tiempo.
#31 tienes razón, aunque para eso existen revisiones de estandares, hoy en día y por aún muchos años AES/256 o AES/512 se consideran seguros, es muy probable que en un futuro no lo sean, pero para entonces ya existira un sistema de cifrado más robusto.
Joé, es salir una noticia en la que Google se posiciona a favor del DRM y empiezan a salir defensores de restringir la libertad de los usuarios como setas. Curioso fenómeno.
#27 Querido amigo, te paso una nota para que la tengas como referencia para saber sobre que empresas puedes hablar bien y mal.
@Json
Como verás, Google pertenece a la categoria "bueno" por lo tanto si Google quiere DRM, entonces el DRM tiene que ser necesariamente bueno.
Aún hay pocas empresas, pero espero poder ampliarla con la ayuda de todos.
Saludos
Pd. Antes Google era bueno++, pero estos últimos meses no he tenido mas remedio que rebajarle la calificacion
Google tú antes molabas...
Como dijo el comandante de la HVO Ivica Rajic después de volar el puente de Mostar: "Haremos uno nuevo más grande y más antiguo"
el sensacionalismo en meneame empieza a ser galopante
Bfff aunque a priori parezca poca cosa, es un troyano encasquetado. Tarde o temprano un servicio que consideres básico te exigirá el uso de esa tecnología (un banco, correo mas seguro, paypal,etc...) lo que boicot a sus implantaciones tienen la guerra perdida.
Entendiendo DRM como contenido cifrado que juega con claves publicas/privadas se puede aplicar a mil campos entiendo yo...
Que se pongan DRM en las pelotas y verán que risa cuando para que se las toque alguien ajeno tengan que pasar por caja
Sin un sistema DRM ¿ quien hará juegos si cualquiera puede "clonarlo" y cambiar por ejemplo la entradilla con otro patrocinador ? . La posibilidad de ofuscar el código no me parece mal .
#40 ¿Quién hará sistemas operativos si los publican con una licencia libre? Oh wait...
Últimamente no dejo de leer propaganda contra Google y comentarios jocosos sobre su lema "don't be evil".
El documento es una propuesta de tres trabajadores de Google, Microsoft y Netflix, no una apuesta de las tres compañías. Dice claramente que el DRM no se añadirá a la especificación sino que se trata de cifrado corriente y moliente.
Esto es como lo de las cookies: de repente saltan desde Apple y Microsoft a decir lo malos que son los de Google por saltarse sus preferencias de seguridad... Y resulta que es un mecanismo conocido durante años que implementan muchísimos otros productos.
Lo dicho, propaganda, guerra entre empresas, y Alt1040, sensacionalista donde las haya (al fin y al cabo no es más que un Engadget o un Gizmodo más) haciendo de altavoz.
DRM --> Defective by design.
DRM --> Defectuoso por diseño.
Vamos que prefiero una mie... lenta como es Flash, al HTML5 con DRM.
Salu2
El DRM es malo por muchos motivos, siendo el primero el limitar de forma artificial a abundancia del hecho de la copia de ficheros (tengan o no ciertos derechos asociados). Esta limitación artificial condena a los propios contenidos a su segura desaparición, creando una sensación falsa de propiedad cuando no existe.
Interesante leer esto: http://opensource.com/life/11/11/drm-graveyard-brief-history-digital-rights-management-music
Creo que los modelos de negocio basados en la falsa escasez de capacidad de copia son negativos y malos a la larga. Los negocios que den un valor añadido y que se aprovechen de la copia para captar negocio entorno a la parte de valor añadido difícilmente replicable, serán los que acaben triunfando. Entre medio se pierde mucho tiempo y mucho contenido para siempre.
Los bluray traen eso mismo
las pelis que veaia por streaming sacadas de blurays no tienen drm
asi que al fianl pasara lo de siempre
Esto me huele a intento de seguir coartando las libertades en internet mas que proteger derechos...
Bueno, de momento solo es una propuesta. En caso de salir, parece que Firefox al menos no lo implementaría.
#10 Con lo cual en firefox no se podrá utilizar Netflix, ni ninguno de los futuros servicios de videoclub existentes o que salgan en el futuro.
#14 Bueno, ese es su servicio y se lo f.... como quieren.. Si no estas de cuerdo con sus condiciones puedes no usarlo e intentar con alternativas sin DRM.
#76 No va a haber alternativas sin DRM, si una empresa gasta cientos de millones en comprar los derechos de obras digitales va a utilizar DRM para proteger su inversión.
Y en cuanto a los sitios piratas ya has visto que le pasó a megavideo.
Me lo he pensado mejor:
Cualquier "creación" se basa en la cultura que tenga el creador. Esa cultura la ha obtenido de su sociedad, ya sea su lengua o la lengua franca de turno, matemáticas, música, estilos musicales, ritmos, libros, comentarios que oye en la calle, la vida de otros que inspira una novela, ¡tanta cosas!... Y luego la "creación", que en realidad es una obra derivada de la cultura que conoce. ¿Cómo de grande es el mérito de la creación? Mucho menos grande de lo que pretenden algunos creadores. El esfuerzo intelectual existe, sí, horas y horas dándole vueltas a algo, no lo neguemos, es trabajoso, pero son horas y horas caminando sobre una base a la que uno solo ni soñaría alcanzar si se hubiera criado entre los animales de un bosque. Por eso no se puede pretender cobrar eternamente por una obra, ni eternamente ni cinco minutos (vale, más de cinco minutos sí ). Mientras que por otro lado el "público" no le ha cobrado nada al creador por usar el "dominio público". Entonces ¿quién es nadie para limitar el acceso a la cultura? El DRM coarta el acceso a la información y por ende a la cultura, por eso rechazo de plano el DRM, porque no se crea de la nada (esto daría lugar a un buen debate filosófico), los creadores le deben muchísimo a su sociedad y es reprochable no devolver habiendo cogido tanto.
Y como ejercicio para el lector (siempre quise escribir eso) unas preguntas para las que no tengo respuesta:
- ¿Cuánto debería recibir un creador por su obra?
- ¿Proporcional al tiempo empleado?
- ¿Depende de lo que aprecie la gente esa obra?
- ¿Que lo decidan las leyes de nuestro amado "libre mercado"?
- ¿Si nadie encuentra valor no debería recibir nada a cambio?
- ¿Y si un par de siglos tras su muerte se le encuentra una utilidad enorme?
- ¿Nada si la obra fue creada sin ánimo de lucro, por ejemplo si fuera el resultado de una afición?
Supongamos que se hace una obra por encargo y el que paga se quede con los derechos de autor:
- ¿Qué representan los derechos de autor?
- ¿Qué significa venderlos?
- ¿Pagar por una obra te da el mérito de haberla creado y todo lo que conlleva?
- ¿Qué derechos tiene o debería tener un autor sobre su obra?
- ¿Y sobre obras derivadas?
#38 ¿Tú también trabajas de gratis para pagar las deudas que has contraído con la sociedad? Que rule lo que te estás metiendo, que debe de ser buenísimo.
Quien quiera vender contenido con DRM lo va a hacer y si tiene poder para ello lo va a imponer.
En el caso de que no hay un sistema ampliamente usado y aceptado va a inventar e imponer el suyo con dios sabe que añadidos.
Cuando exista uno funcional, universal y abierto en HTML5 y aun asi no lo usan,sabremos que es porque tiene algo que esconder.
si la evolución natural de internet es XHTML 2.0 y no HTML 5
que locura estamos metiendo con el HTML 5
usar HTML5 es como usar un coche de gasolina en vez de uno impulsado de agua en fusión fría (si existiera)
el motor es nuevo que da mas potencia pero sabes que depende de la gasolina que estos le pondrá el precio que le salga de los co**nes
mientras que el de agua en fusión fría, es un motor súper complejo muy pesado pero el agua se puede recoger la la lluvia
#8 Creo que te has perdido el capítulo de la guerra de WHATWG vs. W3C.
SPOILER --> XHTML murió
#8 estás equivocado. Es más correcto hoy día usar html5 que xhtml, sobretodo si miras a futuro, no necesariamente muy lejano.
Todo radica en la semantica...
#8 Eso no tiene sentido. XHTML surgió por un afan de que HTML cumpliese estrictamente la especificación XML. No aporta ningún beneficio sustancial a las funcionalidades web en si, sino que únicamente es una forma mas "formal" de escribir un documento html.
Por lo demás no aporta funcionalidades nuevas, cosa que si hace HTML5
Yo lo veo más como un entretenimiento para los crackers... A ver lo que tardan en pasárselo por el forro.
La jodimos...
DRM jode a los que pagan por una obra y no impide que se pueda piratear. Bravo.
Una propuesta en borrador que, básicamente, implica la inclusión de mecanismos de
protecciónProhibición.Lo que proponen puede ser positivo para la evolución de la web, pero me temo que a la larga puede ser perjudicial para la libertad del usuario, si se extiende mucho y mal su uso.
Aquí está pasando exactamente lo mismo de lo que se quejan muchos. ¿Os acordáis de "el p2p es simplemente una herramienta y no puede criminalizarse"? Bien, pues esto es exactamente lo mismo.
Disfruten de la incoherencia atúnida.
Perdón, quise decir:
¡HIJOS DE PUTA! ¡QUERÉIS BLOQUEAR NUESTRO DERECHO A LA LIBERTAD! ¡VIVÍS ANCLADOS EN UN MUNDO PASADO!
Ahora sí, fixed.
...aha.
El problema que vería con un estándar es si para implementarlo te ves obligado a usar una patente: hay que pasar por caja. De otro modo el DRM solo se trataría de una funcionalidad que no queremos que exista, pero que si hacemos una web no estamos obligados a usar.
Gracias Google.
JAJAJAJAJAJAAJ NO SE ATREVERÁN
No sé a ti, pero la sociedad no ha intentado cobrarme por disfrutar de su cultura. En cambio muchas empresas y personas si quieren cobrar por algo que como ya he dicho no han inventado por completo (ni se acercan). Y no he dicho tampoco que no tengan derecho a cobrar, o que no merezcan recibir algo a cambio, he dicho que esa cuantía es mas pequeña de lo que pretenden, ni debe alargarse demasiado en el tiempo.
El DRM es ideal para aquellos que quieren recibir, sacar provecho y no dar.
¿DRM como un estándar en vez de cada uno tener el suyo con rookits de por medio? Me parece perfecto.
Google Inc.? Esa empresa privada a la que cientos de millones de personas le regalan toda la información sobre su vida entera porque es muy cómodo?
Y ahora empezáis a decir que se le empiezan a ver las orejas cuando antes me llamabais conspiranoico y hundíais a negativos... no es que me pase por primera vez pero siempre me deja un sabor agridulce.
Por cierto, todavía vais a verlas venir más, estad seguros