Re: [lp-br-sp] [lp-br-es] Navegadores respeitosos existem?

[Ricardo Panaggio]

On 29/08/17 06:13 PM, Thadeu Lima de Souza Cascardo wrote:
> On Tue, Aug 29, 2017 at 05:21:57PM -0300, panaggio wrote:
>>> On Tue, 2017-08-29 at 13:41 -0300, Thadeu Lima de Souza Cascardo
>>> wrote:
>>>  E
>>> torcer pro SSL do servidor estar atualizado e com chaves novas,
>>> porque
>>> Heartbleed. Agora, se você envia seus dados (ainda que somente
>>> User-Agent), se você usa algo atrás de um grande provedor,
>>> Cloudbleed. O
>>> negócio tá feio.
>>
>> Infelizmente isso está fora do controle de pessoas normais. Precisamos
>> de uma nova internet, menos centralizada, pra resolver esse tipo de
>> problema. Isso pro Cloudbleed. Mas a tendência da humanidade é
>> centralizar e terceirizar as coisas. É nossa cultura. Será que isso vai
>> ter remédio? Talvez a próxima espécie dominando do Homo seja mais
>> esperta que a gente.
> 
> Sem dúvida. É um sério problema. Tem uma discussão lateral ocorrendo na
> debian-devel sobre software cada vez mais sob o controle de um terceiro,
> se deveria estar na main ou não.

OT: pessoas normais podem entrar nessa lista, certo? Eu adoraria nem que
fosse apenas acompanhar essa conversa. Me inscrevi e estou procurando
isso nos arquivos.

> A minha resposta a isso é conversar mais sobre isso, pra conscientizar
> mais pessoas de que isso é um problema, e escrevermos mais software,
> fazermos mais coisas que funcionem offline. Navegação geográfica, por
> exemplo, é um problema que pode ser resolvido offline e, por muito
> tempo, foi.

Ufa. Isso soa tão bem pra mim que faz parte de mim me sentir menos
sozinho na minha ideia de que tem coisa demais errada, e que SaSS virou
praticamente do dia pra noite um dos nossos maiores pesadelos, e um dos
que mais precisamos lutar contra.

> Pra não ficar me somente um exemplo, e usar um exemplo da Web: existem
> ferramentas que permitem fazer download e ler a wikipedia offline.

Então, nesse caso específico, eu tive uma experiência relevante. Eu já
parseei a Wikipédia inteira, em português e inglês, dezenas de vezes,
até que fiz um parser que conseguia fazer parse uma vez do dump total e
depois só aplicar patches usando os diffs (Podia ter feito certo da
primeira vez, mas meu tempo era mais caro que o tempo das máquina. Coisa
de startup; isso foi feito para o falecido Umamão). Mas tive que alugar
uma máquina pra fazer isso na época, com RAM suficiente pra colocar tudo
em memória. Só o texto hoje, da wikipédia em inglês, tem mais de 10GB.
Compactado. Em XML. Sei que dá pra fazer um dump melhor, que seja mais
facilmente acessível, e que talvez fosse o rumo certo para a Wikipédia:
armazenar tudo de maneira distribuída, cada um com uma porcentagem do
mirror (podendo ser 100% se a pessoa tiver hardware e vontade, porque
não?). Mas não sei se a WikiMedia ia querer isso. Alguém conseguiria
levar essa pergunta até tão alto que pudesse ser respondida por quem
toma esse tipo de decisão? A tecnologia para fazer isso está
praticamente pronta. É só uma questão de adaptar. E isso seria épico
para mostrar como isso é uma solução tanto factível como desejável.

> Outra maneira de usar a web de forma offline após um download, e sem o
> uso de um navegador é o uso de feeds (prefiro Atom a RSS :-). No SFD2016
> que fizemos, o GFTG falou sobre RSS e eu falei sobre Software as a
> Service Substitute, que é fazer justamente o oposto do que a indústria
> tem feito: substituir serviços por software, ainda que sejam serviços
> que antes já eram providos como software. Ou seja, permitir que mais
> coisas que hoje fazemos online sejam feitas offline. Ou ainda, de forma
> mais distribuídas.
> 
> Ou seja, temos que falar mais sobre isso, e fazer mais sobre isso. E
> acho que cada gotinha vale. Não precisamos ficar desestimulados porque
> achamos que é necessário muito esforço coletivo pra atingirmos o
> objetivo. Talvez seja, mas sem a nossa participação, por menor que seja,
> levaremos mais tempo pra chegar lá.
> 
> Sobre o Cloudbleed ou o uso de Cloudflare, é triste mesmo. O que fazer?
> Há muitas maneiras de distribuir a carga, e temos que usar isso mais.
> Onion services, GNUNet, ZeroNet, Bittorrent, etc, etc? Temos que usar
> tudo o que temos. E se temos tantas ferramentas a escolher, é porque
> outras pessoas se interessam em resolver os mesmos problemas, e isso tem
> que nos animar, não nos colocar pra baixo.

