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

Yasodara Cordova yasodara.cordova em gmail.com
Quarta Maio 15 11:46:37 UTC 2013 

Opa, Leandro

Como falei e o Felipe e o Thiago falaram: o DRM nao é uma invenção do w3c.
É uma invenção da indústria cultural.  A Netflix e outras tentam achar uma
solução bpra entregar conteúdos com drm usando padrões livres.

Nao vejo uma solução política pra isto... As empresas precisam entregar o
conteúdo da indústria cultural.  As empresas fazem parte do w3c e querem
usar o html5 pra fazer isso. Que fazer? Imho, propor um caminho fora do
html5,  tecnicamente,  via outra solucao, pra manterbo html5 maculado.
Outra proposta? Sugerir ao google e outras um boicote aberto ao drm (o que
nao resolveria o problema técnico proposto)

Levando em conta que a indústria incipiente do video on demand pela web
precisa continuar crescendo e entregando conteúdo para o consumidor,  que
na maioria das vezes nao ta nem ai pro drm, eu entendo a proposta do EME. E
tambem entendo que ela cerceia a liberdade dos fabricantes de browsers (que
vao ter que implementar) e do consumidor consciente.  Mas, como atingir os
goals que eu falei ai em cima sem isso? É nessa solução que alguém tem que
chegar....
Em 15/05/2013 02:21, "Leandro Salvador" <leandrosalvador em gmail.com>
escreveu:

> Olá Yaso e Pessoal!
>
> Yaso, apenas para dialogar bem brevemente com uma ponderação que você
> compartilhou conosco.
>
> Quando você diz que "seria necessário pensar em uma outra maneira de
> atingir esses objetivos", talvez o DRM seja uma excelente solução técnica
> para atingirmos esses objetivos. O que me parece ser o grande problema, de
> fato, não é a solução técnica, mas sim a escolha política que a precede. No
> caso, esses objetivos parecem ser o próprio problema.
>
> Bem un passant, isso lembrou-me a questão da TV Digital Brasileira. Os
> grupos econômicos interessados em limitar o espectro de frequências e
> manter o statu quo tiveram a habilidade de fazer o debate girar em torno do
> padrão digital (se japonês, europeu, estadunidense ou brasileiro), e
> sublimaram o debate político: se o Brasil seria "Full HD" ou multicanal.
> Gênios! Ganhou o "Full HD", como todos sabem, patrocinado pelo Ministro da
> Rede Globo no governo Lula, Hélio Costa.
>
> Talvez na W3C o debate já esteja partindo de pressupostos e de objetivos
> muito problemáticos, como se realmente precisassem ser atingidos.
>
> My 2 cents...
> Abraços!
>
> (Enviado via Linux Android.)
> Em 12/05/2013 15:43, "Yasodara Cordova" <yasodara.cordova em gmail.com>
> escreveu:
>
>> 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**
>>
>> _______________________________________________
>> 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
>>
>>
> _______________________________________________
> 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/20130515/26676bc0/attachment-0003.html>

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