En Android y en otros sistemas, la palabra blob se usa a menudo para hablar de piezas de software cerradas. En concreto, los blobs binarios o propietarios son fragmentos que controlan funciones clave del hardware y que se incluyen sin publicar su código fuente. En teléfonos y tablets esto afecta al módem, la GPU, el GPS, la cámara o la WiFi, por lo que su presencia condiciona qué podemos auditar, modificar o reparar. Sin estos componentes muchos dispositivos ni arrancan correctamente ni alcanzan todas sus funciones, de ahà el dilema: comodidad frente a libertad y seguridad verificable.
El debate no es nuevo y atraviesa de lleno al ecosistema del software libre: hay proyectos que aceptan blobs por pragmatismo para que el equipo funcione, y hay iniciativas que los rechazan para preservar transparencia y control del usuario. En Android la discusiĂłn es especialmente intensa porque casi todo el stack del hardware depende de controladores cerrados, lo que explica que los intentos de crear telĂ©fonos completamente libres hayan chocado con lĂmites tĂ©cnicos y legales durante años.
Qué son exactamente los blobs binarios o propietarios en Android
En el argot de las comunidades de software libre, un blob binario es un objeto cargado en el nĂşcleo o en el sistema sin acceso al cĂłdigo fuente. Hablamos de binarios precompilados que el fabricante proporciona en lugar de documentaciĂłn tĂ©cnica, la cual permitirĂa crear controladores abiertos. Es práctica habitual con GPUs, chipsets de red, modems celulares o controladoras RAID, y en Android se extiende a buena parte del hardware del terminal.
Cuando un proveedor publica manuales completos y especificaciones, los desarrolladores pueden escribir drivers abiertos y mantenerlos con la comunidad. El problema aparece cuando el proveedor no documenta o impone acuerdos de confidencialidad, obligando a integrar su blob propietario en la vendor partition. AsĂ el sistema depende de ese binario, de su licencia y del soporte que el fabricante quiera prestar en el tiempo.
Las consecuencias son claras y han sido ampliamente documentadas por la comunidad: el usuario no puede modificar ni redistribuir versiones derivadas de esos binarios; su portabilidad queda limitada a unas pocas arquitecturas; la calidad y correcciĂłn no pueden verificarse; no es posible auditar la seguridad ni detectar puertas traseras con garantĂas; y en caso de fallos o vulnerabilidades la comunidad no puede corregirlos sin intervenciĂłn del proveedor. Además, el vendedor puede dejar de dar soporte en cualquier momento, dejando dispositivos funcionales sin actualizaciones crĂticas.
Para paliar la ausencia de drivers nativos, a veces se recurre a wrappers que hacen de capa de compatibilidad. Estos envoltorios permiten usar controladores pensados para otros sistemas, pero no resuelven el núcleo del problema: el componente sigue siendo opaco, dependiente y, a menudo, frágil ante cambios del sistema anfitrión.
En el mundo de los sistemas tipo BSD y GNU/Linux encontramos posiciones muy variadas. NetBSD, FreeBSD o DragonFly BSD han aceptado blobs en determinados casos para cubrir funcionalidades que de otro modo no existirĂan. OpenBSD y LibertyBSD mantienen una postura firme de no incluir ningĂşn blob en su árbol, priorizando seguridad comprobable y transparencia. Entre las distribuciones 100% libres, destacan gNewSense, Trisquel o Parabola por su oposiciĂłn activa a los blobs.
Riesgos, motivos de rechazo y posturas en la comunidad
Los motivos para evitar blobs binarios se repiten una y otra vez entre desarrolladores y usuarios avanzados. Los puntos crĂticos abarcan libertad de uso, portabilidad, correcciĂłn, auditorĂa de seguridad y mantenimiento, y no son teĂłricos: afectan al dĂa a dĂa de quienes quieren un sistema confiable a largo plazo.
- No se pueden modificar ni redistribuir: el usuario no controla el software ni puede adaptarlo a sus necesidades o compartir mejoras.
- Portabilidad limitada: suelen estar compilados para unas pocas arquitecturas y no es viable migrarlos a otros sistemas.
- VerificaciĂłn imposible: no hay forma de revisar su correcciĂłn ni su calidad interna.
- AuditorĂa de seguridad nula: el binario podrĂa esconder puertas traseras o spyware sin que nadie externo lo detecte con facilidad.
- Sin reparaciĂłn comunitaria: ante errores o vulnerabilidades, la correcciĂłn depende exclusivamente del proveedor.
- Soporte volátil: el fabricante puede abandonar el mantenimiento y dejar el dispositivo expuesto.
La Fundación para el Software Libre (FSF) promueve activamente que los sistemas eviten blobs y recomienda distribuciones libres como Trisquel, Parabola o gNewSense. Incluso distingue entre firmware y blobs del kernel, impulsando campañas para firmwares y BIOS abiertas que eliminen dependencias privativas en el arranque.
En el terreno mĂłvil, la FSF ha apoyado iniciativas para empujar hacia telĂ©fonos totalmente libres. Un ejemplo reciente es LibrePhone, cuya meta es sustituir los Ăşltimos componentes privativos que sobreviven en proyectos como LineageOS, mediante ingenierĂa inversa y desarrollo de alternativas abiertas. La primera fase ha sido financiada por donaciones, con la idea de documentar a fondo un modelo de telĂ©fono y reemplazar pieza a pieza los binarios cerrados. El reto no es solo tĂ©cnico: tambiĂ©n legal, por los estrictos NDA que protegen la documentaciĂłn de chips de proveedores como Qualcomm o Broadcom.
Otros proyectos han seguido estrategias más pragmáticas. GrapheneOS y LineageOS, por ejemplo, eliminan el software de Google y refuerzan seguridad y privacidad (consulta una guĂa para crear una ROM personalizada), pero mantienen blobs propietarios para que el dispositivo sea utilizable. No cumplen el ideal de 100% software libre, pero ofrecen un equilibrio razonable entre funcionalidad y control, con la esperanza de que la industria avance hacia más apertura.
Android, el hardware del mĂłvil y el muro de los controladores
Si pensamos en un Android sin blobs, enseguida aparece Replicant, que intentĂł desde 2010 ofrecer una variante completamente libre. El proyecto logrĂł retirar componentes de Google, pero se estrellĂł contra la realidad del hardware: sin documentaciĂłn oficial era inviable reimplementar drivers crĂticos. Por eso hoy funciona en telĂ©fonos antiguos y con funciones recortadas, un compromiso que muchos usuarios no pueden aceptar.
La dependencia de blobs se nota sobre todo en el módem celular (baseband), la GPU, el GPS o la cámara. Estas piezas son las que más se resisten a abrirse por razones comerciales y de propiedad intelectual, y sin ellas no hay señal, no hay aceleración gráfica ni fotos a la altura. De ahà que la prioridad en iniciativas como LibrePhone sea aislar y sustituir estos componentes, empezando por elegir dispositivos donde ese trabajo sea factible y documentable.
En paralelo, se observa movimiento en la industria. GrapheneOS ha anunciado que colabora con un gran fabricante Android para llevar su sistema más allá de los Pixel, exigencia que histĂłricamente imponĂa por criterios de seguridad y actualizaciones. Aunque sigue requiriendo blobs propietarios, su expansiĂłn sugiere que algunos fabricantes empiezan a tomarse en serio estos estándares, con potencial para que el mercado abrace prácticas más abiertas a medio plazo.
Chromebooks, Coreboot, Libreboot y la cuestiĂłn de los blobs
Chromebooks y firmware abierto ilustran bien el problema. Google ha impulsado Coreboot en sus equipos, pero eso no equivale a ausencia total de blobs. La FSF no otorga su certificación “respects your freedom” a estos portátiles porque aún contienen componentes privativos, especialmente en áreas como la GPU o la WiFi. Por ejemplo, muchas tarjetas Atheros funcionan sin blobs, pero no todas y no las más modernas; además, en Chromebooks los módulos WiFi pueden ir soldados o usar conectores propietarios.
En gráficos, la situación histórica ha sido dispar. Nvidia con chips Kepler ofrece resultados muy dignos con el driver abierto Nouveau, incluido el reclock manual de núcleo y memoria para recuperar frecuencias de fábrica. En generaciones como Maxwell de primera hornada se logró reclock parcial (núcleo), y en otras persisten limitaciones. En AMD, pese a los grandes avances de sus controladores libres, los chips siguen requiriendo firmware privativo para funcionar; sin él, la GPU queda prácticamente inutilizable.
Para quienes quieren usar GNU/Linux en un Chromebook sin depender de 3D propietario, se recomiendan escritorios ligeros como LXDE o Xfce, que no exigen aceleraciĂłn 3D. Es un enfoque pragmático cuando no hay alternativa libre con rendimiento adecuado. Eso sĂ, cambiar hardware (como la tarjeta WiFi en portátiles con Mini PCIe) puede anular garantĂas y no siempre es factible en equipos nuevos.
Libreboot lleva el ideal más lejos que Coreboot: elimina por principio los blobs, automatiza compilaciĂłn e instalaciĂłn, y proporciona imágenes ROM listas para flashear junto a utilidades como flashrom y un payload GRUB integrado. Entre sus objetivos están: distribuir solo software libre, facilitar el uso a no expertos, ofrecer tiempos de arranque ágiles, mayor seguridad y plena capacidad de personalizaciĂłn. A cambio, soporta menos hardware, precisamente porque muchos equipos aĂşn dependen de piezas privativas para arrancar o inicializar subsistemas crĂticos.
- Solo software libre: evita microcĂłdigo privativo, inicializaciĂłn de vĂdeo cerrada o mĂłdulos propietarios, y desaconseja añadir componentes como Intel Management Engine.
- Más automatización: desde la compilación a la instalación, con documentación orientada a usuarios y canales de soporte comunitario.
- ROMs precompiladas: imágenes listas para flashear, también en tamaños no estándar (por ejemplo, 16 MiB) cuando el hardware modificado lo requiera.
- Actualizaciones sencillas: sin DRM ni bloqueos del fabricante; posibilidad de subir o bajar de versiĂłn con libertad plena.
- Respuesta ágil: ante fallos o vulnerabilidades, la comunidad actĂşa con rapidez, frente a la inercia tĂpica de firmwares propietarios.
En el lado del procesador, los Chromebooks con ARM han sido valorados por su bajo consumo y ausencia de microcĂłdigo actualizable como en Intel. TambiĂ©n se mencionan aspectos positivos como el uso de software libre en el controlador embebido (EC) en ciertos modelos. Con Intel, en cambio, preocupa la combinaciĂłn de microcĂłdigo, tecnologĂas de administraciĂłn remota como AMT y la presencia del subsistema Management Engine, considerado por muchos como una zona opaca con riesgos potenciales para privacidad y seguridad.
El panorama general deja una conclusiĂłn incĂłmoda: la mayorĂa de usuarios arrancan sus máquinas con firmwares cerrados repletos de blobs, y reemplazarlos exige pericia, tiempo y hardware compatible. La ingenierĂa inversa es lenta, costosa e incierta, por lo que los avances llegan por oleadas y a menudo resultan especĂficos de unos pocos modelos.
No confundir con Blob Storage: almacenamiento de objetos en la nube
El término blob también aparece en la nube con un significado muy distinto: Binary Large Object como sinónimo de objeto de datos. En este contexto, Blob Storage (S3, Azure Blob Storage, Google Cloud Storage) es un servicio para guardar y recuperar datos no estructurados a gran escala. No hablamos de controladores propietarios, sino de archivos y metadatos almacenados como objetos dentro de contenedores, accesibles por APIs, SDKs y herramientas CLI.
La estructura tĂpica tiene una cuenta de almacenamiento como espacio de nombres, dentro contenedores, y en ellos objetos con datos binarios, metadatos e identificadores Ăşnicos. Los proveedores ofrecen niveles de precio y rendimiento (hot, cool, archive) segĂşn la frecuencia de acceso, con durabilidad mediante replicaciĂłn y disponibilidad global.
Los casos de uso más comunes incluyen publicaciĂłn y distribuciĂłn de contenido multimedia (imágenes, vĂdeo, audio) y hosting estático de sitios web (HTML, CSS, JS e imágenes). TambiĂ©n es la base de data lakes y analĂtica, donde se guardan datos estructurados, semiestructurados y no estructurados para big data y machine learning. En empresas, sirve como repositorio de documentos, PDFs y registros digitalizados.
- Ventajas: escalabilidad elástica, durabilidad mediante replicación, alcance global, costes ajustables y fácil integración con servicios de análisis.
- Limitaciones: latencia mayor que el bloque, semántica distinta al sistema de archivos y recuperaciones más lentas en niveles de archivo.
Integrar Blob Storage en soluciones reales es directo: crear o usar una cuenta, generar el contenedor, establecer credenciales seguras y subir el objeto con sus metadatos y polĂticas de acceso. Este flujo funciona con SDKs en JavaScript, Python o Java, y con CLIs como Azure CLI o AWS CLI. Es la forma natural de almacenar datasets para IA, backups empresariales, contenido estático para apps web y mĂłviles, o conectar pipelines ETL hacia Power BI o herramientas de BI.
Incluso hay consultoras especializadas que diseñan arquitecturas a medida en AWS y Azure combinando ciberseguridad, IA aplicada y analĂtica de datos. Sus servicios abarcan desde el desarrollo de software y agentes de IA hasta hardening y dashboards, con proyectos donde Blob Storage es la columna vertebral para datasets de entrenamiento, backups, archivos estáticos y analĂtica escalable. Es importante insistir: este uso de “blob” nada tiene que ver con los blobs propietarios del kernel; aquĂ hablamos de objetos de datos en cloud.
Privacidad, seguridad y cĂłmo moverse en Android con el mĂnimo de blobs
Para usuarios preocupados por privacidad y control, el itinerario razonable suele pasar por elegir dispositivos con buen soporte comunitario, optar por ROMs centradas en seguridad y minimizar la dependencia de Google cuando sea posible. LineageOS y GrapheneOS reducen la exposiciĂłn y fortalecen el sistema, aunque no puedan eliminar todos los blobs por razones de hardware. Es clave verificar el estado de soporte de cada modelo y las actualizaciones de seguridad disponibles.
Si buscas equipos de sobremesa o portátiles con menos componentes cerrados, explorar hardware compatible con Coreboot o Libreboot es una vĂa conocida, con la salvedad de que el catálogo es limitado y la instalaciĂłn exige cuidado. Revisar el estado de la GPU, la tarjeta WiFi y el firmware de arranque antes de comprar evita sorpresas posteriores. En entornos sin 3D intensivo, escritorios ligeros como Xfce o LXDE ayudan a esquivar dependencias de aceleraciĂłn propietaria.
Conviene tambiĂ©n separar expectativas: lograr un Android 100% libre hoy es extremadamente difĂcil, por lo que el objetivo práctico es reducir la superficie cerrada y apostar por proyectos con auditorĂas, parches rápidos y polĂticas de seguridad estrictas. La comunidad lleva años presionando para abrir piezas clave del hardware mĂłvil; la colaboraciĂłn de fabricantes será determinante para que esa presiĂłn se traduzca en documentaciĂłn y controladores abiertos.
Más allá del móvil, la conversación pública sobre firmware, microcódigo y subsistemas opacos (como Intel Management Engine) ha crecido con razón. El primer software que se ejecuta al encender el equipo es el más sensible, y cualquier error o comportamiento no documentado puede afectar a todo lo que viene después. Reducir blobs en esa capa, cuando es viable, aporta beneficios reales en seguridad y en capacidad de respuesta ante incidentes.
En medios tecnolĂłgicos se viene cubriendo este tira y afloja entre funcionalidad inmediata y libertad a largo plazo. Algunas redacciones han señalado que proyectos como LibrePhone o avances en sistemas centrados en privacidad mandan un mensaje a la industria: si nadie empuja, la apertura total no llegará sola. Aun no siendo un camino corto ni barato, cada pieza sustituida por un componente abierto amplĂa la posibilidad de auditar, mejorar y mantener el sistema sin pedir permiso.
Para cerrar el cĂrculo: en Android, los blobs binarios son el peaje que hoy pagamos para que el hardware funcione, pero tambiĂ©n la frontera que impide auditarlo y repararlo con independencia. Mientras llegan controladores y firmwares abiertos de forma generalizada, la mejor estrategia es informarse, escoger bien el dispositivo y apostar por proyectos con buen historial de seguridad, diferenciando siempre entre el “blob” como binario propietario del kernel y el “blob” como objeto de datos en la nube, dos mundos distintos que comparten nombre pero no significado.
