Visita judicial a la inyección SQL

• El amplio principio de divulgación de la FOIA de Illinois fue puesto a prueba ante un esquema de base de datos de una entidad pública, y la solicitud de la base de datos de multas de estacionamiento CANVAS de Chicago derivó en una demanda y en un debate legislativo
• La FOIA garantiza con fuerza la divulgación de información existente, pero no puede obligar a crear nuevos registros, por lo que mientras más datos estén dentro de aplicaciones, más importante se vuelve el esquema que indica qué consultas pueden pedirse
• Chicago se opuso alegando que el esquema de CANVAS amenazaba la seguridad, y el punto central del juicio fue si divulgar el esquema realmente hacía posible o facilitaba un ataque de SQL Injection
• En primera instancia y en apelación ganó la parte a favor de la divulgación, pero la Illinois Supreme Court consideró que el file layout es exento por sí mismo y que un esquema SQL entra en esa categoría
• Actualmente las entidades públicas de Illinois pueden negarse a divulgar esquemas de bases de datos, y la SB0226 busca obligarlas a proporcionar una descripción de la estructura de la base de datos para que el solicitante pueda pedir consultas específicas

---

El problema con el que chocó la FOIA de Illinois frente a las bases de datos

• La FOIA de Illinois trata en principio la información recopilada por las entidades públicas como propiedad pública, con excepciones limitadas
  • Por lo general, al solicitante no se le cobran costos
  • Las entidades públicas no pueden limitar fácilmente la cantidad de solicitudes
  • El plazo de respuesta es de 5 días por defecto, y puede ampliarse 5 días más con una solicitud escrita de extensión
  • Si se demanda una negativa indebida, es posible recuperar honorarios de abogado
• La gran limitación es que la FOIA no puede obligar a una entidad pública a crear nuevos registros
  • Si el informe deseado ya existe, puede solicitarse
  • Si no existe, hay que pedir los datos en bruto y armarlos por cuenta propia
• A medida que la información pública está cada vez menos en archivadores, unidades compartidas o documentos de Word, y más en aplicaciones especializadas y bases de datos, el valor del esquema aumenta
• Un esquema de base de datos es la estructura que contiene los nombres de varias tablas y los nombres de las columnas de cada tabla
  • En el artículo se compara con un archivo de Excel con varias pestañas
  • El nombre de cada pestaña y la fila de encabezados de cada pestaña equivalen al esquema

La solicitud de Matt Chapman por el esquema de CANVAS

• Matt Chapman es presentado como un civic hacker que hace periodismo de datos aprovechando solicitudes FOIA a gran escala
• En el proceso de trabajar con datos de multas de estacionamiento de Chicago apareció el sistema CANVAS
  • CANVAS es el repositorio central que contiene todos los datos de multas de estacionamiento de Chicago
  • Matt Chapman solicitó por FOIA el esquema para entender qué había dentro de la base de datos CANVAS
• Chicago rechazó la solicitud basándose en la excepción de la FOIA de Illinois relacionada con el procesamiento automatizado de datos
  • Esa disposición incluye software, protocolos operativos, resúmenes de programas, file layouts, listas de fuentes, módulos, guías de usuario, documentos de diseño lógico y físico, y manuales del personal
  • También enumera como excepción la información cuya divulgación pudiera amenazar la seguridad del sistema o de los datos
• Chicago llamó a Matt Chapman “hacker” y sostuvo que el esquema de CANVAS podría representar un riesgo para la ciudad si caía en manos equivocadas

El punto técnico central en tribunales: SQL Injection

