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<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 > >
_______________________________________________ okfn-br mailing list [email protected] http://lists.okfn.org/mailman/listinfo/okfn-br Unsubscribe: http://lists.okfn.org/mailman/options/okfn-br