Esses três últimos parágrafos valeram mais que anos de terapia. Muito
obrigado Cascardo!

Acho que está na hora de eu voltar a escrever software. E parar de
resolver problemas bestas dos outros e começar a resolver problemas de
todo mundo. Só preciso descobrir como fazer os dois sem acabar com a
minha reserva que já está no fim.

>> Heartbleed eu considero uma ocorrência infeliz apenas. Não tinha muito
>> como fugir. Foi um bug e bugs acontecem. SO que dá pra fazer hoje é
>> torcer para que os adms dos servidores com os quais você interage
>> tenham feito a lição de casa.
> 
> Mas mostra que toda maioria é burra.  :-P   Deveríamos usar mais outras
> bibliotecas TLS/SSL por aí. Além do mais, mostra que precisamos de mais
> camadas de proteção, que devemos usá-las. E que só a bandeirinha do
> ecommerce não vai nos salvar. Isso inclui ter mais comunicação local.
> Esse email que estou trocando com um grupo majoritariamente no Brasil
> vai bater certamente na Europa (porque meu servidor está hospedado lá),
> e muito provavelmente na América do Norte.

Certamente bateu em todos esses lugares. Há pessoas aqui com servidores
na América do Norte e o meu também fica na Europa. E se fosse algo
sensível, o Google e a Microsoft também estariam lendo, porque temos
assinantes que usam e-mails das duas empresas (até onde me recordo). E a
lista ainda tem o arquivo aberto, não? Então está sendo lida por dezenas
ou centenas de robôs.

Para ficar registrado: depois de eu citar a palavra "dropbox" na lista
ontem, eu recebi ~10 scams sobre dropbox, todos sobre uma criação de
conta que não existiu apontando cada uma para um bait diferente. Esse é
o mundo em que vivemos.