• La pregunta central del juicio fue si divulgar el esquema de CANVAS hacía posible un ataque de SQL Injection
• SQL es el lenguaje que muchos programas usan para hablar con bases de datos, y SQL Injection es una vulnerabilidad de seguridad que puede aparecer en programas que usan SQL
• SQL Injection ocurre cuando la entrada del usuario se inserta incorrectamente en una plantilla de consulta SQL dentro del código de la aplicación
  • Como ejemplo, en una consulta donde el nombre va entre comillas, una entrada como Bob O’Connor que incluye una comilla puede confundir la interpretación que hace la base de datos
  • Un atacante puede aprovechar esos puntos de entrada para hacer que el resto de la entrada se ejecute como si fuera código
• El CISO de Chicago, Bruce Coffing, sostuvo que divulgar el esquema ayuda a un atacante de tres maneras
  • Le permite encontrar vulnerabilidades
  • Le permite explorar vulnerabilidades con mayor sigilo
  • Le permite elegir aplicaciones que valga la pena atacar
• La postura contraria se centró en que el esquema no es el lugar donde se encuentran vulnerabilidades de SQL Injection
  • Las vulnerabilidades de SQL Injection se encuentran en las plantillas de consultas SQL del código fuente de la aplicación, no en el esquema de la base de datos
  • Lo solicitado no era el código fuente, sino un esquema más cercano a la fila de encabezados de unas tablas
  • Un atacante puede recuperar el esquema mediante SQL Injection, por lo que el esquema se parece más al resultado del ataque que a un requisito previo para él

El criterio en primera instancia y en apelación

• En primera instancia ganó la parte de Matt Chapman
  • Chicago apeló de inmediato y Matt Chapman no recibió el esquema de CANVAS
• La corte de apelación abordó las cuestiones jurídicas bajo la premisa de que la instancia inferior es la principal encargada de determinar los hechos
• El riesgo derivado de la divulgación se discutió bajo el estándar de “would jeopardize”
  • “could” significa un nivel en el que puede imaginarse que algo ocurra
  • El estándar jurídico de “would” fue explicado como evidencia clara de daño que no deje dudas razonables al juez
  • La apelación se inclinó por exigir una probabilidad muy alta de daño
• La apelación analizó si la frase limitante de la excepción aplicaba solo a “any other information” o a todo el bloque de “Administrative or technical information” de la excepción
  • Si aplicaba solo a “any other information”, entonces los file layouts y elementos similares quedarían exentos por sí mismos
  • Si aplicaba a toda la excepción, bastaría la determinación de hecho de que la divulgación no amenazaba la seguridad para que ganara la parte de Matt Chapman
• La apelación concluyó que la frase limitante aplicaba a toda la excepción y falló a favor de Matt Chapman

La conclusión revertida en la Illinois Supreme Court

• Chicago volvió a apelar y el caso llegó a la Illinois Supreme Court
• La Illinois Supreme Court interpretó la excepción de la FOIA de manera distinta a la corte de apelación
  • La frase limitante aplica solo a “any other information”
  • Los demás elementos están exentos por sí mismos
• Con esa interpretación, la cuestión decisiva pasó a ser si un SQL schema es un file layout
• Surgió el contraargumento de que un esquema y un file layout son técnicamente distintos
  • El mismo SQL schema puede usarse en varios motores de base de datos
  • Cada motor de base de datos administra los datos resultantes con un underlying file layout distinto
  • El McGraw-Hill Dictionary of Scientific & Technical Terms, 6E define file layout como “descripción de la disposición de los datos dentro de un archivo”
  • Un SQL schema se parece más a una abstracción diseñada para no tener que pensar en la disposición real de los datos
• La Illinois Supreme Court también usó la definición de schema del Merriam-Webster Online Dictionary: “structured framework or plan: outline”
  • El tribunal concluyó que la diferencia era solo de nombre
  • En consecuencia, el esquema fue tratado como un file layout y la parte de Matt Chapman perdió

Situación actual y SB0226

