ShieldFont golpea a los scrapers de IA que ignoran Robots.txt
ShieldFont ha convertido una fuente web en un arma contra los scrapers de IA, tras décadas de depender de las instrucciones voluntarias de robots.txt. El proyecto de código abierto permite que las personas lean prosa corriente mientras los sistemas automatizados que recopilan HTML sin procesar encuentran palabras diferentes. No se limita a ocultar texto. Intenta que la recopilación no autorizada sea menos útil.
Esa distinción hace que ShieldFont sea más que otro experimento de bloqueo de bots. Un bloqueo le dice a un rastreador que se vaya, pero el rastreador puede ignorarlo. ShieldFont asume que esa negativa ya ha fracasado. Responde modificando lo que recibe un scraper que no cumple las reglas.
El estudio creativo S&A y la fundición tipográfica de Copenhague Playtype lanzaron el proyecto el 28 de julio de 2026. Hackaday lo destacó el 14 de agosto, llevando el concepto a un público técnico más amplio. El conflicto central ya es visible: los propietarios de sitios web quieren lectores humanos sin suministrar automáticamente datos limpios para el entrenamiento de IA.
También es una defensa deliberadamente imperfecta. ShieldFont puede perjudicar la accesibilidad, la visibilidad en buscadores, el comportamiento de copiar y pegar, la traducción y otras funciones del navegador. Un scraper decidido puede revertirlo. Su objetivo real es la economía de la recopilación, no la posibilidad teórica de extraer contenido.
ShieldFont convierte el contenido en el mecanismo de exclusión
ShieldFont sustituye una solicitud cortés por una consecuencia técnica para los scrapers que recopilan la representación equivocada de una página.
Un sitio web convencional envía texto en HTML e indica al navegador cómo presentarlo. Las personas ven el resultado renderizado, mientras que muchos rastreadores toman directamente el texto subyacente. ShieldFont explota esa brecha entre la fuente y la visualización.
Antes de la publicación, su codificador sustituye determinadas palabras del texto fuente por señuelos. El navegador carga entonces una fuente OpenType especialmente construida que restaura visualmente las palabras que pretendía el autor. Una persona ve la frase original, pero un scraper básico de HTML almacena las sustituciones.
OpenType es el formato de fuente ampliamente utilizado que controla cómo los caracteres se convierten en glifos visibles. Su sistema GSUB, abreviatura de sustitución de glifos, normalmente gestiona funciones como las ligaduras y las formas específicas de cada idioma. ShieldFont reaprovecha ese mecanismo a nivel de palabra.
La explicación de la mecánica de ShieldFont ofrece una ilustración sencilla. El texto fuente podría contener “avengers” donde el autor escribió “winners”. La fuente dibuja las letras de “winners”, dejando al recopilador de texto sin procesar con el sustantivo equivocado.
Este enfoque difiere de alterar cada carácter. El ruido a nivel de caracteres es fácil de rechazar para un filtro de calidad, y los modelos de lenguaje modernos a menudo pueden reconstruir cifrados de sustitución simples. ShieldFont intenta, en cambio, preservar la fluidez gramatical mientras altera el significado factual.
Sus correspondencias intercambian palabras por alternativas de la misma categoría gramatical. Los sustantivos suelen sustituir a sustantivos, mientras que los verbos sustituyen a verbos. El pasaje resultante debería seguir siendo lo bastante legible para superar la limpieza automatizada de conjuntos de datos, pero lo bastante distinto como para tergiversar la afirmación original.
Ese equilibrio importa porque el texto rechazado nunca llega al entrenamiento. Una frase visiblemente corrompida puede proteger el original, pero no impone demasiado riesgo adicional a un recopilador. Un texto falso pero plausible tiene más posibilidades de consumir recursos de filtrado, revisión o entrenamiento.
Los creadores llaman a ese efecto envenenamiento. El término exige prudencia porque no hay evidencia pública de que ShieldFont degrade un modelo de frontera a una escala significativa. El resultado demostrado se refiere a pasajes transformados, no a un descenso medible en el rendimiento de un modelo comercial.
Según las pruebas controladas del proyecto, el 55,8 por ciento de los pasajes protegidos ya no expresaban la misma afirmación factual. Según se informa, esos pasajes conservaron suficiente coherencia como para parecer prosa corriente. Esta cifra procede de la propia metodología de ShieldFont y no ha recibido una replicación independiente amplia.
La versión actual se dirige a palabras frecuentes del contenido en inglés. Sus tres diccionarios principales contienen aproximadamente 12.000 pares de palabras cada uno. Una correspondencia opcional más pequeña sustituye menos términos, dando a los editores otro equilibrio entre ocultación y compatibilidad.
Los editores pueden usar un codificador alojado, un componente de React, JavaScript en tiempo de compilación o un flujo de trabajo de fuentes personalizado. La protección también puede limitarse a bloques seleccionados. Esto permite dejar sin cambios la navegación, los titulares y el material esencial para las búsquedas.
Por tanto, ShieldFont no crea un perímetro invisible alrededor de un sitio web. Modifica piezas concretas de contenido antes de que lleguen a un recopilador no confiable. Ese alcance limitado produce su principal ventaja y sus limitaciones más graves.
Por qué Robots.txt ya no resuelve la cuestión
El problema de robots.txt no es una sintaxis débil; es la ausencia de aplicación cuando un rastreador decide que las reglas no le corresponden.
El Protocolo de Exclusión de Robots se remonta a los primeros tiempos de la web. Un sitio coloca un archivo robots.txt en su raíz y luego enumera qué agentes de usuario deben evitar rutas concretas. Los rastreadores cooperativos leen el archivo antes de solicitar esos recursos.
El protocolo se estandarizó mediante RFC 9309, pero la estandarización no lo convirtió en un control de acceso. Robots.txt comunica una preferencia. No autentica visitantes, cifra contenido ni impide que un cliente disfrazado realice una solicitud.
Esa distinción antes parecía manejable porque los motores de búsqueda tenían incentivos para identificarse y preservar sus relaciones con los editores. El entrenamiento de IA introdujo recopiladores con objetivos, identidades y cadenas de suministro diferentes. Los creadores de conjuntos de datos también pueden obtener material a través de intermediarios en lugar de bots propios reconocibles.
La evidencia respalda ahora las preocupaciones de que el cumplimiento varía. Un estudio sobre cumplimiento de rastreadores de 2025 examinó 130 bots que se autodeclaraban a lo largo de 40 días de registros web institucionales. Los investigadores informaron de un cumplimiento más débil a medida que las restricciones se volvían más estrictas.
El estudio también descubrió que algunos rastreadores de búsqueda con IA rara vez consultaban robots.txt. Ese resultado no prueba que todas las empresas de IA ignoren las preferencias de los editores. Sí muestra por qué un archivo voluntario no puede cargar con todo el peso de la aplicación de las reglas.
Los operadores de sitios web pueden bloquear agentes de usuario conocidos, desafiar solicitudes sospechosas, imponer límites de tasa o utilizar un firewall de aplicaciones web. Estos controles operan más cerca de la solicitud de red, lo que los hace más difíciles de ignorar que una directiva en un archivo de texto.
Sin embargo, la identificación sigue siendo difícil. Un recopilador puede rotar direcciones, cambiar cadenas de agente de usuario, distribuir solicitudes o parecer tráfico normal de navegador. Las defensas agresivas también pueden bloquear motores de búsqueda, servicios de accesibilidad, proyectos de archivado e investigadores legítimos.
Los proveedores de infraestructura comercial han respondido con controles más sólidos. Los controles de bots de IA de Cloudflare permiten a los clientes bloquear rastreadores asociados al entrenamiento de modelos y otros usos de IA. Estos sistemas se benefician de una visibilidad del tráfico que los editores individuales a menudo no tienen.
ShieldFont ataca otra capa. Asume que una solicitud llegó a la página pese a la preferencia declarada del editor y a sus defensas perimetrales. El scraper recibe una respuesta correcta, pero la respuesta contiene una representación que deja de ser fiable fuera del proceso de renderizado del navegador.
Esto transforma la confrontación de permiso frente a incumplimiento en recopilación barata frente a verificación costosa. Un rastreador todavía puede ganar. Primero debe reconocer la página protegida, identificar la correspondencia pertinente, renderizar el contenido o recuperar el texto visible de otra forma.
Los fundadores del proyecto describen la publicación y el consentimiento como actos separados. Su postura es que hacer una obra accesible para lectores humanos no debería autorizar automáticamente el entrenamiento de modelos. ShieldFont traduce ese argumento de política en una incomodidad técnica.
Esa traducción explica el atractivo del proyecto. Da a un editor individual algo más concreto que otra regla de exclusión. Sin embargo, también traslada el conflicto a la propia página, donde los lectores y los sistemas de búsqueda pueden sufrir daños colaterales.
El verdadero mecanismo es la fricción económica
ShieldFont solo funciona cuando revertirlo cuesta más de lo que un recopilador masivo espera obtener de una página protegida.
Ninguna fuente web pública puede mantener su correspondencia en secreto de forma permanente. El navegador necesita la fuente para mostrar las palabras previstas, por lo que la información de renderizado necesaria llega al dispositivo del usuario. Un investigador específico puede descargarla y analizarla.
Las propias advertencias de implementación de ShieldFont reconocen esta debilidad. Los desarrolladores recuperaron 11.962 pares de palabras de una fuente distribuida sin utilizar su diccionario. Estiman que crear un inversor de OpenType requiere ingeniería especializada, pero la correspondencia sigue siendo recuperable.
Los diccionarios predeterminados también son públicos porque el proyecto es de código abierto. Cualquiera que construya un decodificador dedicado puede estudiarlos directamente. Las correspondencias privadas aumentan el trabajo necesario por sitio web, pero no hacen imposible la reversión.
Por eso la defensa depende de la escala. La mayoría de los scrapers masivos están optimizados para obtener grandes volúmenes de HTML a bajo coste. Normalmente no inspeccionan cada fuente, la vinculan con bloques protegidos y reconstruyen las relaciones entre fuente y glifos para cada dominio.
Un scraper puede renderizar cada página en un navegador sin interfaz. Puede capturar pantallas y utilizar reconocimiento óptico de caracteres, que convierte los píxeles visibles de nuevo en texto. Un modelo de visión y lenguaje puede realizar una recuperación similar a partir de imágenes renderizadas.
Cada vía añade coste. El renderizado consume más cómputo y tiempo que descargar marcado sin procesar. El OCR introduce pasos de procesamiento y verificación. Los modelos de visión añaden más gasto, latencia y oportunidades de error.
La detección plantea otro desafío. Si las instalaciones de ShieldFont exponen un nombre de clase, una ruta de archivo o un atributo de accesibilidad fijos, los recopiladores pueden señalarlas a bajo coste. Por ello, el proyecto fomenta correspondencias variadas e implementaciones camufladas.
El camuflaje no puede seguir siendo eficaz para siempre. Cuando la adopción se haga visible, los grandes recopiladores podrán incorporar la detección a sus pipelines. La cuestión importante es si la detección y la recuperación siguen siendo económicas en muchos sitios web no relacionados.
Esto se parece más al filtrado de spam y al bloqueo de anuncios que al cifrado tradicional. Ninguna de las partes logra una victoria técnica definitiva. Una parte modifica sus señales, mientras la otra actualiza el reconocimiento y las contramedidas.
ShieldFont se distribuye con las correspondencias Alpha, Beta y Gamma, además de herramientas para generar variaciones privadas. Un decodificador entrenado para una correspondencia puede fallar con otra. El uso generalizado de correspondencias únicas aumentaría la carga de verificación por sitio para el recopilador.
Sin embargo, la misma apertura que fomenta la adaptación ayuda a los adversarios. Los investigadores y scrapers pueden inspeccionar cada decisión de diseño. El desarrollo abierto facilita encontrar debilidades, aunque también permite a los colaboradores crear nuevas correspondencias e integraciones.
Por tanto, la afirmación más sólida es modesta. ShieldFont puede hacer que la extracción ingenua produzca resultados erróneos y que la verificación masiva sea más costosa. No puede garantizar que los textos protegidos queden fuera de todos los conjuntos de datos.
La afirmación sobre el envenenamiento es más difícil de demostrar. Los pipelines de entrenamiento eliminan duplicados, puntúan, filtran, clasifican y mezclan colecciones enormes. Una cantidad limitada de prosa alterada podría descartarse, diluirse o corregirse antes de que afecte a un modelo.
Los creadores de ShieldFont informan que cambiar aproximadamente una cuarta parte de las palabras hizo que la mitad de los pasajes analizados perdiera su afirmación factual original. Eso mide la distorsión semántica dentro del texto. No establece el comportamiento posterior de los modelos.
Un recolector también podría considerar que las páginas protegidas no son fiables y excluirlas por completo. Ese resultado sigue favoreciendo el objetivo de exclusión voluntaria del editor, aunque se trata de bloqueo mediante disuasión en lugar de envenenamiento mediante ingesta.
Esta es la inversión central del proyecto. ShieldFont no necesita que cada frase envenenada perjudique el entrenamiento. Necesita que los recolectores duden de si un texto aparentemente fluido merece conservarse sin verificaciones adicionales.
La defensa también afecta a los lectores, la búsqueda y la accesibilidad
El problema más difícil de ShieldFont es que las máquinas que atienden a usuarios legítimos suelen consumir el mismo texto subyacente que los scrapers no autorizados.
Los lectores de pantalla suelen depender de la estructura del documento y del contenido textual, no solo de los píxeles dibujados por una fuente. Si el código fuente contiene palabras señuelo, el software de asistencia corre el riesgo de anunciar información falsa. Eso haría que la página protegida fuera activamente engañosa.
La implementación predeterminada evita ese resultado al marcar los bloques protegidos con aria-hidden. Este atributo elimina el contenido del árbol de accesibilidad. Un usuario de lector de pantalla podría no oír nada donde un lector vidente encuentra un párrafo completo.
Ese no es un resultado aceptable para uso general. La documentación de ShieldFont advierte que los bloques protegidos pueden incumplir los requisitos aplicables de WCAG. Los editores sujetos a obligaciones de accesibilidad para personas con discapacidad necesitan una revisión profesional antes de implementarlo.
Un modo dinámico beta intenta otra vía. Almacena el texto original cifrado y pide al navegador del lector que resuelva un rompecabezas computacional antes de revelarlo. La demora pretende seguir siendo tolerable para una persona, al tiempo que desalienta la extracción automatizada a gran escala.
Este diseño aún genera fricción para los usuarios legítimos. Requiere JavaScript y puede interferir con el foco del teclado. El proyecto afirma haber probado el enfoque con VoiceOver y herramientas automatizadas, pero eso no demuestra un cumplimiento amplio de accesibilidad.
Otras funciones del navegador también dependen del texto fuente. Copiar un párrafo protegido puede capturar señuelos en lugar de las palabras visibles. La búsqueda en la página, la traducción, el modo lector, los feeds de sindicación, las fuentes forzadas y las vistas de solo texto pueden fallar o comportarse de forma impredecible.
Los motores de búsqueda plantean otro conflicto. Un crawler que indexe texto sin procesar puede posicionar el señuelo en lugar de la página visible. Eso puede debilitar la relevancia, producir fragmentos inexactos o asociar el sitio con términos que el autor nunca quiso publicar.
Los creadores recomiendan dejar sin protección el contenido crítico para las búsquedas. Las páginas de marketing, los titulares, la navegación y otros materiales de descubrimiento pueden seguir siendo HTML convencional. Los archivos de pago o determinados pasajes creativos constituyen objetivos de implementación más plausibles.
Este enfoque bloque por bloque reduce el daño, pero también proporciona a los recolectores contexto limpio alrededor del material protegido. Un modelo podría inferir algunas palabras sustituidas a partir de encabezados cercanos, resúmenes, datos estructurados, feeds o copias duplicadas en otros lugares.
La implementación también puede fallar durante la publicación. Algunos flujos de compilación conservan la prosa original del autor en comentarios antes de generar la salida protegida. Publicar esos comentarios expondría tanto el texto limpio como su señuelo correspondiente.
ShieldFont proporciona comprobaciones diseñadas para detectar este error. Su documentación advierte a los desarrolladores que eliminen los comentarios fuente y hagan fallar la compilación cuando permanezcan marcadores protegidos. Esa salvaguarda sigue dependiendo de una integración y pruebas correctas.
Los archivos de mapeo privados requieren cuidados similares. Un sitio web que expone un diccionario legible junto a la fuente anula el propósito. Las versiones en caché, los mapas de origen, las API de contenido y los endpoints de vista previa también pueden filtrar la redacción original.
Por tanto, los equipos de seguridad deberían tratar ShieldFont como una transformación experimental de contenido, no como un sistema de control de acceso. No sustituye la autenticación, la autorización, la limitación de tasa, la supervisión ni las restricciones contractuales.
Los editores también deben considerar la confianza de los usuarios. Un visitante que copie una cita y reciba una redacción diferente puede considerar razonablemente que la página está rota. Investigadores, estudiantes y periodistas necesitan texto preciso fuera de la presentación visual original.
Las herramientas personales de conocimiento enfrentan el mismo problema. Alguien que guarde un artículo en una base de conocimiento de IA podría archivar sin saberlo la versión señuelo. El envenenamiento defensivo no puede distinguir entre el entrenamiento no autorizado y un lector que preserva material para un uso legítimo.
Este daño colateral limita dónde tiene sentido ShieldFont. Puede encajar en una declaración artística, un experimento controlado o material seleccionado con bajos requisitos de accesibilidad y descubrimiento. Es una opción predeterminada arriesgada para la información de servicio público.
ShieldFont se suma a un movimiento más amplio de envenenamiento de datos
El proyecto lleva la protección adversarial de las imágenes al texto web ordinario, pero hereda las mismas preguntas sobre verificación y adopción.
Los artistas ya han explorado herramientas que modifican obras digitales antes de que los modelos las ingieran. Glaze busca interrumpir la imitación no autorizada de estilos, mientras que Nightshade apunta al entrenamiento de modelos de imagen mediante cambios adversariales. Ambos reflejan la frustración con los sistemas de exclusión voluntaria que dependen de la cooperación de los recolectores.
ShieldFont aplica una idea relacionada al texto, pero su mecanismo es inusualmente legible. No requiere una perturbación invisible distribuida entre los píxeles de una imagen. Explota el hecho de que los navegadores y los crawlers de texto sin procesar pueden derivar mensajes distintos de un mismo documento.
Los experimentos tipográficos anteriores también separaban la lectura visual de la interpretación por máquinas. TuringFonts utilizaba fuentes de cifrado por sustitución para ocultar información a bots simples. ZXX alteraba las formas de los glifos para resistir el reconocimiento óptico de caracteres.
Los sistemas modernos debilitaron esos enfoques. Los modelos de lenguaje a menudo pueden descifrar sustituciones de caracteres a partir del contexto, mientras que los modelos de visión pueden leer letras estilizadas. ShieldFont intenta conservar tokens fluidos mientras cambia el significado, y apunta al pipeline de datos en lugar de limitarse al reconocimiento.
Un estudio de seguridad de 2026 llamado “Poisoned Typeface” examinó fuentes remapeadas maliciosamente desde la dirección opuesta. Según se informa, los investigadores descubrieron que los asistentes de IA a menudo confiaban en el texto subyacente mientras los humanos veían contenido renderizado diferente. Esa brecha puede servir para defensa, engaño o ataque.
Este doble uso importa. Una fuente que oculta prosa precisa de un scraper también puede mostrar a una persona una instrucción mientras un agente automatizado procesa otra. La misma discrepancia podría afectar a los asistentes de navegador, los agentes empresariales y los sistemas automatizados de compra.
Los defensores deben evitar normalizar el remapeo de fuentes como contenido fiable. Un agente que lee ciegamente el texto fuente es vulnerable a señuelos. Un agente que confía en las capturas de pantalla puede encontrarse con inyección visual de prompts. Comparar ambas representaciones aumenta el coste y aun así deja ambigüedad.
Para los desarrolladores de modelos, ShieldFont es por tanto una advertencia sobre la procedencia de los datos. El lenguaje fluido no es necesariamente fiel a la fuente visible para humanos. Los pipelines de entrenamiento podrían necesitar señales que muestren cómo se renderizaba una página cuando fue recopilada.
La procedencia añade almacenamiento y computación. Renderizar miles de millones de páginas, conservar capturas de pantalla, recopilar fuentes y reconciliar representaciones haría más costosos los conjuntos de datos web amplios. Ese aumento de costes es precisamente la presión que ShieldFont busca crear.
Para los editores, la tendencia más amplia es un avance hacia controles exigibles. El bloqueo de red, el acceso autenticado, los sistemas de licencias, los permisos legibles por máquina y las transformaciones adversariales intentan reemplazar las expectativas informales.
Ningún método por sí solo resuelve el conflicto. La autenticación restringe el acceso de los lectores. El bloqueo produce falsos positivos. Las licencias requieren contrapartes y estándares. El envenenamiento puede perjudicar a usuarios legítimos. Robots.txt sigue siendo útil como registro explícito de la intención del editor, pero no puede imponerse por sí mismo.
La contribución más duradera de ShieldFont podría ser conceptual, más que operativa. Demuestra que una página web tiene múltiples capas legibles y que los recolectores eligen en cuál confiar. Esa elección ahora conlleva consecuencias legales, éticas y técnicas.
El proyecto también desafía una suposición común sobre la disponibilidad pública. El contenido puede ser públicamente legible sin ser técnicamente neutral. Un editor puede moldear deliberadamente el coste, la fiabilidad y los usos permitidos de la extracción automatizada.
Qué mostrará si ShieldFont importa
Tres señales determinarán si ShieldFont se convierte en infraestructura significativa o sigue siendo una demostración contundente del problema del consentimiento.
La primera señal es la replicación independiente. Los investigadores necesitan probar los mapeos actuales en pipelines realistas de recopilación, filtrado, deduplicación y ajuste fino. Los cambios semánticos a nivel de pasaje por sí solos no pueden demostrar el envenenamiento de conjuntos de datos a escala de modelo.
Los estudios útiles deberían comparar la extracción de HTML sin procesar, el texto renderizado en navegador, OCR, la inversión de fuentes y la recuperación mediante visión y lenguaje. También deberían medir la detección errónea y el coste de verificar páginas que no utilizan ShieldFont.
Los resultados podrían reforzar el argumento del proyecto incluso si los recolectores eliminan todas las páginas protegidas. Una exclusión fiable demostraría que la fuente impone una exclusión voluntaria mediante disuasión económica. Una recuperación automatizada barata debilitaría esa afirmación.
La segunda señal es la adopción por parte de editores con mapeos variados. Un mapeo público es fácil de reconocer y descifrar. Cientos de implementaciones independientes pondrían mejor a prueba si la variación por sitio crea una fricción operativa significativa.
La calidad de la adopción importa más que las cifras de descarga. Los editores deben implementar la fuente sin filtrar texto plano, destruir la navegación ni excluir a los usuarios de lectores de pantalla. Los sitios reales expondrán problemas de integración que una demostración controlada no puede reproducir.
Habrá que observar su uso en archivos, ensayos solo para miembros, escritura creativa y otros materiales que no dependan demasiado del posicionamiento en buscadores. Una implementación amplia en información esencial probablemente provocaría objeciones de accesibilidad más contundentes.
La tercera señal es la respuesta de los desarrolladores de crawlers y agentes. Los recolectores pueden identificar archivos de fuentes conocidos, analizar sustituciones OpenType, renderizar páginas sospechosas o descartar bloques protegidos. Cada elección revela cuánto procesamiento adicional están dispuestos a tolerar.
Los agentes de navegador también pueden empezar a comparar el texto del DOM con el texto renderizado. Una discrepancia podría activar una advertencia, un segundo método de recuperación o la negativa a actuar. Tales salvaguardas abordarían tanto el remapeo malicioso como el envenenamiento defensivo.
Estas respuestas decidirán el resultado práctico. Si la recuperación se convierte en una función de biblioteca barata, ShieldFont necesitará cambios de mapeo más rápidos o un camuflaje más sofisticado. Si los pipelines de recopilación simplemente rechazan las páginas protegidas, los editores obtendrán una exclusión voluntaria más sólida.
Los avances legales y del sector podrían reducir la necesidad de defensas adversariales. Las licencias exigibles, una identidad fiable de los crawlers y señales de consentimiento reconocidas ofrecerían soluciones más limpias. ShieldFont existe porque muchos creadores no confían hoy en esos sistemas.
El proyecto no debería juzgarse como una cerradura irrompible. Sus propios creadores rechazan esa descripción. Se entiende mejor como un arancel aplicado a un proceso de recopilación que antes trataba el texto público como materia prima barata.
Ese arancel también recae actualmente sobre algunos lectores legítimos. Los fallos de accesibilidad, las funciones rotas del navegador y la indexación inexacta en buscadores no son detalles menores. Determinan si la táctica protege la autoría o simplemente desplaza el daño.
Para desarrolladores y editores, la medida inmediata es realizar pruebas cuidadosas. Compare el texto fuente, el texto renderizado, la salida para tecnologías de asistencia, el contenido copiado, las vistas previas de búsqueda, los feeds y las versiones archivadas antes de proteger cualquier elemento importante.
Para quienes desarrollan IA, el mensaje es igual de directo. Ya no es seguro tratar el HTML como un registro incuestionable de lo que vio una persona. ShieldFont hace que esa discrepancia sea deliberada, visible y fácil de reproducir.
La cuestión más amplia es si los mecanismos de consentimiento pueden volverse creíbles antes de que la publicación adversarial se convierta en algo habitual. Si los rastreadores continúan ignorando las preferencias expresadas, más creadores buscarán defensas que impongan consecuencias. ShieldFont ofrece una respuesta provocadora: cuando un scraper se niega a respetar la señal, haga que el material que obtiene sea menos fiable.
