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 <[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 >> >> > > > -- > > ∞ <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