• Actualmente las entidades públicas de Illinois pueden negarse a divulgar esquemas de bases de datos
• Mientras más datos se trasladan a aplicaciones especializadas, más frecuente es la situación en la que para acceder a datos básicos hay que pedir por FOIA que se ejecute una consulta de base de datos
• Sigue en pie el problema de que las bases de datos no deberían convertirse en una zona segura para que los gobiernos locales eviten divulgar información pública
• SB0226 busca añadir texto a la ley FOIA para obligar a las entidades públicas a proporcionar una explicación suficiente de la estructura de toda base de datos que administren
  • El objetivo es permitir que el solicitante pida a la entidad pública que ejecute consultas específicas de base de datos
• Este proyecto de ley coincide en buena medida con la línea de trabajo con la que Matt Chapman ha seguido impulsando este tema

[GN⁺]

Comentarios de Hacker News

• Soy el demandante en esta demanda. Todavía estoy escribiendo un texto complementario para acompañar el artículo de tptacek, que estará listo pronto; mientras tanto, pueden hacer preguntas aquí.
  Mientras esperan, también pueden revisar este artículo anterior: https://mchap.io/that-time-the-city-of-seattle-accidentally-...

  • Matt está haciendo un trabajo realmente necesario.
    Pero hay que recordar que Matt, aun con el apoyo de Loevy and Loevy, abogados de derechos civiles de primer nivel nacional, técnicamente perdió. Eso muestra lo absurdamente difícil que es pelear contra el ayuntamiento, y hacerlo sin abogado es todavía peor.
    Lo que juega a nuestro favor es cambiar la ley, como se propone en el artículo. Si la Corte Suprema estatal dicta sentencia, sin una reforma se acabó, e Illinois tiene historial de modificar con frecuencia su ley FOIA. Aunque algunas de esas modificaciones también fueron en la dirección de reforzar más la no divulgación de información, no de ampliar la transparencia.
    Otro cambio necesario es imponer sanciones fuertes a las instituciones que pierden este tipo de peleas. En Illinois, eso queda limitado más o menos a una multa civil de 5000 dólares contra la institución. Ni siquiera está claramente definido qué es una multa civil; antes se le entregaba al demandante, pero en casos que litigé después simplemente hicieron que el dinero fuera al condado. Como dijo un fiscal estatal: “no importa si pierdo, simplemente me hago un cheque a mí mismo”.
    Por último, hay que tener cuidado con lo que se pide en una demanda. Puede salir un fallo de apelación como este y convertir en ley exactamente aquello contra lo que estabas peleando. No es culpa de nadie, pero pasa. Yo mismo obtuve una vez un fallo absurdo que, en vez de reforzar los derechos de las personas encarceladas, los eliminó.
  • Me cuesta entender el argumento de que conocer los nombres de las columnas no ayuda a un atacante. Si una base de datos no permite comodines, ¿no facilita mucho más saber que se puede hacer '); SELECT col FROM logins que tener que adivinar el nombre de la columna?
    Tampoco es fácil oponerse al criterio del tribunal sobre el esquema y la disposición de archivos. El esquema no es la disposición de archivos en sí, pero es similar: indica cómo se ubican los “archivos” (registros) dentro del “sistema de archivos” (tablas de la base de datos). Por ejemplo, la desnormalización se parece muchísimo a poner datos inline dentro de un registro de archivo. También es una idea bien conocida que un sistema de archivos es, en la práctica, una base de datos. Me pregunto cómo se puede sostener que no son similares.
  • Me pregunto si sería posible una solicitud como “una fila de cada tabla de la base de datos CANVAS”.
  • Es admirable que hayas resistido esta pelea. La transparencia solo se consigue cuando la gente no se conforma.
    Me pregunto cuál ves como el siguiente paso.
  • ¿Qué estarán ocultando los administradores de CANVAS?

