Cronológico Linha  

< Cronológico >       < Linha >

---

Continuamos a nossa saga, na qual nos debruçamos sobre questões da Web.
No último texto, foquei no conteúdo Web a que somos expostos, e sobre
como existem páginas bem construídas, simples e leves, ou não tão
leves, mas ao menos com um toque artesanal.

Vimos que simples não quer dizer feio nem disfuncional. Vimos que
felizmente ainda há pessoas preocupadas com conteúdo desnecessário e
páginas complexas.

Mas hoje vamos discutir outro aspecto da Web, o software que faz tudo
funcionar. Se simplificarmos a arquitetura da Web, veremos que há dois
programas principais em uma navegação Web: o servidor Web, que fornece
o conteúdo (documentos html, imagens, estilos css, etc) quando
requisitado, e o cliente Web (no jargão técnico, "agente de usuário"),
cujo tipo mais popular e conhecido é o navegador Web.

Não que servidores não sejam um tópico importante também (e há assuntos
a tratar sobre isso), mas por brevidade (ou tentativa de), vou focar
apenas nos navegadores por hoje.

Dentre os fatores que considero preocupantes em realação a esse
assunto, eu elencaria três principais:

1. A complexidade envolvida na navegação Web (e portanto na construção
de um navegador Web)
2. A real variedade de opções de navegadores
3. O uso dos navegadores como instrumento de controle e coleta de dados

A ordem dos problemas não é por acaso. Considero que o primeiro é um
dos fatores decisivos na ocorrência dos outros dois, e que o segundo
amplifica o terceiro. Então vamos explorar as questões nessa ordem.

Algumas tarefas que precisamos executar em um computador são
inerentemente complexas. Navegação Web é uma delas. Porém, existem
maneiras diferentes de atacar a complexidade. A que vejo como mais
eficaz é dividir os problemas maiores em problemas menores, e
resolvê-los individualmente, e no processo remover tudo aquilo que não
seja essencial. Ainda assim, construir e manter um navegador Web não é
uma tarefa nada trivial.

Um trabalho interessante no sentido de definir uma arquitetura
conceitual com base em implementações existentes foi feito na
Universidade de Waterloo, por Alan Grosskurth e Michael W. Godfrey. Os
links para dois artigos [1][2] relacionados a esse trabalho estão
disponíveis a seguir.

[1] https://grosskurth.ca/papers/browser-refarch.pdf
[2] https://grosskurth.ca/papers/browser-archevol-20060619.pdf

Como evidenciam, existem várias partes que precisam compor um navegador
para que ele funcione no modo como estamos acostumados. Portanto,
manter tudo isso sozinho pode ser altamente custoso. O reuso de
bibliotecas de código aberto (para interpretação XML, ou comunicação
HTTP, por exemplo) ameniza o problema, embora por outro lado faça com
que os navegadores fiquem mais parecidos no modo como funcionam.

A parte mais complexa de um navegador é o mecanismo de renderização
[3]. Na tentativa de reduzir o custo de desenvolvimento e manutenção,
muitos navegadores reutilizam esse mecanismo. E é aí que esbarramos no
segundo ponto, a falta de variedade entre os navegadores. O que ocorre
na maior parte das vezes é uma reedição de outros navegadores, trocando
apenas a casca. Isso nos leva a um cenário de pouca inovação e pouca
concorrência (algo especialmente preocupante se consideramos o aspecto
comercial de alguns navegadores).

[3] https://pt.wikipedia.org/wiki/Mecanismo_de_renderiza%C3%A7%C3%A3o

Hoje há uma concentração muito grande sobre o motor Blink [4], da
Google, que é usado no navegador Chromium [5] e em navegadores
derivados dele, como o Chorme. Diversos navegadores, tanto de código
fechado quanto abertos aderiram a ele, mesmo após um histórico
consolidado utilizando outros motores.

[4] https://www.chromium.org/blink/
[5] https://www.chromium.org/Home/

É triste observar como mecanismos inovadores e promissores foram
abandonados em favor dele. É o caso do Presto [6], por exemplo,
desenvolvido para uso no navegador Opera. Infelizmente, seu código
nunca foi aberto (embora já tenham ocorrido vazamentos [7], em 2017).

