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

Quarta Maio 15 20:34:39 UTC 2013

Acredito que os principais pontos que justificam a oposição a essa proposta
já foram colocados na thread pelo Felipe Sanches e pelo Leandro Salvador. A
própria ideia de exigir a implementação de dispositivos que sejam capazes
de controlar o dispositivo do usuário contra a sua própria vontade é
contrária ao princípio da "Web para todos" [1] pelo qual se pauta o W3C.
Além disso, admitir a instalação de uma caixa-preta (o "CDM") na máquina do
usuário, que pode realizar coisas sobre as quais o usuário não pode ter
conhecimento nem controle, contraria a existência de um grupo de interesse
em privacidade [2] no W3C e, como o Fred Andrews colocou [3], põe em cheque
a credibilidade do W3C na área de defesa da privacidade.

O único argumento que li até agora a favor da proposta que tem alguma
consistência é aquele que diz que é melhor fazer isso e trazer essas
empresas de conteúdo para a web e para o HTML5 que não fazê-lo e estimular
a proliferação de plataformas paralelas de entrega de conteúdo via
aplicativos nativos [4][5]. Argumentam que, cedendo à proposta, esses
produtores de conteúdo seriam eventualmente estimulados experimentar e
disponibilizar conteúdos sem DRM na plataforma HTML5. A minha resposta para
isso é: se eles quiserem experimentar disponibilizar conteúdo sem DRM na
plaforma HTML5, podem fazê-lo já, sem a necessidade dessa proposta.

A verdadeira questão é o que seria menos ruim: ceder às pressões e tornar a
web uma plataforma fechada e sujeita ao controle total do produtor do
conteúdo, ou deixar aqueles que querem controle fazerem suas próprias
plataformas fechadas em separado, fora da web? A primeira trai os ideais de
uma web aberta e para todos. A segunda, por mais que seja fragmentadora, dá
a liberdade de escolha para cada um participar do tipo de plataforma que
desejar. Eventualmente, se essas empresas quiserem ter como clientes as
pessoas conscientes de sua própria privacidade e liberdade, passariam a
oferecer seus serviços na plataforma aberta (a web). Caso contrário,
vive-se sem eles.

Leandro, entendo que o que você procura é saber qual a maneira de
manifestar a nossa oposição à proposta, de dentro dos processos do W3C.
Vejo que uma forma que tem sido usada por algumas pessoas que já participam
é levantar as objeções como sendo "bugs" no texto da proposta [6][7].

Yaso, afinal a filiação deste Ministério ao W3C já foi concluída, ou não?
Apesar de a oposição à proposta de incluir DRM no HTML5 ser uma posição
discutida apenas com a nossa equipe, acredito que podemos convencer a
Secretária a fazer uma manifestação formal no processo, como membro do W3C,
se for o caso.

Abraço,
Augusto Herrmann

[1] http://www.w3.org/Consortium/mission.html#principles
[2] http://www.w3.org/Privacy/
[3] http://lists.w3.org/Archives/Public/public-privacy/2013JanMar/0036.html
[4]
http://arstechnica.com/business/2013/05/drm-in-html5-is-a-victory-for-the-open-web-not-a-defeat/
[5] http://lists.w3.org/Archives/Public/public-html-admin/2013Jan/0112.html
[6]
http://www.w3.org/community/pua/wiki/Digital_Rights_Management#Objections
[7] http://lists.w3.org/Archives/Public/public-privacy/2013JanMar/0037.html

2013/5/15 Yasodara Cordova <yasodara.cordova em gmail.com>

> Opa la!
>
> Em 15/05/2013 11:31, "Felipe Sanches" <juca em members.fsf.org> escreveu:
>
> >
> > O "problema técnico proposto" quando "solucionado", gera um problema
> > social.
>
> Ops aqui. Quem considera isso é você,  lembre-se :) eu tambem acho e
> concordo contigo, mas estou lembrando que nem todos sao ativistas pela
> liberdade
>
> 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.
>
> Impressao errada. O w3c é uma comunidade, existe um processo decisório bem
> baseado em meritocracia e outros requisitos. E é aberto,  transparente :)
>
> Isso é preocupante. Como fazemos
> > para a sociedade também ter peso nas decisões do W3C?
>
> A sociedade tem peso nas decisões do W3C.  O escritório w3c tem
> incentivado a entrada de mais empresas para o consórcio e a entrada de mais
> pessoas para os working groups. Seria lindo ter mais brasileiros como você
> dentro das listas colocando a posição como sociedade civil para lutar como
> ações como esta. :)
>
> Veeeeenha!
>
> (Leandro Salvador tambem)
>
> >
> > 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
> > >
> >
> > _______________________________________________
> > 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/e580d155/attachment-0003.html>