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

Quinta Maio 16 00:36:03 UTC 2013

Yaso,

> É realmente uma PENA que vocês não estarão aqui na sexta nem estão ativos
> nos WGs (ainda). Mas essa discussão nos dá bastante pano pra manga por
> aqui. Espero que vocês possam acompanhar a discussão no streaming (apesar
> do flash)
>
> Pois é, eu queria ir. Essa questão da nossa participação no evento foi...
complicada aqui. Depois te conto os detalhes.

Mas você tocou num outro ponto importante - a principal conferência da Web
no mundo, que trata de HTML5, está sendo transmitida por vídeo somente em
Flash! Que bom que eu não fui o único que percebi [1] esse contrassenso.

Leandro, entendo o que você diz. Eu mesmo não tenho participado dessa lista
como gostaria (e também estou um bom tempo atrasado na leitura do e-mail
pessoal) porque ando ocupado demais com outras atividades. Torço para que
alguns herois tenham a disponibilidade para carregar essa bandeira e não
deixar a discussão morrer dentro do W3C. Podem contar com o meu apoio
sempre que possível!

Por último, algo bastante relevante a dizer nesta lista é que, como bem
lembrou o Jonathan Gray na lista okfn-discuss, a Open Knowledge Foundation
já ratificou o manifesto contra o DRM no HTML5 [2].

Abraço,
Augusto Herrmann

[1] http://identi.ca/notice/100974977
[2] http://www.defectivebydesign.org/sign-on-against-drm-in-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
>>>
>>>
>>
>> _______________________________________________
>> 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
>
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.okfn.org/pipermail/okfn-br/attachments/20130515/9d512d39/attachment-0003.html>