La opción de desactivar el ping HTML en el navegador desaparece en Chromium y derivados

Hace muchos años que las webs registran el origen de su tráfico. Sin embargo no hace tanto que la recopilación de datos empezó a estar cada vez más cotizada. Los datos son dinero, y si no que se lo digan a Google, Facebook o Twitter, cuyo negocio real es la publicidad segmentada: les ofrecen a los anunciantes un público receptivo, el cuál seleccionan a través de esos datos que recopilan desde sus servicios “gratuitos”.

Con la implantación del estándar HTML5 ha aparecido una nueva opción que permite controlar cuáles son los enlaces en lo que el usuario hace click, y cuáles no. Hasta la fecha desde el navegador podíamos controlar si queríamos que esos “datos de ping” se enviasen, pero las últimas noticias dicen que muchos de los navegadores van a dejar de soportarlo. La realidad es que es sólo uno el que lo abandona: Google Chrome, lo que no debería resultar raro: es el producto de Google y a Google se le paga en datos. El problema es otro: en los últimos años la mayor parte de los navegadores han ido abandonando su independencia y construyendo directamente sobre le núcleo de Código Abierto de Chromium.

Muchos de lo que me leéis no tenéis ni idea de la tortura que es pelearse para que cualquier aplicación web que hagáis se visualice correctamente en todos los navegadores, especialmente cuando algunos no siguen los estándares (Internet Explorer y yo jamás nos llevaremos bien, nunca llegó a implementar EcmaScript 6 y la retrocompatibilidad es un infierno), por lo que una estandarización es bienvenida, pero que la mayor parte del control de la experiencia de la web esté en manos de un único jugador no puede ser bueno. La imagen lo ilustra claramente 🙂

El reto de los 10 años en los navegadores: antes Chrome, Internet Explorer, Opera y Firefox. Ahora Chromium, Chromium, Chromium y Firefox

Actualmente solo Firefox y Brave permiten evitar esta funcionalidad, y el primero los lleva deshabilitados por defecto. La decisión sobre qué sucede con vuestros datos, es vuestra.

¿Qué significan los cambios propuestos en WebRequest de Google, y cómo te afectan?

Lo primero sería explicar qué es WebRequest: se trata de una API (Interfaz de Programación de Aplicaciones), o subsistema que define la conexión a una serie de servicios, que permite interceptar peticiones en la red, modificándolas, redirigiéndolas o bloqueándolas. Google que sus intenciones son solucionar problemas de rendimiento, seguridad y privacidad.

El logo de Chrome

Casualmente esta es la API que usan extensiones como SwitchyOmega, uBlock Origin (que es una que yo recomiendo) o el famoso AdblockPlus. Esto nos lleva a que sería Google en exclusiva quien tendría capacidad de decidir qué anuncios (o bloqueadores) bloquear, lo que no le viene nada mal a una empresa cuya mayor fuente de ingresos es vender anuncios. Por no hablar de que podría tomar decisiones sobre la visualización de contenidos “personalizando la experiencia” con lo que ellos crean oportuno.

Sumémosle el hecho de que muchos navegadores usan Chromium como base (Opera, Vivaldi, y próximamente Microsoft Edge), por lo que “se contagiarán” de esto. Mi recomendación personal es que uses Firefox, que es la única alternativa válida a día de hoy en la que el usuario sigue teniendo capacidad de decisión. No estaré de acuerdo con algunas de las decisiones recientes de Mozilla (por ejemplo relegar el RSS me parece lamentable, y tampoco me convence que la búsqueda por defecto sea ahora con Google, pero puedo añadir en cualquier momento las extensiones de RSS o cambiar el buscador a DuckDuckGo, cosa que Chrome no me deja).

Las bondades de la lectura en oscuro en el navegador

Una cuestión recurrente en los últimos años es la fatiga visual que sufrimos al utilizar en mucho el ordenador (o el tablet, o el móvil). Me habréis oído hablar del uso de interfaces oscuras en las diversas aplicaciones, pero siempre hubo una gran laguna: las páginas web.

Por definición, los navegadores muestran las páginas con los colores que decidieron sus programadores (como debe ser y no de otra manera), pero en ocasiones, cuando estás leyendo por la noche, una página con su emisión de luz blanca te produce un insomnio que al día siguiente lamentarás, o si eres programador, esa interfaz blanca radiactiva presente tanto en Github como Gitlab hará que te escuezan los ojos al final de la jornada.

Feedly visto en Chromium mediante Dark Reader

Una solución muy interesante es la que nos ofrece el proyecto de código abierto Dark Reader, que nos permite instalar una extensión tanto en Firefox como en Chromium/Chrome que activar o desactivar un modo de lectura bajo en luz de forma intuitiva. O si eres de los que prefieres un tono sepia en lugar del habitual negro, también tienen esa solución. Todo ello mediante temas dinámicos, pero siempre respetando los colores de las fotos, lo que es una auténtica alegría para la vista.