La mayoría de la gente, incluidos muchos desarrolladores de software competentes, concibe un documento digital de la misma manera que concibe una hoja de papel: como un objeto inerte que contiene palabras e imágenes, indiferente a la herramienta que se utilice para abrirlo. Esta intuición es errónea, y las consecuencias de este error lo abarcan todo, desde la dependencia de un proveedor específico hasta la ciberseguridad y la legibilidad a largo plazo de los registros públicos.
Un documento digital no es papel. Es un pieza de software.
El paralelo con el HTML
La forma más clara de verlo es pensar en una página web. Cuando visitas un sitio web, tu navegador recibe un archivo —un documento HTML— y lo ejecuta. Analiza el marcado, aplica reglas de estilo, ejecuta scripts incrustados, obtiene recursos adicionales y ensambla el resultado en algo que puedes leer. La página que ves en la pantalla no es una imagen estática transmitida desde el servidor, es el resultado de un pequeño programa que tu navegador ejecutó en tu nombre.
Nadie discute que un navegador web es software. Sin embargo, el archivo HTML que consume también es, en un sentido significativo, software: un conjunto de instrucciones que describen lo que debe suceder cuando se abre el archivo. Cambia las instrucciones y la página renderizada cambia. Oculta la especificación de cómo deben interpretarse las instrucciones, y solo la parte que posee la especificación puede garantizar una representación fiel.
Vale la pena recordar que la apertura del HTML no fue fruto de la casualidad, y estuvo a punto de perderse. A principios de la década de 2000, Internet Explorer 6 acaparaba alrededor del noventa por ciento del mercado de los navegadores, y Microsoft aprovechó ese dominio para imponer extensiones privativas al HTML, al CSS y al modelo de documentos: etiquetas, comportamientos y filtros no estándar que solo funcionaban en su navegador.
Los desarrolladores web, desesperados por llegar a los usuarios, comenzaron a programar tanto para Internet Explorer como para el estándar, asumiendo ellos mismos el costo de ese doble trabajo, mientras que el proveedor se beneficiaba del bloqueo en cualquier caso. La web abierta no se fragmentó, pero solo porque los desarrolladores absorbieron el costo de mantenerla unida. Si hubieran dejado de hacerlo, el HTML se habría convertido silenciosamente en lo que Microsoft lanzara a continuación.
Se requirió un esfuerzo sostenido por parte del W3C, de navegadores competidores como Firefox y de la comunidad de desarrolladores conscientes de los estándares para devolver la web a terreno abierto. Si ese esfuerzo hubiera fracasado, el HTML hoy no sería un lenguaje compartido, sino un producto de Microsoft. La web sobrevivió porque se defendió el estándar. Los formatos de documentos no siempre han tenido tanta suerte.
Un documento de oficina -un DOCX, un ODT, un PPTX, un PDF- funciona exactamente de la misma manera. Es un archivo estructurado que contiene instrucciones: este texto con esta fuente y este tamaño, esta imagen incrustada aquí, esta tabla con este diseño, este campo recalculado automáticamente, esta macro ejecutada al abrir el documento. Cuando «abres» el documento, una aplicación lee esas instrucciones y las ejecuta. La página que ves en la pantalla es el resultado de un programa -la suite ofimática- que ejecuta las instrucciones contenidas en el documento.
El documento es el código. La suite ofimática es el intérprete. Juntos forman un sistema de software, y el usuario es quien lo ejecuta, por lo general sin darse cuenta.
Por qué esto importa: el bloqueo es una propiedad del software
Una vez que ves un documento como software, la cuestión de los formatos de archivo se convierte en la cuestión de los lenguajes de programación. Un formato de archivo privativo es un lenguaje de programación cuya especificación es propiedad de un único proveedor, quien la controla y puede modificarla a su antojo. Los «programas» escritos en ese lenguaje -tus contratos, tus facturas, tus libros, tus archivos de la administración pública- solo pueden ejecutarse de manera confiable mediante el software que ese proveedor autoriza.
Este es el mecanismo estructural del «lock-in». No se trata de un efecto secundario de los hábitos de los usuarios ni de los costos de capacitación. Es la consecuencia directa de redactar tus documentos en un lenguaje cuya gramática pertenece a otra persona. En el momento en que el proveedor cambie la gramática —y los formatos privativos cambian constantemente, al menos con cada lanzamiento de un nuevo producto, pero a menudo con mayor frecuencia—, tus documentos existentes podrían visualizarse de manera diferente, perder funciones o dejar de abrirse por completo. No eres dueño del lenguaje en el que están escritos tus propios registros.
Los estándares abiertos como ODF existen precisamente para romper esta dependencia. ODF es un formato especificado públicamente y mantenido de forma independiente, cuya gramática no pertenece a ningún proveedor en particular. Cualquier desarrollador puede crear un intérprete fiel. Tus documentos, escritos en un lenguaje abierto, siguen siendo legibles independientemente de lo que decida cualquier empresa en particular.
Por qué esto importa: la superficie de ataque es una propiedad del software
La segunda consecuencia es la seguridad. El software tiene vulnerabilidades, el papel no. En el momento en que admitimos que un documento es software, el extenso catálogo de avisos de seguridad relacionados con OOXML deja de sorprender y se vuelve, de hecho, inevitable.
Los formatos de documentos de Office son tremendamente complejos. El OOXML, en particular, cuenta con miles de páginas de especificaciones, que incluyen lenguajes de macros, objetos OLE incrustados, referencias externas, lógica de formato condicional y una importante capa de compatibilidad con formatos binarios heredados. Cada uno de estos elementos es una puerta de entrada para un atacante. Un documento que llega por correo electrónico y «simplemente se abre» puede ejecutar código oculto, descargar contenido malicioso de Internet, aprovechar debilidades en la forma en que se lee el archivo y, a partir de ahí, tomar el control de la computadora misma. El patrón se repite año tras año, vulnerabilidad tras vulnerabilidad, porque el documento está haciendo lo que hace el software: ejecutarse.
Un formato más simple y especificado con mayor rigor es más difícil de convertir en un arma. Esto no es una garantía -cualquier formato suficientemente expresivo tiene riesgos-, pero el principio se mantiene: la complejidad es amiga del atacante, y la complejidad privativa, nunca documentada por completo para terceros, es la mejor amiga de todas.
Por qué esto importa: la libertad es una propiedad del software
Si un documento digital es software, entonces el marco que aplicamos a la ética del software se aplica a los documentos. La Fundación para el Software Libre define cuatro libertades: la libertad de usar el programa para cualquier propósito, de estudiarlo y modificarlo, de redistribuir copias y de distribuir versiones modificadas. La segunda y la cuarta -Libertad 1 y Libertad 3- requieren acceso al código fuente.
Un documento en un formato privativo viola estas libertades exactamente de la misma manera que lo hace el software privativo. No es posible estudiar a fondo cómo se interpretará, ya que la especificación del formato es secreta, parcial o está sujeta a cambios unilaterales. No se pueden crear ni compartir de manera confiable herramientas modificadas para interpretarlo, porque el propietario del formato se reserva el derecho de declarar que su intérprete no cumple con los requisitos. El «código fuente» del documento -la especificación completa y estable de lo que significan sus instrucciones- no está en sus manos.
Esto no es una metáfora. Es la misma dependencia, estructuralmente, que hace que el software privativo sea inaceptable para cualquier organización que se tome en serio la soberanía digital. El documento, como software, hereda la política del formato en el que está escrito.
La conclusión es inevitable
Un documento digital es un pequeño programa. Se ejecuta cada vez que se abre. El lenguaje en el que está escrito determina quién lo controla, quién puede atacarlo y si sus lectores son libres.
Tratar los documentos como si fueran de papel ha permitido que una generación de responsables políticos, administradores públicos e incluso tecnólogos pasen por alto el hecho de que la elección del formato de un documento es una elección de dependencia de software, y una elección de qué gramática rige nuestro registro escrito. No existe un formato neutral, al igual que no existe un lenguaje de programación neutral. Solo hay formatos cuyas especificaciones son abiertas, estables y gobernadas colectivamente, y formatos que no lo son.
Hemos aprendido, poco a poco y a costa de un alto precio, a exigir transparencia en nuestro software. El documento es software. La exigencia es la misma.
