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

Yasodara Cordova yasodara.cordova em gmail.com
Domingo Maio 12 18:15:10 UTC 2013


Thiago, Dw1ìego,

quando eu falo "argumento técnico" estou querendo dizer o seguinte: a
netflix e outras companias usam o silverlight ou flash pra entregar
conteúdo protegido por DRM. Ambas as tecnologias agonizam e estas empresas
agora decidiram fazer um framework que vai permitir que se use HTML5 pra
entregar conteúdo protegido por DRM sem uso de plugins.

Então, as empresas querem usar o HTML5 pra tornar seus produtos entregáveis
sem os plugins, decidiram fazer um conjunto de APIS pra permitir que se
faça isso (EME). É uma decisão técnica que visa resolver um problema
técnico.

Lá na proposta estão definidos os "goals" que se conseguem com o EME [1].
Longe de mim incentivar o uso do DRM, também acredito em um mundo livre,
mas pra que essa proposta não pareça a melhor (pra indústria e pro usuário
que não se importa com DRM), seria necessário pensar em uma outra maneira
de atingir esses objetivos que se atingem com o EME.

[1]This proposal was designed with the following goals in mind:

   - Support simple decryption without the need for DRM servers, etc.
   - Support a wide range of media containers and codecs.
   - Support a range of content security models, including software and
   hardware-based models
   - Stream reusability - the actual encrypted content stream/file for a
   given container/codec should be identical regardless of the user agent and
   content decryption and protection mechanism.
   - Support a wide range of use cases.
   - Flexibility (and control) for applications and content providers
   without requiring client/user agent updates.
   - Minimize additions to HTMLMediaElement and new capabilities added to
   the user agent.
      - Defer all information and algorithms about the content decryption
      and protection solution to the application/server and client content
      decryption
module<https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#cdm>.
      The user agent should just pass information.
      - The user agent should not be responsible for communication with
      license servers.
      - The user agent should not select among content decryption and
      protection options. The application should make this decision.
      - Note: Applications are already capable of everything required
      except secure decryption and decode.
   - Compatible with adaptive streaming.
   - Usability.



2013/5/11 Thiago Rondon <thiago.rondon em gmail.com>

>
>
> 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
>



-- 

∞ <http://yaso.eu>yaso.eu
∞ w3c.br <http://w3c.br>
∞ ingraxa.eu
∞ yaso.in



**feelings are wireless**
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.okfn.org/pipermail/okfn-br/attachments/20130512/04a39a67/attachment-0003.html>


Mais detalhes sobre a lista de discussão okfn-br