[okfn-br] Say NO to DRM in HTML5!

[Diego Rabatone]

E outra, DRM não é uma questão técnica, é uma questão econômica de modelo
de negócio. O HTML5 permitir a introdução de DRM é, como bem disse o
Rondon, algo fora do escopo do HTML.

Seria como, por exemplo, o HTML querer impor que o uso do "userMedia" (para
captura de áudio e vídeo) só pudesse rodar em "equipamentos certificados e
registrados" para "evitar o uso de equipamentos roubados" .... Não faz
parte do escopo desta tecnologia. Se eu paguei imposto ou não, se eu paguei
pelo produto ou não, se eu paguei pelo acesso ou não, são questões
relativas ao modelo de negócio, e não questões do protocolo TCP/IP, Wifi,
HTML, etc....


--------------------------------
Diego Rabatone Oliveira
diraol(arroba)diraol(ponto)eng(ponto)br
Identica: (@diraol) http://identi.ca/diraol
Twitter: @diraol


Em 11 de maio de 2013 17:25, Thiago Rondon <thiago.rondon em gmail.com>escreveu:

>
>
> On Saturday, May 11, 2013 at 12:28 PM, Yasodara Cordova wrote:
>
> > Hum. Fato. Meu problema é que ele já se posicionou.
> > Precisa de uma opinião técnica muito convincente pra fazer o cara mudar
> de idéia, ate porque os argumentos a favor do DRM no HTML5 sao muito bons.
> >
> > Mas, ele escuta a comunidade de desenvolvimento com atenção, vc tem
> razao. Vai que...
> >
>
> Qual argumento técnico é convincente ?
>
> DRM é baseado em um sistema de segurança obscuro, onde ninguém pode saber
> o que acontece. Tecnicamente é falho.
>
> O único argumento técnico que a DRM aborda no aspecto técnico de controle
> é com relação a assinaturas binárias para garantir quem é o provedor do
> conteúdo, mas esta demanda geralmente é mais presente em desenvolvimento de
> software do que em distribuição de conteúdo, que acredito que o foco é
> este, a linguagem de apresentação HTML.
>
> O Adobe Flash e o Microsoft Silverlight provaram que não conseguem se
> manter sozinhos, e não é toa que um esta sendo desmotivado o uso por
> desenvolvedores e outro será descontinuado. Razão pela qual o Netflix esta
> trabalhando nesta proposta.
>
> Isto me parece mais um movimento político de receio de perder terreno para
> algum tipo de padrão fechado que possa vir, e principalmente manter modelos
> de negócios existentes.
>
> A venda "casada" de conteúdo e tocador, é algo perigoso. Por que não temos
> soluções livres para tocadores de DVD depois de 20 anos de existência ?
> Pois, com esta mecânica é uma caixa preta, que só algumas empresas podem
> ter acesso teoricamente.
>
> Não acredito que o HTML 5 deveria interferir neste ninho... A inovação
> esta aí para isto.
>
> A Netflix que se vire para manter seu modelo de negócio sem a DRM, o que
> tecnicamente é bem possível. Ninguém nunca provou que o DRM é um sucesso
> contra cópias, não há casos reais. A única coisa que o DRM consegue é
> restringir o uso de seu dispositivo através do teu provedor de conteúdo.
>
> A industria da música não resistiu ao DRM, pois seus usuários ao comprar
> uma música e não poder tocar no teu carro não estavam gostando muito desta
> experiência.... Agora, imagine você comprar um filme no teu tablet, e não
> poder tocar na tua TV ? Que modelo de negócio é este ? Existem tantas
> alternativas técnicas para garantir quem é você, por que você precisa ter
> controle sobre o teu dispositivo ?
>
> A falha da DRM esta em acreditar que o inimigo é o proprietário da obra, e
> por isto ele acredita ter direitos sobre o device dele para realizar estes
> controles.
>
> Mesmo que a proposta seja sobre a extensão do HTMLMediaElement no HTML5,
> não acredito que é bacana incentivar este tipo de iniciativa dentro de um
> padrão aberto, pois isto claramente esta criando uma aproximação perigosa e
> sem sentido depois de anos de briga por padrões abertos.
>
> Minha opinião ? O tiro pode sair pela culatra.
>
> Abs!
> -Thiago Rondon
>
>
>
>
>
>
> _______________________________________________
> okfn-br mailing list
> okfn-br em lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/okfn-br
> Unsubscribe: http://lists.okfn.org/mailman/options/okfn-br
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.okfn.org/pipermail/okfn-br/attachments/20130511/9b963943/attachment-0003.html>