• Creo que la ciudad debería compartir el esquema y que, en la práctica, está defendiendo la seguridad por oscuridad, pero no estoy de acuerdo con la premisa central del artículo: “conocer el esquema SQL no ayuda a un atacante”.
  Entendí el argumento del artículo así: “los atacantes recuperan el esquema SQL mediante ataques de inyección SQL. El esquema no es un requisito previo del ataque, sino un producto del ataque”. Eso parece implicar que, si se encuentra una vulnerabilidad, de todos modos se puede recuperar el esquema, pero no siempre es así. Algunas inyecciones SQL solo pueden obtener parte de los datos de la tabla consultada en ese momento, y no otras tablas como information_schema. Si la señal que se obtiene de la vulnerabilidad es solo “la consulta falló” o “la consulta tuvo éxito y devolvió datos”, conocer el esquema vuelve mucho más fácil explotarla.
  Si las consultas fallidas a la base de datos se registran por separado, es probable que las inyecciones que puede encontrar un ataque funcionando 24 horas al día ya se hayan parcheado. Entonces los logs podrían no llenarse de ruido hasta que se descubra un punto real de inyección, por ejemplo una vulnerabilidad que solo existe para usuarios con sesión iniciada y que los bots no pueden encontrar; en ese caso habría tiempo para detectarla y corregirla antes de que el atacante descubra cómo aprovecharla de verdad.
  Conocer el esquema no solo acelera la explotación de una vulnerabilidad, sino que también aumenta la posibilidad de explorar una inyección desde el inicio sin provocar fallas en las consultas.

  • Si el criterio es que “conocer el esquema SQL no ayuda a un atacante”, entonces saber el nombre del servicio también ayuda a un atacante, saber los nombres de los funcionarios del ayuntamiento también ayuda, y saber qué es legalmente una multa de estacionamiento también ayuda. Si alguien quiere hackear al gobierno después de ser demandado, conocer los detalles de su propia demanda también ayuda al ataque.
    El criterio no debería ser “censurar toda información útil”, sino “no publicar código que revele contraseñas o backdoors”. El esquema no puede entrar en esa categoría.
  • No soy atacante, sino un desarrollador de software común, pero si hay inyección SQL, para mí prácticamente todo está terminado en lo que respecta al esquema.
    Aun así, he trabajado con aplicaciones reales en las que conocer el esquema ayudaba a filtrar datos incluso sin una inyección completa. El ejemplo más obvio es cuando se construyen consultas con base en parámetros de URL, pero esos parámetros no se restringen a una lista de permitidos.
    Así que estoy de acuerdo en que el esquema puede darles cierta ventaja a los atacantes.
  • Me recuerda que la vulnerabilidad descubierta recientemente de “filtración de emails vía YouTube” también empezó, en esencia, leyendo algo que podría considerarse esquema.
    https://brutecat.com/articles/leaking-youtube-emails
  • Si registras por separado las consultas fallidas a la base de datos, y ese “fallo” significa “señal de inyección SQL”, entonces nada de lo que se pueda hacer con el esquema reduce esa señal. Un solo error de sintaxis SQL ya merece seguimiento.
    Por eso creo que ese razonamiento no se sostiene.
  • La inyección SQL ciega es un tipo en el que no se producen errores, pero se distingue el éxito del fracaso mediante señales sutiles. El caso más interesante que conozco fue uno en el que la respuesta aparentemente normal de una inyección exitosa era 1 byte más larga que la de una inyección fallida; con eso no solo se averiguó el esquema, sino que se extrajo por completo toda la base de datos.
    En los logs del servidor no había nada que indicara un error.
    La mayoría de los ejercicios relativamente introductorios de inyección SQL que enseñé también se hacían sin conocer el esquema. Por eso la inyección SQL es tan astuta y peligrosa.

