1 pontos por GN⁺ 2023-10-02 | 1 comentários | Compartilhar no WhatsApp
  • o escândalo das acusações do Post Office Horizon no Reino Unido é um caso de erro judiciário em grande escala na Grã-Bretanha moderna, mostrando não só falhas individuais e organizacionais, mas também que papel a lei e os procedimentos judiciais tiveram
  • os tribunais presumem que um dispositivo mecânico estava funcionando normalmente na ausência de prova em contrário, e esse ponto de partida também se aplica a registros de computador
  • sob essa presunção probatória, só os registros de computador podem bastar para comprovar fatos como déficit contábil, criando uma estrutura em que o réu precisa provar o erro
  • a Section 69 do Police and Criminal Evidence Act de 1984 estabelecia a regra oposta, exigindo que a acusação demonstrasse o funcionamento normal do computador, mas foi revogada em 1999
  • se a Section 69 tivesse permanecido, a forma como as acusações do Post Office avançaram poderia ter sido diferente, e após sua revogação o ônus voltou a recair sobre o réu

O escândalo do Post Office Horizon e a responsabilidade do processo legal

  • o Post Office prosecutions scandal é considerado um dos maiores casos de erro judiciário em massa da Grã-Bretanha moderna
  • o caso reúne falhas pessoais e institucionais, e os documentos e provas legais também são vastos, o que dificulta compreender o quadro completo
  • muitas análises focam nas falhas da diretoria do Post Office, dos advogados e da fornecedora de software Fujitsu
  • porém, a lei e os procedimentos aplicados também fizeram parte do problema, e a responsabilidade não diminui pelo fato de que os tomadores de decisão sabiam ou deveriam saber que isso poderia operar de forma severa contra os réus

A presunção probatória de que “o computador funciona normalmente”

  • a presunção (presumption) de que juristas falam é um mecanismo pelo qual o tribunal adota um determinado estado como padrão na ausência de prova em contrário
  • a formulação clássica é: “na ausência de prova em contrário, o tribunal presumirá que um dispositivo mecânico estava em condição normal no momento relevante”
  • aqui, dispositivo mecânico também inclui computadores
  • isso não significa que o tribunal sempre confia no computador em qualquer situação, mas sim que esse é o ponto de partida, que pode ser contestado por prova
  • a menos que o estado contrário seja demonstrado, o tribunal pode aceitar esse estado como fato

Por que a presunção é necessária e qual é o risco

  • o uso de presunções pelos tribunais não é, por si só, um problema; sem elas, seria difícil tratar muitos casos de forma prática
  • as presunções reduzem as questões do caso a um escopo administrável
    • um contrato pode ser tratado como não fraudulento, a menos que se prove que é falso
    • um réu pode ser tratado como não portador de transtorno mental, a menos que se prove o contrário
  • o ponto central é qual estado vira o padrão e qual lado precisa derrubar esse padrão
  • se o conteúdo da presunção for irrealista ou se as condições para refutá-la forem excessivamente difíceis, a presunção deixa de ajudar a Justiça e passa a ser um mecanismo que produz erros judiciários

A estrutura em que registros de computador viram a base da condenação

  • a regra de considerar que o computador estava funcionando normalmente é uma presunção probatória
  • se não houver prova de que o computador não estava funcionando corretamente, o tribunal pode considerar que só os registros de computador já bastam para provar os fatos relevantes
  • por exemplo, se os registros de computador mostram um déficit financeiro de um subpostmaster ou de uma funcionária dos Correios, o tribunal pode aceitá-los como prova de um déficit real
  • para abalar essa premissa, o réu precisa mostrar que o computador não estava funcionando normalmente
  • quando a principal prova da acusação são registros de computador, a estrutura acaba virando “computer says guilty

