[okfn-br] Say NO to DRM in HTML5!

Quarta Maio 15 19:17:28 UTC 2013

Opa la!

Em 15/05/2013 11:31, "Felipe Sanches" <juca em members.fsf.org> 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 <yasodara.cordova em gmail.com>:
> > 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" <leandrosalvador em gmail.com>
> > 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" <yasodara.cordova em gmail.com>
> >> 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 <thiago.rondon em gmail.com>
> >>>>
> >>>>
> >>>>
> >>>> 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
> >>>> okfn-br em lists.okfn.org
> >>>> 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
> >>> okfn-br em lists.okfn.org
> >>> http://lists.okfn.org/mailman/listinfo/okfn-br
> >>> Unsubscribe: http://lists.okfn.org/mailman/options/okfn-br
> >>>
> >>
> >> _______________________________________________
> >> okfn-br mailing list
> >> okfn-br em lists.okfn.org
> >> http://lists.okfn.org/mailman/listinfo/okfn-br
> >> Unsubscribe: http://lists.okfn.org/mailman/options/okfn-br
> >>
> >
> > _______________________________________________
> > okfn-br mailing list
> > okfn-br em lists.okfn.org
> > http://lists.okfn.org/mailman/listinfo/okfn-br
> > Unsubscribe: http://lists.okfn.org/mailman/options/okfn-br
> >
>
> _______________________________________________
> okfn-br mailing list
> okfn-br em lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/okfn-br
> Unsubscribe: http://lists.okfn.org/mailman/options/okfn-br
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.okfn.org/pipermail/okfn-br/attachments/20130515/f99df14e/attachment-0003.html>