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

Quarta Maio 15 14:19:24 UTC 2013

O "problema técnico proposto" quando "solucionado", gera um problema
social. Portanto, sou favorável a não tentar prover uma "solução" para
o tal "problema". E o primeiro passo para tal é parar de encarar essas
demandas da indústria como um "problema técnico a ser resolvido".

Se a indústria está tendo dificuldades para por em prática o DRM, essa
é uma ótima notícia!

Agora... uma coisa me preocupou bastante na sua intervenção, Yaso...
"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."

Esclareça pra mim se estou errado, mas me deu a impressão de que você
quiz dizer nessa frase que como as empresas fazem parte do W3C, então
o W3C faz o que as empresas querem. Isso é preocupante. Como fazemos
para a sociedade também ter peso nas decisões do W3C?

Felipe

2013/5/15 Yasodara Cordova <yasodara.cordova em gmail.com>:
> 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. 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
>>>
>>>
>>>
>>>
>>> --
>>>
>>> ∞ yaso.eu
>>> ∞ 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
>>
>
> _______________________________________________
> 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
>