Introdução e revogação da Section 69

  • essa presunção probatória nem sempre operou na mesma direção
  • a Section 69 do Police and Criminal Evidence Act 1984, aprovada em 1984, inverteu a direção da presunção
  • sob a Section 69, em vez de o réu ter de mostrar erro no computador, a acusação precisava demonstrar o funcionamento normal do computador
  • essa disposição substituiu a posição tradicional da common law segundo a qual “na ausência de prova em contrário, presume-se que um dispositivo mecânico estava em condição normal”
  • se a Section 69 ainda estivesse em vigor quando o Post Office processou os subpostmasters e as funcionárias dos Correios, o andamento dos casos poderia ter sido diferente
  • a Section 69 foi revogada em 1999, e a presunção tradicional da common law voltou a valer
  • desde então, a estrutura passou a não exigir mais que o promotor demonstre primeiro o funcionamento normal do computador; em vez disso, o réu precisa mostrar que o computador não estava funcionando normalmente
  • como a Section 69 foi revogada e se as razões para isso eram válidas ficam como tema para o texto seguinte

1 comentários

 
GN⁺ 2023-10-02
Opiniões no Hacker News
  • A impressão que tive na última vez que examinei o escândalo dos Correios foi que dizer “confiamos demais no sistema de TI” era mais uma desculpa conveniente
    A alta cúpula sabia bem do problema e também sabia que estava processando pessoas inocentes, mas parece ter seguido em frente para encobrir o próprio fracasso. Se for assim, são necessárias penas de prisão significativas. Obstrução da Justiça não é um crime leve, e há até suspeitas de que Paula Vennells tenha mentido deliberadamente ao Parlamento

    • Há evidências consideráveis de que, quando os poderosos do conselho dos Correios ignoraram as provas dos subpostmasters, teve grande peso o fato de muitos deles serem asiáticos, como descendentes de indianos, bengaleses e paquistaneses
      Por isso, por causa do racismo, o conselho dos Correios tinha uma barreira psicológica que o impedia de ligar os pontos e, mesmo depois de confrontado com evidências avassaladoras de centenas de condenações falsas, faltou-lhe moralidade e ele resistiu ainda mais. É também uma triste história de falha tecnológica, mas também uma denúncia da cultura dos conselhos de administração no Reino Unido. Essa catástrofe vem sendo coberta pela revista Private Eye há mais de 10 anos
    • Não entendo por que se acha que regras de punição — no fim das contas, colocar pessoas na prisão ou taxar comportamentos permitidos — poderiam resolver esse problema
      Não faria mais sentido defender a remoção estrutural desse poder?
    • Se a punição esperada pelos executivos tivesse sido maior, os problemas dos subpostmasters teriam sido resolvidos mais rapidamente, ou mais tarde?
  • Depois de passar a vida consertando bugs, muitas vezes me surpreende o simples fato de sistemas de computador sequer funcionarem
    Tive pessoalmente uma experiência parecida com o sistema fracassado dos Correios: mesmo apresentando evidências, todos rejeitavam a possibilidade de o sistema de computador estar errado. Era porque investigar a fundo para entender dava trabalho demais

    • Concordo com a frase “é surpreendente que sistemas de computador sequer funcionem”
      Como vi de perto como software é feito, não entendo como tudo isso consegue funcionar. Minha resposta a esse paradoxo é que, na verdade, nem tudo funciona. Fomos treinados a aceitar o que não funciona como se fosse outra coisa. As pessoas veem sistemas de computador como onipotentes e infalíveis ou, ao contrário, os tratam como bodes expiatórios
    • Para acrescentar um pouco mais de nuance: muitos softwares populares estão tão quebrados que sua função central — a própria razão de o software existir — não funciona
      Por exemplo, ao usar nos últimos dois anos sites de companhias aéreas como TAP, Vueling e KLM, encontrei com frequência bugs que impediam reservar passagens ou fazer login na conta, e eu diria que eles não funcionavam mais vezes do que funcionavam. Instagram e Google vêm desativando contas automaticamente sem motivo aparente; no Instagram, depois de passar por isso 3 vezes em dois meses, simplesmente desisti e parei de usar. Quem usa Skype dispensa explicações, e o Teams falha de formas impressionantes, mesmo depois de inúmeros “updates”: o botão de silenciar não silencia de fato, a ordem das letras em uma frase se inverte enquanto você digita no chat, ou ele encerra de repente durante uma chamada e para de responder. Essa perda de produtividade deve ser considerável no mundo todo, e é possível que o custo da mão de obra desperdiçada pelas empresas seja maior do que o que elas pagam em licenças à Microsoft. O Telegram não lida direito com monitores externos, quebra a escala e exige reinicialização, e o iCloud leva de alguns segundos a cerca de uma hora para sincronizar arquivos mesmo quando todos os dispositivos estão com boa conexão
    • A maioria das pessoas tende a escolher o caminho fácil de acreditar que tudo é perfeito, em vez de aceitar que tudo funciona “mais ou menos”
      Isso acontece mesmo vendo continuamente evidências em contrário, mas, como engenheiro, acho isso natural e eficiente. É preciso definir prioridades, e alguns bugs são menos importantes que outros. Acho melhor dedicar mais esforço a educação, saúde e pesquisa básica do que corrigir todos os bugs de todos os softwares
    • Isso acontece com frequência porque as máquinas geralmente funcionam bem durante 99% do tempo
      Então, quando começam a falhar no 1% dos casos, as pessoas ignoram, porque elas funcionaram nos 99% anteriores. Elas foram treinadas a confiar nos resultados, então a própria dúvida nem lhes ocorre. Isso me lembra o livro Systemantics: https://www.amazon.com/Systemantics-Systems-Work-Especially-...
      Uma das teses centrais do livro é a falácia operacional de que “um sistema não faz de fato aquilo que diz fazer”. Não só pessoas comuns, mas também engenheiros se esquecem disso com frequência. Só porque um sistema diz que faz X não significa que ele realmente faça X. É preciso cultivar um ceticismo saudável em relação a sistemas de TI complexos. Eles podem não falhar na maior parte do tempo, mas, inevitavelmente, algum dia falharão
    • O crescimento acelerado da indústria de software é tanto uma causa de uma confusão incontrolável quanto o motivo pelo qual as empresas gastam quantias absurdas para fazer as coisas continuarem funcionando de algum jeito
      Pelo menos é essa a sensação
  • Um dos grandes problemas desses processos é que o titular do direito de acusar era o próprio Post Office
    Antes desse caso, eu nem sabia que o Post Office tinha esse poder. Na prática, o Post Office atuava ao mesmo tempo como denunciante e órgão de acusação. “O Post Office Investigation Branch (IB) é a organização reconhecida de investigação criminal mais antiga do mundo. Há mais de 335 anos, identifica crimes relacionados ao correio e processa seus autores.”
    https://www.postalmuseum.org/blog/the-post-office-investigat...

    • Na Inglaterra, qualquer pessoa pode propor uma acusação
      Em teoria, é um meio de responsabilizar pessoas poderosas, mas é extremamente caro, de modo que quase todas as acusações privadas são, na prática, movidas por empresas
  • Eu não conhecia esse escândalo
    Fiquei curioso para saber qual foi o principal problema do software que causou as inconsistências. Algo como perda de conexão? A Wikipedia não trazia muitos detalhes. Encontrei aqui: https://www.benthamsgaze.org/2021/07/15/what-went-wrong-with...

    • Este é um dos maiores escândalos relacionados a software da nossa época
      Eu recomendaria ler mais a respeito, mas é preciso ter estômago forte. Muita gente que se aprofundou nesse caso acabou procurando um balde por perto. É realmente difícil de encarar
    • Acho que o problema foi mais a indiferença do que os bugs em si
      Sistemas grandes quase sempre têm bugs durante o desenvolvimento, mas normalmente eles são encontrados e corrigidos. Aqui, os bugs foram encontrados, mas não foram corrigidos
    • Em resumo, um livro-razão distribuído fornecido por terceiros saiu de sincronia com permissões de acesso impossíveis de auditar, e, como “o computador disse que era assim”, gerentes de agências viraram bodes expiatórios por fraudes fictícias
  • Minha premissa básica é que computadores não funcionam corretamente
    Porque já vi casos demais em que, de fato, eles não funcionavam corretamente. Até quando dirijo, não confio cegamente no Google Maps: verifico se a rota faz sentido e confiro de novo o nome da rua e o número da saída onde ele manda virar. Já caí nessa vezes demais

  • Pela minha experiência como programador, o computador em si normalmente funciona corretamente
    Quase nunca é um bug de hardware. Mas o software está sempre errado, e o hardware do computador apenas executa cegamente o que o software mandou

    • Pela minha experiência como programador que trabalha com drivers, o hardware quase nunca funciona corretamente
      “É só corrigir no software” poderia muito bem ser o lema oficial da indústria de hardware
    • Essa distinção não é relevante para este texto
      Aqui, “computador” significa um sistema composto de hardware e software, e a palavra “computador” quase sempre é usada assim. O problema é os tribunais presumirem que um computador estava funcionando normalmente quando não há prova em contrário. Ou seja, o tribunal pode se dar por satisfeito de que os fatos relevantes foram provados apenas com os registros do computador e, se o réu não conseguir mostrar que o computador não estava funcionando corretamente, aceitar que havia um déficit financeiro atribuível ao chefe da agência dos Correios. Em suma, se o núcleo da acusação são os registros do computador, então foi o computador que disse que a pessoa era culpada
    • No hardware há uma enorme quantidade de pequenos comportamentos peculiares ou hacks para fazê-lo funcionar corretamente, e ele de fato frequentemente não funciona direito
      Muitas vezes se espera que o software que mexe diretamente com o hardware em um nível muito baixo compense essas irregularidades
    • Isso também acontece no hardware
      Como exemplo antigo, CPUs Intel Pentium tiveram dois bugs famosos descobertos após o lançamento. O bug FDIV de divisão em ponto flutuante, que levou a um recall em 1994, e o bug F00F, descoberto em 1997, que travava o processador até a reinicialização.
      https://en.m.wikipedia.org/wiki/Hardware_bug
    • Você está descrevendo exatamente a experiência que pessoas que não são programadoras têm com software
      Como geralmente funciona, presume-se que quase sempre seja problema do usuário. Se você não sabe o que procurar, acaba apenas descartando os casos de erro que conhece e chega a erros judiciais terríveis como os do texto acima
  • Essa presunção vira um problema principalmente quando o operador do computador é a mesma parte que persegue a outra

    1. é difícil ou impossível para alguém de fora verificar o funcionamento do computador, e 2) o operador tem um forte incentivo para manipular as saídas do computador ou esconder erros. Como caso relacionado pelo ponto de vista oposto, lembro de alguns anos atrás, quando trolls de copyright usavam em tribunal logs criados por eles mesmos a partir de enxames de BitTorrent. Esses dados eram muito fáceis de falsificar e quase impossíveis de detectar por pessoas de fora, e havia um grande incentivo financeiro para fazer isso. Parecia absurdo que esse tipo de “prova” fosse sequer considerado em juízo
    • Ah, o caso Prenda Law... que lembranças
  • É uma questão do que os tribunais devem presumir, mas também vale perguntar o que desenvolvedores de software presumem ou deixam de presumir
    Desenvolvedores de software vão presumir que um software amplamente usado funciona corretamente. Mesmo que haja 3.500 bugs no GitHub Issues do pandas, eles consideram que o JavaSDK ou a biblioteca pandas funcionam corretamente. Mas, se estiverem integrando uma biblioteca menos conhecida ou usando um software menos conhecido, ficam menos confiantes quanto ao seu funcionamento

    • Com olhos suficientes, todos os bugs são rasos
      No sentido de que, assim, milhares de pessoas acabam reclamando durante anos. Dizendo de forma menos cínica: é razoável esperar que funcionalidades amplamente usadas de softwares amplamente usados tenham sido testadas em condições reais, então, se houver bugs, é provável que ao menos sejam conhecidos. Mas o espaço de estados até de um software de complexidade média exige uma quantidade enorme de testes para ser coberto por completo. Basta ver o tamanho da suíte de testes do SQLite. A única abordagem que parece funcionar bem para criar software com poucos bugs é combinar componentes pequenos, autocontidos, isolados e bem compreendidos, tornando o todo mais fácil de raciocinar. Essa é a filosofia original do Unix, a filosofia da programação funcional e parte da filosofia de sistemas de atores, embora o raciocínio sobre interações assíncronas seja mais difícil. Espero ver essa abordagem cada vez mais na prática
  • O título talvez seja quase o oposto de clickbait
    O texto trata do escândalo dos Correios, mas pegou um tema realmente grande

  • Link para preservação: https://archive.ph/wip/AJl8i