- Um solicitante de registros públicos pediu apenas os metadados dos e-mails de
seattle.govde 2017, como remetente, destinatário, cópia, hora e data, mas a cidade de Seattle entregou um arquivo que incluía também até os primeiros 256 caracteres de cerca de 32 milhões de e-mails - O Seattle IT estimou inicialmente que a revisão exigiria 320 anos de trabalho e US$ 33 milhões em salários, mas depois reduziu o custo da primeira parte para US$ 1,25, afirmando que, por se tratar de metadados sem corpo da mensagem, não era necessária revisão
- Cerca de 400 arquivos publicados no portal de registros públicos continham informações sensíveis misturadas, como nomes de usuário e senhas, números de cartão de crédito, números de seguridade social, carteira de motorista, informações de investigações da polícia e do FBI, além de alertas do Zabbix
- Depois que o solicitante avisou sobre o problema, Seattle suspendeu temporariamente o acesso ao GovQA, disse que reprocessaria a versão corrigida e depois exigiu exclusão dos arquivos, varredura do disco rígido pela Kroll e condições de isenção legal
- No fim, o solicitante apagou os arquivos, passou por medidas de declaração e limpeza de disco, e Seattle começou a fornecer em partes os metadados originalmente pedidos a partir de 26 de janeiro de 2018, entregando 27 milhões de registros até o momento da redação
Ponto de partida do pedido de registros públicos
- Depois de já ter solicitado metadados de chamadas e e-mails do gabinete do prefeito de Chicago, o solicitante ampliou os pedidos de registros públicos para verificar se problemas semelhantes apareciam de forma sistêmica em várias partes dos EUA e para mapear a estrutura de comunicação
- Ele enviou mais de 100 pedidos de metadados de e-mail por todo o país, com pelo menos 2 pedidos por estado
- O primeiro lote em grande escala foi enviado para as maiores cidades de 14 estados escolhidos aleatoriamente, e os únicos lugares onde tentou levar o pedido até o fim foram Houston e Seattle
- Houston respondeu relativamente rápido e enviou pelo correio metadados de 6 milhões de e-mails
- O pedido para Seattle depois se transformou em um caso muito mais complexo
Pedido original enviado a Seattle
- Em 2 de abril de 2017, o solicitante pediu ao departamento de TI de Seattle os metadados de todos os e-mails trocados em 2017 com endereços de e-mail pertencentes a Seattle
- From address
- To address
- bcc addresses
- cc addresses
- Time
- Date
- Tecnicamente, ele considerava que o pedido poderia ser atendido com um comando de PowerShell de uma linha, mas avaliava que, em termos de política, era o tipo de pedido que normalmente provoca forte resistência
- A primeira resposta de Seattle informou que, nos 90 dias anteriores, endereços
seattle.govhaviam enviado 5,5 milhões de e-mails e recebido 26,8 milhões, de modo que havia muitos registros a revisar antes de qualquer compartilhamento - O solicitante manteve o pedido para o conjunto completo de cerca de 32 milhões de registros, argumentando que estava pedindo apenas metadados, e não o conteúdo das mensagens, então o volume de revisão deveria ser relativamente menor
Estimativa de custo de US$ 33 milhões
- Ao reescrever o conteúdo do pedido, Seattle pareceu usar uma formulação que alterava o escopo original
- O pedido original se limitava a metadados, mas a redação reescrita parecia incluir também o conteúdo dos e-mails
- O solicitante disse não saber por que isso foi alterado
- O Seattle IT estimou que cada e-mail exigiria entre 30 segundos e 2 minutos de revisão, e que o trabalho total poderia demandar cerca de 320 anos de funcionários e US$ 33 milhões em salários
- O solicitante avaliou que pedidos grandes de registros públicos costumam ser rejeitados por serem “excessivamente onerosos”, mas que uma estimativa de custo dessa magnitude é muito rara
- Também foi apresentado um custo de armazenamento separado
- Seattle estimou que os dados solicitados poderiam ter entre 8 e 10 TB e considerou montar um servidor FTP para download
- Pelo modelo interno de custos, poderia cobrar US$ 2.480 por ano mais US$ 2,11 por GB; para 10 TB, o cálculo chegava a US$ 21.606,40 por ano
- O solicitante comparou isso com o dump de metadados de e-mail de Houston, que tinha 1,2 GB, e com o fato de que Seattle usava Amazon S3 para armazenar dados de pedidos de registros públicos
- Na época, o preço do S3 era de US$ 0,023 por GB
- Seattle não encerrou o pedido imediatamente e perguntou se ele queria seguir em frente; em 29 de maio, o solicitante perguntou quantos registros receberia, mas não obteve resposta
Retirada da estimativa e primeira parte por US$ 1,25
- Em 5 de junho, Seattle reconheceu que a estimativa inicial de custo estava errada e cobrou US$ 1,25 pela primeira parte, correspondente aos registros de dois dias, 1º e 2 de janeiro, dentro de um período de 3 meses
- Foi informado que o arquivo entregue seria uma planilha Excel contendo apenas os metadados solicitados, sem o corpo dos e-mails, e por isso não exigiria revisão, podendo ser fornecido muito mais rápido do que os 320 anos mencionados antes
- O solicitante interpretou a exigência de um cheque individual para cada bloco de dois dias como uma forma de dificultar deliberadamente o pedido e enviou 14 cheques antecipadamente
- Os primeiros 13 eram de cerca de US$ 1,25 cada
- Depois disso, Seattle não exigiu mais pagamentos unitários adicionais
- Durante dois meses não houve grandes novidades, e então Seattle descontou todos os cheques e criou uma conta no portal de registros públicos
Grande vazamento revelado no portal GovQA
- Em 22 de agosto, ao adicionar novamente a conta de e-mail ao celular, o solicitante percebeu que o pedido havia sido concluído
- No portal de pedidos de registros públicos de Seattle, havia cerca de 400 arquivos disponíveis para download, contendo no total metadados de aproximadamente 32 milhões de e-mails
- O maior problema era que os primeiros 256 caracteres de todos os e-mails também estavam incluídos
- Os arquivos continham informações como:
- nomes de usuário e senhas
- números de cartão de crédito
- números de seguridade social e de carteira de motorista
- investigações policiais em andamento e relatórios de prisão
- conteúdo de mensagens sobre casos extraconjugais
- investigações do FBI
- alertas do Zabbix
- O solicitante considerou que se tratava de um enorme conjunto de dados repleto de informações muito privadas e que provavelmente violava diversas leis, incluindo o Privacy Act of 1974 e normas do estado de Washington sobre registros públicos
- A causa exata é difícil de saber, mas ele sugeriu que pode ter havido falha de comunicação causada pela reescrita do pedido e pelas férias do responsável original por registros públicos
Contestação e resposta inicial de Seattle
- O solicitante respondeu esperando que Seattle percebesse o próprio erro, dizendo que os registros entregues não correspondiam ao pedido original e continham muito mais informação do que a solicitada, e pediu nova revisão
- Seattle respondeu que as informações pedidas estavam em colunas específicas do relatório e que, como os registros haviam sido gerados por um relatório do sistema, não era possível limitá-los apenas aos campos solicitados
- From address ficava na coluna J
- To address na coluna K
- bcc address na coluna M
- cc address na coluna L
- Time and date na coluna R
- Seattle afirmou que não tinha obrigação de criar novos registros inexistentes e considerou o pedido encerrado, pois havia fornecido todos os registros responsivos
- Quando o solicitante detalhou as informações vazadas e disse que levaria o caso ao Washington Office of Privacy and Data Protection, Seattle reconheceu o caso como um erro involuntário
- Seattle suspendeu temporariamente o acesso ao GovQA para investigar a causa e informou que forneceria os registros corrigidos na semana seguinte por meio do GovQA
- Ao mesmo tempo, pediu ao solicitante que não revisasse, compartilhasse, copiasse nem usasse os registros em questão
Ligação com o CTO e o Chief Privacy Officer
- Depois disso, o solicitante entrou em uma conference call com o CTO de Seattle e o Chief Privacy Officer por meio de contatos ligados ao Slack de Open Data de Seattle
- Na ligação, discutiu-se o que havia acontecido e como os registros deveriam ser tratados
- O solicitante disse que, enquanto perguntava se poderia manter os e-mails, sua conexão com a internet caiu; quando voltou cerca de 10 minutos depois, o clima da ligação havia mudado
- Seattle apresentou as seguintes condições
- exclusão de todos os arquivos
- contratação da Kroll para escanear o disco rígido e comprovar a exclusão
- se concordasse com os itens 1 e 2, receberia isenção legal completa
- O solicitante não concordou e decidiu que, dali em diante, os advogados tratariam do assunto
Pressão legal e confirmação da exclusão
- Depois da ligação, o advogado do solicitante entrou em contato com os advogados de Seattle, e Seattle aparentemente passou a tratar o caso examinando possíveis acusações ligadas ao Computer Fraud and Abuse Act
- O solicitante considerou problemático ser tratado dessa forma por informações que a própria Seattle havia enviado, mas acabou apagando os arquivos
- Durante cerca de um mês, a maior parte das discussões ocorreu entre os advogados das duas partes
- O solicitante propôs uma declaração formal explicando o ocorrido, como os arquivos foram apagados e como a exclusão seria verificada
- Seattle concordou em grande parte com a declaração, mas exigiu garantias adicionais, como a execução de um bash script para sobrescrever com bits aleatórios o espaço não utilizado do disco
- No fim, o solicitante executou
zerofreeefstrim, e Seattle aceitou a declaração - Depois disso, não houve novas ameaças legais
Cobertura externa e notificação de Seattle
- Cerca de uma semana após a ligação, um funcionário da cidade de Seattle contou o caso à KIRO7, de Seattle
- A investigação da KIRO7 revelou que Seattle ainda não havia notificado sobre o vazamento, embora isso fosse exigido pela lei do estado de Washington sobre pedidos de registros públicos
- Só depois da investigação da KIRO7 Seattle notificou os funcionários sobre o vazamento de e-mails
- A cobertura relacionada saiu em uma matéria da KIRO7
- Uma semana depois, uma matéria da Crosscut tratou o caso com mais detalhes, incluindo o histórico do departamento de TI de Seattle
- Em 19 de janeiro, o CTO de Seattle, Michael Mattmiller, renunciou; o solicitante disse não saber se a saída tinha relação com o vazamento, mas considerou a coincidência temporal digna de menção
Entrega final dos metadados
- A partir de 26 de janeiro de 2018, Seattle começou a entregar em partes os metadados de e-mail originalmente solicitados
- Até o momento da redação, foram entregues 27 milhões de registros de metadados de e-mail
- Os únicos departamentos que ainda não haviam fornecido metadados eram o Police Department e o Human Services
- Os dados brutos podem ser baixados no dataset do Kaggle
- O dataset ainda contém elementos que dificultam processamento e análise
- triple quotes, ponto e vírgula, vírgulas e outros elementos tornam os dados bastante bagunçados
- há milhões de alertas de sistema incluídos
- comunicações entre endereços
seattle.govtêm dois registros de metadados diferentes entre si
- O solicitante está fazendo um trabalho de prova de conceito para usar esses dados no contexto da lei de registros públicos e visualizou um dia de metadados no Gephi
- o layout é Yifan Hu
- foi aplicado filtro com k-core mínimo 5 e degree mínimo 5
- Ele pede contato de pessoas que possam ajudar com modelagem de rede
Controvérsia legislativa no estado de Washington e próximos planos
- Em 23 de fevereiro, entre a primeira e a segunda parte dos metadados, o legislativo do estado de Washington tentou aprovar a SB6617
- A SB6617 era um projeto que excluiria da lei de registros públicos do estado de Washington vários tipos de registros, incluindo trocas de e-mail
- O projeto passou pela Câmara e pelo Senado em menos de 24 horas após a primeira leitura e foi enviado ao gabinete do governador
- O Seattle Times tratou do assunto em uma matéria
- O gabinete do governador de Washington recebeu mais de 6.300 telefonemas, 100 cartas e mais de 12.500 e-mails, e o governador acabou vetando o projeto
- Quando o solicitante perguntou se essa controvérsia tinha relação com o atraso na segunda parte dos metadados, Seattle respondeu que não, que havia corrigido o bug que travava o andamento e que enviaria registros adicionais naquela semana
- Um mês depois, Seattle começou a enviar o restante
- O solicitante continua obtendo metadados de e-mail de outras cidades e pretende escrever mais sobre os fundamentos dos pedidos de registros públicos e sobre solicitações de registros digitais
- O próximo texto tratará do processo em andamento contra o White House OMB por metadados de e-mail de janeiro de 2017; segundo ele, na primeira audiência o advogado da parte ré não compareceu
1 comentários
Opiniões no Hacker News
A parte mais interessante dessa história é o risco jurídico de continuar mantendo registros divulgados por engano
Se o autor não tivesse informado à cidade que ela havia “divulgado informações muito mais sensíveis do que imaginava”, provavelmente a cidade nunca teria percebido o erro, e talvez o autor pudesse ter feito o que quisesse com esses dados
Mas, no momento em que ele avisou, a cidade passou a saber que os dados estavam nas mãos de alguém que não deveria ter acesso, e surgiu a questão jurídica de ele ter ou não o direito de mantê-los
Quando se trata de propriedade física ou dinheiro, há muita jurisprudência sobre como lidar com algo recebido por um erro evidente. Se uma concessionária deixa um carro novo no endereço errado e depois descobre que era para outro endereço, você não pode ficar com o carro; e, se US$ 100 mil forem depositados por engano na sua conta bancária, o valor será recuperado
Mas e quanto a dados, isto é, informações? Acho que há um argumento jurídico razoável de que certas categorias de dados, como segredos comerciais, podem ser objeto de uma ordem para que você não as mantenha
Por isso, mesmo que tenha sido um erro enorme da cidade criar essa situação, parece que o autor tomou a decisão correta ao cooperar com o pedido da cidade. Ainda assim, é lamentável que a cidade, em vez de recompensá-lo por ter avisado sobre o problema, tenha tentado ameaçá-lo caso ele não cooperasse para corrigir o erro deles
https://about.usps.com/publications/pub300a/pub300a_v04_revi...
https://faq.usps.com/s/article/What-Options-Do-I-Have-Regard...
Há também uma discussão adicional sobre casos em que se recebe algo entregue por engano
https://law.stackexchange.com/questions/17533/if-a-retailer-...
Se você acha que o tratamento depois de avisar já foi ruim, basta imaginar quanto pior teria sido se ele não tivesse avisado
E também não decorre necessariamente daí que ele poderia ter feito o que quisesse com os dados. Se tivesse divulgado dados adicionais, é bem provável que teria se metido em grande encrenca
Mesmo agora, no fim das contas, o fato de os dados terem sido apagados depende em certa medida de acreditar na declaração juramentada que ele assinou
Portanto, é ambíguo se existe uma estrutura jurídica clara para processar alguém simplesmente por continuar mantendo registros recebidos por engano. Se fosse propriedade física ou alguns dados protegidos por direitos autorais, seria outra questão
TI governamental é famosa por ser cara e, muitas vezes, desastrosa. Recentemente precisei criar uma conta em um órgão local e descobri, por tentativa e erro, que dois campos de data do formulário web exigiam formatos diferentes
No fim recebi as informações de login, mas elas não funcionavam; achei que fosse problema de senha e cliquei para redefinir, só para receber um erro 404
A pessoa responsável foi muito educada, mas só consegui fazer login depois que o órgão redefiniu três vezes
Se uma empresa privada tivesse problemas assim, iria à falência. O governo provavelmente vai contratar mais uma pessoa incompetente, e essa pessoa deve ganhar um emprego para a vida toda
Claro que provavelmente não haverá um meio de responsabilizar de fato essa empresa terceirizada
É por isso que a TI governamental não é lá muito boa. É um ambiente horrível para trabalhar, e a remuneração também não é boa em comparação com o setor privado
Eu já trabalhei bastante na área de dados abertos e também em um departamento de dados abertos de um governo de grande cidade.
Esse tipo de atitude não ajuda em nada a causa. Só reforça a crença de que dados abertos e pedidos de acesso à informação são um enorme desperdício de tempo e recursos, e que apenas abrem riscos legais sem muito motivo.
Também acho bem surpreendente considerar metadados de e-mails do governo como dados abertos legítimos. Você acha que deveria ser público quantas vezes você enviou e-mails ao governo e recebeu respostas, e com quais departamentos se comunicou? Eu não acho.
Fica uma assimetria estranha dizer que tudo bem eles terem seus metadados, mas que você não pode ter os deles.
Não é um espelho perfeito, mas, se o OP mostrar que esses metadados são poderosos e pressionar para que ambos os lados parem de coletar esse tipo de metadado, consigo imaginar um uso legítimo desse tipo de pedido de acesso à informação.
Esse tipo de coisa acontece o tempo todo. Pior ainda é que pessoas em cargos altos, como Chief Data Officers, muitas vezes não conseguem falar com a imprensa ou com organizações próximas por causa do jurídico. Já ouvi literalmente de um CDO: “não posso falar com você”.
Uma frase que uso com frequência sobre dados abertos é: “dados abertos são uma mentira”. No fim das contas, não há nenhum meio legal de verificar se aquilo que foi fornecido como conjunto de dados aberto está completo, tanto em colunas quanto em linhas.
É muito raro sequer explicarem se há informações faltando, ou por que estão faltando. Como resultado, o público passa a ter um entendimento profundamente equivocado da situação real, e muitos fazem isso de propósito por medo de que o público interprete os dados de forma errada.
Por isso, no fim, você acaba recorrendo à FOIA e até a disputas judiciais. Há um motivo para eu ter precisado entrar com cerca de 10 ações envolvendo FOIA.
Resumindo: dados abertos são bons, mas, por falta de rigor e responsabilização, são praticamente inúteis para trabalhos que exigem profundidade.
Isso inclui tanto metadados quanto conteúdo, e a orientação é não incluir informações sensíveis que você não queira ver divulgadas.
Foi uma leitura interessante.
Como alguém que já trabalhou do outro lado, como administrador de sistemas, consigo imaginar quase exatamente como a solicitação inicial dele foi recebida.
Como acontece muitas vezes, provavelmente leram só parte do pedido e se assustaram com a escala. Então, na cabeça deles, ele estava pedindo informação demais, e talvez tenham passado dias rindo dele no bebedouro, com base em uma premissa errada.
Imagino que, no fim, alguém tenha percebido o mal-entendido e cometido o erro fatal de exportar cabeçalhos cortados de um valor hardcoded, em vez de fazer o parsing dos cabeçalhos de e-mail.
E só depois que ele apontou esse problema é que começaram a levá-lo a sério.
Não estou dizendo que a TI deve sempre se curvar a qualquer pedido, nem que se espere educação diante de abuso real.
Mas a fofoca tóxica no bebedouro não é isso. É literalmente insultar a inteligência das pessoas ou, especialmente em situações em que se exerce poder sobre usuários, sentir prazer com o sofrimento delas.
Isso me lembra a vez em que o Assessor do nosso condado ameaçou chamar a polícia porque eu disse que queria dados públicos.
Também tentaram me cobrar milhares de dólares a mais por materiais pelos quais deveriam cobrar apenas o custo de reprodução dos registros, além de várias outras coisas.
Lidar com órgãos públicos é realmente uma diversão.
Na Europa, uma solicitação dessas vincularia informações relacionadas a pessoas, ou seja, quem entrou em contato com quem, em que data e hora
Armazenar isso, quanto mais processar, só é permitido quando há necessidade de saber
Mesmo insistir que funcionários públicos agindo em nome de Seattle já não são indivíduos é uma interpretação forçada; mesmo nesse caso, todos os endereços de e-mail fora do domínio do governo de Seattle seriam terreno completamente proibido sem ordem judicial, justificativa e a condição de se tratar de investigadores criminais
Ah, a proteção de dados pessoais
E cidades divulgam informações pessoais o tempo todo sem muita cerimônia. Endereços residenciais e proprietários de imóveis dentro da cidade estão sujeitos a registros públicos, e a cidade não vê grande problema em entregar nomes e endereços a qualquer pessoa que solicite
Endereços de e-mail têm um risco muito menor do que isso
Faz sentido que os cidadãos possam verificar o que o governo está fazendo. Infelizmente, o governo registra coisas demais; às vezes eu preferiria que não registrasse, e seria ainda melhor se esses registros não estivessem sujeitos à divulgação pública
Se você acha essa solicitação ruim, vale a pena pesquisar a história da LexisNexis. O negócio central deles é solicitar dados, reuni-los em um banco de dados e permitir que o governo dos EUA faça verificações de antecedentes sobre praticamente qualquer pessoa de quem tenha uma vaga noção
Havia também um site chamado masscorruption, se lembro bem, mantido por alguém obcecado por um governo de condado em Massachusetts. Ele fez um pedido FOIA para todos os arquivos de imagem nos desktops do governo, de fato os recebeu e publicou imagens pessoais de funcionários que não deveriam estar armazenadas em computadores do governo
No meu trabalho, sempre que coloco um funcionário do governo no campo de destinatário, o Outlook exibe um banner dizendo que a mensagem que estou escrevendo pode estar sujeita à FOIA. Especialmente em governos locais, é realmente impossível saber o que vai mobilizar as pessoas e o que vai despertar seu interesse
O autor parece enxergar “metadados” de um jeito completamente diferente
Do meu ponto de vista, metadados seriam algo como “número aproximado de e-mails”, se possível “blocos de endereços”, “faixas de horário amplamente médias”, talvez “categorias muito vagas”
Quem enviou, para quem foi, quem estava em cópia oculta e quem estava em cópia não são metadados no meu entendimento
Pela lei, é preciso manter registros de todas as ações e comunicações, e qualquer pessoa pode consultá-los
Estritamente falando, recursos do governo não deveriam ser usados para comunicação privada, e, legalmente, meios privados de comunicação também não deveriam ser usados para trabalho público
Separadamente do ponto central do texto, tenho uma curiosidade real: há tanta gente assim que pode simplesmente chamar “meu advogado”?
O texto diz que Seattle abordou o caso como se fosse levar adiante acusações sob a Computer Fraud And Abuse Act (CFAA) em relação às informações que eles próprios enviaram, então o autor fez seu advogado entrar em contato com o advogado da outra parte
Nas jurisdições que conheço, quando um pedido é negado ou quando cobram uma taxa que você considera injusta, uma ação judicial é basicamente o principal meio de reparação
Quando há dúvida, é melhor continuar com alguém que já conhece a minha situação
Por exemplo, tive alguns problemas em um imóvel alugado antigo e, nesse processo, entrei para uma associação de proteção a inquilinos, a Mieterschutzbund. Por meio dela, posso ter 1 hora de consulta com um especialista da associação e também 1 a 2 horas de consulta com um advogado especializado em direito do inquilino
Esse processo normalmente leva só 1 ou 2 dias, então, na prática, tenho um advogado de locação de prontidão
Em troca, eu conserto a fiação elétrica de alumínio na casa dele
Arquivo preservado: https://web.archive.org/web/20231024164822/https://mchap.io/...
Uma solicitação feita em 2017 pedindo as seguintes informações sobre todos os e-mails enviados ou recebidos por endereços de e-mail pertencentes a Seattle é realmente um pedido razoável ao qual o governo deveria responder?
Isso não expõe muitas informações privadas de funcionários do governo e das pessoas com quem eles se comunicam? O texto e a lei parecem tratar isso como algo totalmente normal, mas para mim parece muito estranho
Por exemplo, isso pode revelar os horários exatos em que as pessoas entram e saem do escritório, informações de férias de todos os funcionários, amizades ou relações que não são explicadas pelo organograma ou pela divisão de equipes, e até pistas relacionadas a investigações criminais
Se é possível inferir tanta coisa assim, fico em dúvida se realmente dá para chamar isso de metadados
Funcionário de papelada que só atrapalha? Tem. Analfabeto digital? Tem. Culpar o solicitante pelo próprio erro? Tem. Tudo isso junto? Não tem preço