[6] https://pt.wikipedia.org/wiki/Presto_(motor_de_renderiza%C3%A7%C3%A3o)
[7]
https://blogs.opera.com/security/2017/01/legacy-opera-presto-source-code-appearance-online-sharing-sites/

Outro caso conhecido de substituição para o Blink é o do KTHML [8]
(antigo motor usado nos programas do KDE), que era usado no navegador
Konqueror [9].

[8] https://pt.wikipedia.org/wiki/KHTML
[9] https://apps.kde.org/konqueror/

Depois do Blink, outros motores que agregam uma quantidade ainda
expressiva de navegadores e base de usuários estão o Webkit [10] e o
Gecko [11]. Desses, o que ainda possui algum cuidado com uma base de
código mais enxuta é o Webkit, embora ainda assim seja relativamente
grande.

[10] http://www.webkit.org/
[11] https://developer.mozilla.org/pt-BR/docs/Glossary/Gecko

Há uns dias, encontrei por acaso um interessante infográfico
(atualizado em abril de 2023) [12], recapitulando a trajetória dos
motores criados para a Web ao longo dos anos.

[12] https://eylenburg.github.io/browser_engines.htm

Como observamos, há um grande desequilíbrio entre a quantidade de
navegadores existentes e a quantidade de motores para navegação e
renderização, sendo que dentre os mais utilizados estão justamente os
mais complexos (ao mesmo tempo em que são mais complexos porque são
mais usados e precisam atender mais cenários distintos de uso).

Essa concentração de navegadores sobre alguns poucos motores colocam um
grande poder na mão dos desenvolvedores desses motores. Isso pode se
tornar um problema, quando a conduta dos desenvolvedores e/ou da
organização que determina as diretrizes do desenvolvimento cai sob
suspeita. Vejamos por exemplo a conduta da Mozilla (empresa por trás do
motor Gecko), ao longo dos anos, nesse assustador histórico intitulado
"Mozilla Devil Incarnate" [13]:

[13] https://digdeeper.neocities.org/articles/mozilla

Como nos mostra o artigo, um outro problema relacionado aos navegadores
é a quantidade de dados coletados pelos navegadores. Isso parece ter se
tornado uma tendência, inclusive entre alguns que se vendem como
navegadores "pró-privacidade".

Um interessante projeto relacionado se chama "Spyware Watchdog Article
Catalog" [14], um catálogo de aplicações (dentre elas, vários
navegadores Web) que potencialmente coletam dados ou realizam chamadas
a servidores externos sem o consentimento do usuário, apontando
evidências para isso.

[14] https://spyware.neocities.org/articles/

Como podemos perceber, o cenário de desenvolvimento de navegadores
ainda nos apresenta grandes desafios. Enquanto internautas usuários da
Web, devemos nos preocupar com questões como a complexidade dos
navegadores, que nos levam a aplicações pesadas, que consomem muito
recurso da máquina e constantemente apresentam bugs que podem
comprometer sua segurança. O uso de plugins muitas vezes é usado para
tentar conter as brechas, que não deveriam sequer existir, em primeiro
lugar.

Além disso, vemos um cenário de baixa inovação e baixa concorrência, e
por fim ainda temos o problema da coleta de dados, proveniente de um
desenho falho.

Assim como acontece com a criação de conteúdo, não é que não existam
opções melhores ou que ao menos que sejam menos danosas. Porém elas são
muitas vezes pouco conhecidas ou não possuem uma grande quantidade
ainda de atenção para poder se propagar como uma norma mais sadia para
a Web.

Eu poderia continuar falando sobre esse assunto, mas acredito que se
você chegou até o fim desse artigo, já deve ter se cansado desse
assunto e precisa se delisgar um pouco disso. Continuo falando numa
próxima ocasião, focando no lado do servidor, que também possui algumas
questões importantes. Obrigado pela leitura.

--
Att,
@hrcerq

0/ ´ ° ` o ´ ° ` \0

---

• A sobrevida da Web (parte 3), hrcerq, 05/02/2024

---

Arquivo provido por MHonArc 2.6.24.