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