• Kurt publicó esto para trollearme. Conviene saber que el público original eran en su mayoría personas no técnicas involucradas en la política municipal de mi zona, Chicagoland.
  A modo de anuncio de servicio público sobre política local: involucrarse en la política nacional es tan sombrío y desalentador como ser un insecto volador estrellándose contra los vidrios de un rascacielos. En cambio, la política local responde muchísimo. Con mi tiempo libre y casi sin costo logré resultados reales, e incluso conseguí que se aprobara una ley. Es radicalmente distinto de la política nacional.
  Lo sorprendente en muchas zonas es que la política local gira en torno a foros. Puede que esos foros no sean donde uno quisiera estar, y en particular abundan los Facebook Groups, pero hay que aguantarse. Si disfrutas participar en comunidades como HN, puedes participar en política, y solo con actividad en foros puedes lograr que las cosas salgan adelante.

  • También influye mucho vivir en un país donde los gobiernos locales tienen facultades para crear leyes. En muchos otros países no es así o, más precisamente, sus facultades legislativas son extremadamente limitadas.
    De hecho, incluso dentro de EE. UU. esto pasa mucho. Solo los gobiernos locales con facultades de home rule pueden dictar ordenanzas sobre cualquier tema siempre que no entren en conflicto con leyes estatales o federales; los demás gobiernos locales solo pueden legislar sobre temas específicos que la legislatura estatal les haya permitido. Algunos estados otorgan home rule a todos los condados y municipios, otros no se la dan a ninguno, y otros solo a algunos. Por ejemplo, en Texas un municipio puede obtener facultades de home rule si alcanza los 5000 habitantes y luego recibe la aprobación de los votantes.
  • Me da curiosidad si puedes explicar más cuál fue la ley que ayudaste a aprobar.
    También me pregunto si podrías compartir enlaces a buenos recursos, en Facebook o en otro lugar, para alguien que quiera involucrarse más en la política de Chicago. Busqué antes, pero con resultados muy limitados.
  • “Nunca dudes de que un pequeño grupo de ciudadanos reflexivos y comprometidos puede cambiar el mundo. De hecho, es lo único que lo ha logrado.” - Margaret Mead
  • Me pregunto cómo se encuentran esos foros.
  • Me acordé de los esfuerzos que tú y Maciej hicieron antes para distribuir llaves FIDO entre el personal de campañas electorales, y fue realmente deprimente.

• ¿No es absurdo que la Corte Suprema y la corte de apelaciones se hayan dividido por un tema de estructura de la oración? Dejando de lado que sea algo común, personalmente me parece disparatado interpretar algo como “toda disposición de archivos y demás elementos también aplica, pero esos demás elementos solo si son malos”. Es raro vivir en una realidad donde aceptamos que el texto de una ley quede completamente ambiguo.
  Sé que esa ambigüedad favorece a los tribunales, porque les da discrecionalidad, y también sé que, pese a intentos valientes, no se puede convertir el texto legal en un lenguaje “formalmente completo”. Sé que el derecho es un desastre y que lo escriben humanos ingenuos y propensos a errores.
  Aun así, si la estructura básica de las oraciones en una ley no resulta clara ni siquiera para los tribunales, ¿no falló todo el sistema en el primer filtro?

  • No soy abogado, pero entiendo que así es como funciona el sistema judicial. El lenguaje está lleno de ambigüedades, por lo que personas razonables pueden diferir sobre qué significa exactamente una oración compleja. Ha habido disputas sobre qué dice exactamente la Constitución de EE. UU. desde el día en que fue redactada, y todavía hay muchos desacuerdos.
    La respuesta habitual es que las leyes deberían redactarse sin ambigüedades, pero eso es más fácil decirlo que hacerlo. Además, a veces los propios legisladores tampoco logran ponerse completamente de acuerdo, así que dejan deliberadamente algunas frases ambiguas para que los tribunales las interpreten.
  • Este tipo de disputas se siente justamente como la razón de que existan varios niveles de tribunales de apelación. Lo de “formato de archivo” fue realmente tonto y mal juzgado, pero la interpretación legal de “si se divulga” parece necesitar una decisión final y coherente.