>>> Em uma nota um pouco mais prática: Tor Browser. Só porque você
>>> perguntou
>>> especificamente por "Android",
>>> https://www.torproject.org/about/jobs-osdeveloperandroid.html.en
>>
>> Então, eu até usei ele, mas não resolve nem metade dos problemas. Na
>> verdade, se alguns dos plugins que citei funcionassem nele, resolveria
>> grande parte do problema, mas não é tão simples assim infelizmente :(
>>
> 
> Não, mas talvez seja a organização que você procura, ou o projeto com o
> qual colaborar. Não é tão simples mesmo. Tendo o Firefox como upstream,
> fica difícil. Manter um projeto downstream, com patches e tudo o mais é
> complicado. Mas é mais simples que fazer um browser do zero. Existem
> algumas boas práticas pra tornar o trabalho downstream menos laboroso:
> subir o máximo de patches upstream, e fazer rebase com a maior
> frequência possível, porque não há nem garantias que upstream vai manter
> os seus patches que estão lá.

Alguém sabe de algum navegador que queira ser esse navegador respeitoso
que eu sugeri no início da thread?

IceCat parece ter alguém sentando em cima ou então muitas mãos de menos
trabalhando nele. E de toda forma, ele precisa de um mundo de mudanças
pra ficar minimamente aceitável.

Outra coisa: eu não tenho tanta experiência com manutenção de forks com
alterações tão frequentes quanto o Firefox. O projeto mãe do Umamão era
fácil de fazer rebase, mesmo a gente tendo feito um fork monstruoso em
cima, mas porque as alterações ou eram pequenas, ou porque a gente já
conhecia tão bem o código original e o nosso que sabia o que fazer com
as mudanças grandes.

>>> Infelizmente, manter um web browser capaz de atender às necessidades
>>> de
>>> muitos usuários de hoje em dia, ou seja, suportando a Web "moderna",
>>> com
>>> Javascript, CSS3, HTML5, etc, etc, é um trabalho pra muitos, e já
>>> ouvi
>>> que não dá pra manter versão estável de browsers usando WebKit,
>>> porque o
>>> upstream mesmo não dá um bom suporte.
>>
>> Eu temia que fosse necessário criar um novo coletivo para resolver esse
>> problema de privacidade, como a Mozilla apareceu para resolver o
>> problema da falta de padronização 15 anos atrás. Pode parecer
>> romantização da minha parte, mas precisa de muita gente como você
>> disse, muito esforço, muito dinheiro provavelmente, e não vamos ser
>> nós, meia dúzia, que vamos resolver. Eu só esperava ouvir que talvez
>> tivesse outra solução que não fosse começar quase do zero e erguer um
>> navegador novo, livre de companhias que cagam e andam pro usuário, só
>> pensam nos dados que vão coletar no final do dia. Mas acho que meu
>> maior medo é a realidade.
>>
>> Ou, pior ainda, talvez a web como conhecemos já esteja perdida pra
>> sempre, não tenha mais volta. E vamos ter que começar algo novo, do
>> zero, como GNUnet, ZeroNet, e ver se dá pra salvar essas outras do caos
>> que certamente quem domina a internet e a web hoje vão querer impor.
>>
>> -- 
>> Ricardo Panaggio
> 
> Uma outra alternativa, na minha opinião, é construir aplicações nativas
> que consumam mais o conteúdo ou o serviço que se quer acessar. Isso
> praqueles casos em que não dá pra fazer offline ou distribuído mesmo. Dê
> uma olhada no weboob (https://weboob.org/) pra ter um exemplo. É claro
> que muitos desses "serviços" costumam quebrar alguma coisa, com
> frequência. Por isso mesmo, temos que escrever mais protocolos
> padronizados e abertos para distribuir tal conteúdo. De preferência,
> distribuídos. Quando se trata de um serviço que exige comunicação
> centralizada, utilizar padrões também.
> 
> Mas isso não é um mundo ideal, uma utopia? É sim! Mas precisamos
> conversar sobre isso! Eu dei uma palestra no Web.BR ano passado sobre o
> assunto. Precisamos fazer mais. E precisamos escrever código, fazer
> engenharia reversa. É um jogo de gato e rato? Talvez seja, mas é um jogo
> que, se não jogarmos, vamos perder com certeza. Ou não vamos perder, mas
> vamos ter que viver isolados em nosso mundinho de listas de e-mail, IRC
> e wiki. E fazer a travessia dolorosa sempre que precisarmos de algo que
> esteja nesse mundo além.
> 
> Eu não acho que estamos perto do fim. Veja coisas como Bitcoin, que
> desafiam o sistema financeiro. Sem dúvida, tem seus defeitos, está longe
> de ser um David para o Golias, mas está aí. Alguém fez, e inspirou um
> monte de outras coisas que estão aparecendo por aí.
> 
> Veja a Wikipedia. Todo ano, ela faz propagandas irritantes sobre como
> ela não faz propaganda. E como isso é legal! Eu fiz minha doação. E
> preciso contribuir mais com conteúdo, como comecei a fazer no início do
> projeto.
> 
> E tantos outros projetos, pequenos, grandes, esquecidos, mantidos, etc.
> E vamos dando nossa parte. De pouco em pouco, fazemos diferença pra
> alguém.
> 
> Pode ser que essa preocupação seja de uma minoria. E acredito que seja,
> e que talvez isso não mude. Então, não dá pra esperar que, de repente,
> alguém muito grande com muito dinheiro, de fora da nossa comunidade, vai
> aparecer e resolver o nosso problema. E isso é algo que não devemos
> querer. É justamente a antítese do que queremos: alguém grande, com
> muitos recursos (e poderes) resolvendo o problema pra gente. Então, tem
> que partir da nossa própria comunidade a solução, ainda que seja algo
> que só nós utilizemos inicialmente. E vamos espalhando a notícia, pra
> que mais gente venha nos conhecer.

Acho que nessa parte você está corretíssimo. Sonho meu achar que mais um
power hog resolveria o problema. Se não for trabalho de formiga, só vão
aparecer mais problemas.

Acho que chegou a hora de voltar à ativa. E de um jeito melhor. Não acho
que consigo mais falar em público como antes, mas talvez ainda consiga
fazer uma engenharia reversa aqui e escrever uns patches ali.

Essa foi uma das --t-r-o-c-a-s- -d-e- -e-m-a-i-l-- conversas mais
inspiradoras da minha vida toda. Obrigado a todos os envolvidos!

Obrigado mesmo por fazer essa eterna fênix começar a renascer das cinzas!

-- 
Ricardo Panaggio

signature.asc
Description: OpenPGP digital signature