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 <[email protected]> > Opa la! > > Em 15/05/2013 11:31, "Felipe Sanches" <[email protected]> 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 <[email protected]>: > > > 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" <[email protected]> > > > 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" <[email protected]> > > >> 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 <[email protected]> > > >>>> > > >>>> > > >>>> > > >>>> 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 > > >>>> [email protected] > > >>>> 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 > > >>> [email protected] > > >>> http://lists.okfn.org/mailman/listinfo/okfn-br > > >>> Unsubscribe: http://lists.okfn.org/mailman/options/okfn-br > > >>> > > >> > > >> _______________________________________________ > > >> okfn-br mailing list > > >> [email protected] > > >> http://lists.okfn.org/mailman/listinfo/okfn-br > > >> Unsubscribe: http://lists.okfn.org/mailman/options/okfn-br > > >> > > > > > > _______________________________________________ > > > okfn-br mailing list > > > [email protected] > > > http://lists.okfn.org/mailman/listinfo/okfn-br > > > Unsubscribe: http://lists.okfn.org/mailman/options/okfn-br > > > > > > > _______________________________________________ > > okfn-br mailing list > > [email protected] > > http://lists.okfn.org/mailman/listinfo/okfn-br > > Unsubscribe: http://lists.okfn.org/mailman/options/okfn-br > > _______________________________________________ > okfn-br mailing list > [email protected] > http://lists.okfn.org/mailman/listinfo/okfn-br > Unsubscribe: http://lists.okfn.org/mailman/options/okfn-br > >
_______________________________________________ okfn-br mailing list [email protected] http://lists.okfn.org/mailman/listinfo/okfn-br Unsubscribe: http://lists.okfn.org/mailman/options/okfn-br