• ¿Soy el único a quien le desconcierta y preocupa un poco que la excepción para código fuente haya entrado de lleno?
  Es fácil imaginar un escenario en el que la ciudad desarrolla internamente cierto software y oculta en el código fuente “sesgos” u otros elementos que no quisiera que se vieran.
  Ni siquiera tendría que construirlo todo desde cero. Bastaría con parchear y usar componentes de terceros con licencias permisivas.
  En mi opinión, la enmienda propuesta no llega lo suficientemente lejos.

  • No me parece sorprendente.
    Es el mismo problema que enfrentan quienes intentan convertir un proyecto cerrado en open source. Hay código propietario bloqueado por todas partes, donde los desarrolladores y clientes solo tienen derecho a usarlo, no a compartir el código fuente.
    Incluso proyectos creados desde el inicio con una fuerte orientación abierta y sin intereses comerciales directos, como los de contratistas gubernamentales, pueden sufrir este problema. Son bien conocidos los problemas que enfrenta el kernel de Linux al dar soporte a ZFS o a drivers de blob binario en kernel/espacio de usuario[1].
    Paradójicamente, por un lado la información quiere ser libre, y económicamente el software open source terminará desplazando con el tiempo a sus competidores cerrados. Pero convertir un proyecto en open source en sí mismo es caro y a veces tan inmanejable que impide publicar herramientas antiguas aunque los administradores y las empresas quieran hacerlo. Solo involucrar al equipo legal y encontrar a los titulares de derechos de cada componente alcanza para que la mayoría de los administradores se rindan.
    Si el gobierno exigiera en sus contratos que los proveedores usen únicamente componentes open source en todo el árbol de dependencias, el costo podría subir mucho. Muchas dependencias no tienen reemplazos open source equivalentes, o las alternativas cerradas tienen funcionalidades que faltan y haría falta presupuesto para cubrirlas. En el corto plazo ningún concejo aceptaría esos costos adicionales, pero en el largo plazo el público se beneficiaría.
    [1] Es cierto que el problema del kernel es en gran medida función de la GPL. Con licencias más permisivas como Apache 2 o MIT no habría habido esos problemas, y las variantes BSD tampoco tuvieron dificultades con el soporte de ZFS. Sin embargo, la postura de que las aplicaciones públicas, por principio, deberían ser open source por parte del gobierno está más cerca de la GPL que de MIT en términos de licenciamiento. De lo contrario, un proveedor podría traer las partes realmente importantes como código de blob binario “vendorizado” y dejar solo un esqueleto sin significado en los componentes publicados para cumplir el requisito.
  • En teoría, la decisión misma de incluir ese sesgo en el código debería ser información pública. Se podría solicitar bajo qué criterios se creó el software; lo único que no se podría solicitar sería el software en sí.
    Dicho eso, una sentencia así puede tener un efecto inhibidor.
  • Por eso es importante impulsar iniciativas como dinero público - open source, que algunos países de la UE quieren promover.
    Según recuerdo, la anterior coalición de gobierno alemana, que ahora fracasó, lo había incluido en sus promesas, pero no logró implementarlo. Quizá el nuevo gobierno sí lo haga.

• Es un texto muy interesante
  Parece absurdo considerar la publicación del esquema como algo que debe protegerse. Si es como se describe, se vuelve posible un resultado casi mágico, como “como está dentro de la base de datos, no se puede saber nada, y si no puedes decir cómo encontrarlo, estás perdido”.
  Desde mi posición trabajando en una empresa pequeña con muchos clientes, no querría entregar tal cual el esquema de la base de datos, pero aun así me esfuerzo por encontrar y proporcionar los datos que el cliente quiere; no me niego.

  • Que una empresa privada no quiera revelar el esquema de la base de datos se debe a que a un competidor le beneficia ver cómo trabaja la empresa. Esa lógica no aplica a una base de datos gubernamental.

