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<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 <[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 >> > > > > -- > > ∞ <http://yaso.eu>yaso.eu > ∞ w3c.br <http://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
