La presunción de que las computadoras funcionan correctamente
(emptycity.substack.com)- El escándalo de las acusaciones del Post Office Horizon en el Reino Unido es un caso de error judicial masivo en la Gran Bretaña moderna, y muestra no solo fallas individuales y organizacionales, sino también el papel que desempeñaron la ley y los procedimientos judiciales
- Los tribunales presumen que, si no hay pruebas en contrario, un dispositivo mecánico funcionaba correctamente, y este punto de partida también se aplica a los registros informáticos
- Bajo esta presunción probatoria, hechos como faltantes contables pueden considerarse probados solo con registros informáticos, lo que deja al acusado en la posición de tener que demostrar el error
- La Section 69 de la Police and Criminal Evidence Act de 1984 establecía la regla opuesta: la fiscalía debía demostrar el funcionamiento correcto de la computadora, pero fue derogada en 1999
- Si la Section 69 hubiera seguido vigente, la forma en que avanzaron las acusaciones del Post Office podría haber sido distinta; tras su derogación, la carga volvió a recaer sobre los acusados
El escándalo del Post Office Horizon y la responsabilidad de los procedimientos legales
- El Post Office prosecutions scandal es considerado uno de los mayores casos de error judicial masivo en la Gran Bretaña moderna
- El caso combina fallas personales e institucionales, y la documentación legal y las pruebas son tan extensas que resulta difícil comprenderlo en su totalidad
- La sentencia clave de 2019 del juez Mr Justice Fraser consta de más de 1,000 párrafos incluso sin contar los apéndices
- El libro relacionado de Nick Wallis y la investigación judicial rastrean cómo ocurrieron los hechos y qué medidas podrían evitar que se repitan
- Muchos análisis se enfocan en las fallas de la gerencia del Post Office, sus abogados y el proveedor de software Fujitsu
- Sin embargo, la ley y los procedimientos aplicados también fueron parte del caso, y la responsabilidad no se atenúa por el hecho de que quienes tomaban decisiones supieran, o debieran haber sabido, que podían operar con dureza contra los acusados
La presunción probatoria de que “las computadoras funcionan correctamente”
- Lo que los abogados llaman presunción (presumption) es un mecanismo por el cual un tribunal acepta cierto estado de cosas como valor predeterminado cuando no hay pruebas en contrario
- La formulación clásica dice que “si no hay pruebas en contrario, el tribunal presume que un dispositivo mecánico estaba en condiciones normales en el momento relevante”
- En este caso, dispositivo mecánico incluye también a las computadoras
- Esta presunción no significa que el tribunal deba creer en las computadoras en todas las circunstancias, sino que es un punto de partida que puede ser refutado con pruebas
- Mientras no se pruebe el estado contrario, el tribunal puede aceptar ese estado como un hecho
Por qué se necesitan las presunciones y cuál es el riesgo
- El uso de presunciones por parte de los tribunales no es un problema en sí mismo; sin ellas, muchos casos serían difíciles de manejar en la práctica
- Las presunciones acotan los asuntos en disputa a un rango manejable
- Un contrato puede considerarse no fraudulento mientras no se pruebe que es un documento falso
- Un acusado puede ser tratado como no demente mientras no se pruebe demencia
- Lo central es qué estado se convierte en valor predeterminado y qué parte debe romper ese valor predeterminado
- Si el contenido de la presunción es poco realista o las condiciones para refutarla son demasiado difíciles, la presunción deja de ser una herramienta que ayuda a la justicia y se convierte en un mecanismo que produce errores judiciales
La estructura en la que los registros informáticos se vuelven la premisa de culpabilidad
- La regla que considera que una computadora funciona correctamente es una presunción probatoria
- Si no hay pruebas de que la computadora no funcionaba bien, el tribunal puede considerar que los hechos relevantes quedaron probados solo con los registros informáticos
- Por ejemplo, si los registros informáticos muestran un faltante financiero de un director o una empleada de una sucursal postal, el tribunal puede aceptarlos como prueba de un faltante real
- Para cuestionar esa premisa, el acusado debe demostrar que la computadora no funcionaba correctamente
- Cuando la prueba central de la acusación son los registros informáticos, la estructura termina siendo “computer says guilty”
Introducción y derogación de la Section 69
- Esta presunción probatoria no siempre operó en la misma dirección
- La Police and Criminal Evidence Act 1984 Section 69, promulgada en 1984, invirtió la dirección de la presunción
- Bajo la Section 69, no era el acusado quien debía demostrar un error informático, sino que la fiscalía debía demostrar el funcionamiento correcto de la computadora
- Esta disposición sustituyó la postura previa del common law según la cual “si no hay pruebas en contrario, se presume que un dispositivo mecánico estaba en condiciones normales”
- Si la Section 69 hubiera seguido vigente cuando el Post Office acusó a directores y empleadas de sucursales postales, el desarrollo de los casos podría haber sido distinto
- La Section 69 fue derogada en 1999, y volvió la presunción previa del common law
- Desde entonces, la estructura ya no exige que el fiscal demuestre primero el funcionamiento correcto de la computadora, sino que el acusado demuestre que la computadora no funcionaba correctamente
- Cómo se derogó la Section 69 y si las razones fueron válidas queda como tema para el siguiente artículo
1 comentarios
Opiniones de Hacker News
La impresión que me quedó la última vez que revisé el escándalo de Post Office fue que decir “confiamos demasiado en el sistema de TI” sonaba más bien a una excusa conveniente.
Los de arriba sabían bien del problema y parecían haber seguido adelante, aun sabiendo que estaban procesando a personas inocentes, para tapar sus propios fracasos. Si es así, hace falta una pena de prisión considerable. Obstruir la justicia no es un delito menor, y además hay sospechas de que Paula Vennells mintió deliberadamente ante el Parlamento.
Por eso, el directorio de Post Office tenía una barrera psicológica que, por racismo, le impedía conectar las pistas; y, aun después de enfrentarse a pruebas abrumadoras de cientos de condenas falsas, su falta de moral hizo que se aferrara todavía más. También es una triste historia de fracaso tecnológico, pero además es una acusación contra la cultura de los directorios británicos. La revista Private Eye lleva más de 10 años cubriendo esta catástrofe.
¿No sería más correcto argumentar que hay que eliminar estructuralmente ese poder?
Después de pasarme la vida corrigiendo bugs, a menudo me sorprende que los sistemas informáticos funcionen überhaupt.
Me pasó algo personalmente parecido al sistema fallido de Post Office: aunque presentara pruebas, todos se negaban a aceptar la posibilidad de que el sistema informático estuviera equivocado. Era porque meterse a entenderlo daba demasiada lata.
Como he visto cómo se construye el software, no entiendo cómo puede funcionar todo. Mi respuesta a esta paradoja es que, en realidad, no todo funciona. Nos hemos entrenado para aceptar las cosas que no funcionan como si fueran otra cosa. La gente ve a los sistemas informáticos como seres omnipotentes e infalibles, o, por el contrario, los trata como chivos expiatorios.
Por ejemplo, al usar en los últimos dos años los sitios web de aerolíneas como TAP, Vueling y KLM, me encontré con frecuencia con bugs que impedían reservar boletos o iniciar sesión en la cuenta, y diría que fallaban más veces de las que funcionaban. Instagram y Google han desactivado cuentas automáticamente sin mayor motivo; en Instagram me pasó 3 veces en dos meses y terminé rindiéndome y dejando de usarlo. Sobre Skype, si lo usas no hace falta explicar nada, y Teams falla de maneras sorprendentes por más “actualizaciones” que le hagan: el botón de silencio no silencia realmente, al escribir en el chat se invierte el orden de las letras de una frase, o durante una llamada se cierra de repente y deja de responder. Esta pérdida de productividad debe ser considerable a nivel mundial, y es posible que el costo en horas de trabajo desperdiciadas por las empresas sea mayor que lo que pagan en licencias a Microsoft. Telegram no maneja bien los monitores externos, se rompe el escalado y hay que reiniciarlo; iCloud tarda desde unos segundos hasta alrededor de una hora en sincronizar archivos incluso cuando todos los dispositivos tienen buena conexión.
Lo hacen aunque sigan viendo pruebas en contra, pero como ingeniero creo que esto es natural y eficiente. Hay que priorizar, y algunos bugs importan menos que otros. Creo que es mejor dedicar más esfuerzo a educación, salud e investigación básica que a corregir todos los bugs de todo el software.
Entonces, cuando empiezan a fallar en el 1% de los casos, la gente lo ignora porque funcionaron en el 99% anterior. Estamos entrenados para confiar en los resultados, así que ni siquiera se nos ocurre dudar. Me recuerda al libro Systemantics: https://www.amazon.com/Systemantics-Systems-Work-Especially-...
Una de las tesis centrales de ese libro es el error operacional de que “los sistemas no hacen realmente lo que dicen que hacen”. Tanto la gente común como los ingenieros lo olvidan a menudo. Que un sistema diga que hace X no significa que realmente haga X. Hay que desarrollar un escepticismo sano frente a los sistemas de TI complejos. Puede que no fallen la mayor parte del tiempo, pero tarde o temprano van a fallar.
Al menos así se siente.
Uno de los grandes problemas de estos procesamientos fue que el titular de la acción penal era la propia Post Office.
Antes de este caso no sabía que Post Office tuviera esa facultad. En la práctica, Post Office actuaba a la vez como denunciante y como fiscalía. “La Post Office Investigation Branch (IB) es la organización reconocida de investigación criminal más antigua del mundo. Durante más de 335 años ha detectado delitos relacionados con el correo y ha procesado a sus autores.”
https://www.postalmuseum.org/blog/the-post-office-investigat...
En teoría, es un medio para hacer rendir cuentas a los poderosos, pero es muy costoso, así que casi todas las acusaciones penales privadas en la práctica las presentan empresas.
No conocía este escándalo
Me pregunto cuál fue el principal problema del software que causó la discrepancia. ¿Algo como desconexiones? En Wikipedia no aparecía con mucho detalle. Lo encontré aquí: https://www.benthamsgaze.org/2021/07/15/what-went-wrong-with...
Recomendaría informarse más, pero hay que tener estómago fuerte. Muchas personas que investigaron este caso terminaron buscando una cubeta cercana. Es realmente difícil de leer
Los sistemas grandes casi siempre tienen bugs durante el desarrollo, pero normalmente se encuentran y se corrigen. Aquí se encontraron bugs y aun así no se corrigieron
Mi premisa básica es que las computadoras no funcionan correctamente
Porque he visto demasiados casos en los que efectivamente no funcionan bien. Incluso al manejar no confío ciegamente en Google Maps; verifico que la ruta tenga sentido y vuelvo a mirar el nombre de la calle y el número de salida donde me dice que gire. Ya me pasó demasiadas veces
Por mi experiencia como programador, la computadora en sí suele funcionar correctamente
Rara vez se trata de un bug de hardware. Pero el software siempre se equivoca, y el hardware de la computadora solo ejecuta ciegamente lo que el software le ordena
“Arréglenlo en software” bien podría ser el lema oficial de la industria del hardware
Aquí “computadora” significa un sistema compuesto por hardware y software, y la palabra “computadora” casi siempre se usa así. El problema es que los tribunales presumen que, si no hay pruebas en contrario, la computadora funcionaba normalmente. Es decir, el tribunal puede quedar satisfecho con que los registros de la computadora prueban los hechos relevantes y, si el acusado no puede demostrar que la computadora no funcionaba correctamente, acepta que el jefe de la oficina postal tenía un faltante financiero. En pocas palabras, si el núcleo de la acusación son registros informáticos, entonces la computadora dijo que era culpable
Con frecuencia se espera que el software que interactúa directamente con el hardware a muy bajo nivel compense esas irregularidades
Como ejemplo antiguo, las CPU Intel Pentium tuvieron dos bugs famosos descubiertos después del lanzamiento. El bug FDIV de división de punto flotante, que llevó a un retiro en 1994, y el bug F00F, descubierto en 1997, que hacía que el procesador se detuviera hasta reiniciarlo.
https://en.m.wikipedia.org/wiki/Hardware_bug
Como suele funcionar, casi siempre se asume que es un problema del usuario. Si no sabes qué buscar, terminas descartando solo los casos de error que conoces y llegas a un fallo judicial terrible como el del artículo
Esta presunción se vuelve problemática sobre todo cuando el operador de la computadora es la misma parte que persigue a la otra
Es una cuestión de qué deberían presumir los tribunales, pero también vale la pena preguntarse qué presumen o no presumen los desarrolladores de software
Un desarrollador de software presumirá que el software ampliamente usado funciona correctamente. Aunque haya 3,500 bugs de pandas en los issues de GitHub, se considera que JavaSDK o la biblioteca pandas funcionan bien. Pero si integras una biblioteca menos conocida o usas software menos conocido, tendrás menos confianza en su funcionamiento
En el sentido de que miles de personas terminarán quejándose durante años. Dicho de forma menos cínica, se puede esperar que las funciones ampliamente usadas de un software ampliamente usado hayan sido probadas en condiciones reales, así que, si hay bugs, al menos es probable que ya se conozcan. Pero incluso el espacio de estados de un software de complejidad media requiere una cantidad enorme de pruebas para cubrirlo por completo. Basta ver lo grande que es la suite de pruebas de SQLite. El único enfoque que parece funcionar bien para crear software con pocos bugs es combinar piezas pequeñas, autocontenidas, aisladas y bien entendidas para que el conjunto sea más fácil de razonar. Esa es la filosofía original de Unix, la filosofía de la programación funcional y, aunque razonar sobre interacciones asíncronas sea más difícil, parte de la filosofía de los sistemas de actores. Espero ver cada vez más este enfoque en la práctica
El título quizá sea casi lo contrario del clickbait
El artículo trata sobre el escándalo de la Post Office, y de verdad aborda un tema enorme
Enlace para preservar: https://archive.ph/wip/AJl8i