• Para el proyecto cleartap.com solicité vía FOIA más de un millón de páginas de documentación de bases de datos de calidad del agua de Estados Unidos.
  La mayoría de los estados solo cobraron una suma pequeña por recopilar los documentos.
  Michigan pidió 50.000 dólares por la solicitud FOIA. Creo que fue por la crisis de contaminación con plomo en Flint. Me parece que intentaban hacer que desistiera.

  • Vi que había datos de Flint, y me pregunto si realmente pagó ese dinero. O si existe algún proceso de apelación cuando te dan una estimación injustamente alta.
    El proyecto es excelente.

• “Obtén todos los datos de multas de estacionamiento emitidas a Bob O, y también trae toda la información restante de la base de datos y las contraseñas de todos”.
  Este es un ejemplo de inyección SQL escrito en inglés llano, pero aquí “everyone's” también es problemático porque genera una comilla simple huérfana. Si “Bob O'Conner” es malo, “everyone's” también lo es.

• “El código fuente de los programas que ejecutan tampoco suele poder solicitarse mediante FOIA”.
  Lamentablemente, creo que esa parte debería ser ilegal bajo FOIA.
  El código fuente debería ser open source y verificable. Si queda como excepción a FOIA, se elude la confianza pública en el uso de software por parte del gobierno.
  Me pregunto dónde y cómo han fallado ya los tribunales sobre asuntos como este.

  • Aun cuando haya un argumento fuerte de interés público, creo que la tendencia de las agencias gubernamentales a prohibir de forma general la publicación del código fuente se debe principalmente a las mismas razones que en las empresas. Es decir, es demasiado probable que información sensible como contraseñas, tokens o direcciones IP esté hardcodeada en código que está muy lejos de seguir la orientación de una app de 12 factores, y si esa información sensible se filtra, los problemas de seguridad y responsabilidad son enormes.
    En la práctica, también puede haber lógica de negocio que una agencia gubernamental quiera mantener en secreto y que legalmente esté permitida. Si se trata de la base de datos de multas de estacionamiento del artículo original, el código fuente del software que se comunica con esa base de datos podría contener la lógica que elige cuándo y dónde los agentes de tránsito harán operativos “aleatorios” intensivos.

• Cosas como esta me quitaron las ganas de ir a la facultad de derecho. Una parte considerable de los litigios parece teatro kabuki, y no una retórica para llegar a un resultado justo o lógico, sino una retórica para darle a alguien con autoridad un pretexto para tomar una decisión que ya quería tomar desde antes del juicio.

  • Este caso también suena así. Lo que me llamó especialmente la atención fue la parte en que califican la expresión “solo tiene un poco de valor” como una “cobertura egocéntrica de foro”. En realidad, esa expresión también es simplemente precisa, pero el autor parece concluir que no debió haberla dicho porque la palabra “un poco” y la explicación larga no eran tan útiles retóricamente como decir simplemente “no tiene”.
    Alguien podría configurar legalmente algo parecido a un firewall web que revise palabras clave como information_schema en las solicitudes HTTP entrantes y sus variantes codificadas. Eso siempre es un intento de hackeo, así que se puede bloquear. Si ya conoces el esquema, puedes construir las consultas sin tener que superar primero esa restricción. ¿Es probable que esto sea una barrera seria? No. ¿Tiene algo que ver con el egocentrismo? No lo parece.
    Decir que tiene un valor mínimo solo en el sentido de “periférico”, es decir, que no es central ni lo bastante importante como para discutirlo, parece correcto. Pero al decir solo la verdad, la contraparte lo amplifica para intentar convencer al tribunal: “miren, incluso el experto del otro lado dice que tiene valor”. Por eso concluye que el experto simplemente debió haber dicho “no tiene valor”. Yo creo que esa afirmación sería falsa, pero tan mínimamente falsa que sería difícil demostrar que la otra parte no tiene toda la razón. Al final, una formulación menos precisa resulta más ventajosa en este tribunal, y la retórica se vuelve tan importante como el papel del experto.