Um dos maiores impactos que o GDPR terá sobre os consumidores (pelo menos aqueles que são cidadãos de países que seguem as normas regulamentares do General Data Protection Regulation) é o direito de ser esquecido. Um indivíduo pode requerer ser removido dos registros. Mas e se o registro for parte de um blockchain? Isso representa um desafio para a implementação do blockchain. Blockchains são idealizados para durarem para sempre. Cada bloco tem um hash baseado em seus conteúdos, além de armazenar o hash do bloco anterior.
Sendo assim, quando você pega qualquer bloco dentro do blockchain é possível seguir toda a cadeia, bloco a bloco, até sua origem. Ao mudar os conteúdos em um determinado bloco, automaticamente muda-se a hash também; por sua vez, se a hash muda, o bloco seguinte não mais irá referenciá-lo, pois ele iria apontar para o bloco original. Refazer esta cadeia implica em recalcular cada bloco subsequente, o que requer um enorme esforço computacional.
Na figura abaixo, vemos parte do blockchain exibindo três blocos. No bloco 36, vemos o hash do bloco 35, alguns dados (DATA YYYY) e seu próprio hash (HASH 36). Note que alguns dados possíveis de serem gravados podem incluir o criador do bloco (ou seja, quem minerou o hash). Se os dados mudam, o valor do hash muda e os blocos subsequentes não mais apontarão para ele.
Três blocos em um exemplo de blockchain
Para um blockchain já distribuído, o desafio de se modificar a cadeia torna-se muito maior. Não só cada bloco subsequente precisará ser recalculado como cada cópia do blockchain deverá ser atualizada, em cada máquina. Comparativamente, quem algum dia já enviou um email errado para vários recipientes sabe como é difícil retificar a informação enviada. Dado que o blockchains são inapagáveis, qualquer registro de informação pessoal presente no bloco não pode ser alterado.
Além disso, qualquer indivíduo que cria um bloco no blockchain fica permanentemente ligado a ele por todo tempo em que durar aquela cadeia em particular. Por este motivo, em sistemas como o do bitcoin frequentemente são usados pseudônimos criptografados para identificar o criador sem que ele revele sua identidade. Se o criador de um bloco tem sua identidade real revelada, todas suas transações são expostas. Resumindo: tanto os conteúdos de um bloco quanto sua autoria são permanentes.
De acordo com a GDPR, qualquer organização que criar um blockchain pode ser obrigada a remover um bloco ou modificar um dado pessoal se requerido por um indivíduo que queira ser esquecido. E como isso funcionaria? Para efeitos de reflexão, vamos olhar para a seguinte história. A popular base de dados de mainframe DB2 dá suporte à segurança de visualizações e mapeia os dados usados pelas aplicações. Cada visualização requer um usuário registrado no sistema. Geralmente isso seria uma ID específica do indivíduo, a qual recebe permissões para criar ou modificar este acesso de visualização. Eventualmente, este usuário pode mudar de função ou mesmo sair da empresa; caso isso faça com que a sua ID seja removida do sistema, automaticamente todas as funções de visualização associadas a ela deixariam de funcionar. As empresas precisariam manter ativas estas IDs para que não se perdessem estes acessos. Isto é um problema para auditores por conta da Lei Sarmanes-Oxley, de 2002, que exige que cada ID ativa no sistema esteja ligada a um usuário válido, conhecido e autenticado.
Ao se usar ferramentas de gestão de identidades (IdM na sigla em Inglês), estas IDs sem usuário automaticamente apareceriam como inválidas; neste caso, a melhor resposta é criar IDs “sintéticas”, ou seja, criar uma ID indireta, sem associação a um usuário real, e manter uma separação entre os dados e esta ID específica. Neste caso, ao se minerar um bloco, o usuário seria o “Corp-ID miner 31”, o qual poderia ser esquecido se quisesse sem prejudicar a estrutura do bloco, pois a ID sintética seria simplesmente designada a outro técnico, sem necessidade de mudanças no bloco em si.
Das mesma maneira, se fosse um registro médico associado à ID “Corp-ID Client 192734”; caso este indivíduo desejasse ser apagado do registro, bastaria à empresa transferir este identificação a uma ID nula, simplesmente eliminando a ligação entre essa pessoa e o bloco. Tome o seguinte ocorrido como exemplo. Em 1980 eu estava envolvido no planejamento de documentação no centro de desenvolvimento de software da IBM em Poughkeepsie, NY. Normalmente o pessoal ficava neste tipo de projeto no máximo um ou dois anos. Muitos laboratórios e departamentos dentro da IBM precisavam de informações dos planejamentos, mas ficar atualizando a lista de email com cada usuário ligado ao projeto que era substituído era uma tarefa cansativa e grava listas pouco confiáveis.
Em vez disso, criamos um email genérico como “MVS Lab Plan” que ficava sob a responsabilidade de quem quer que estivesse no cargo naquele momento, e seu suplente. Quando surgiam dúvidas, elas eram direcionadas ao e-mail genérico e quem recebesse dava atendimento ao caso (depois de identificar o requerente). É mais ou menos a ideia de números de serviço público: quando há emergência, você liga para 190, não para o telefone do delegado.
O GDPR não proíbe o blockchain, mas cria algumas exigências de procedimento de seu uso em escala comercial. Para indivíduos que entrem nesta cadeia, não lhes é dada a autoridade para modificar o bloco uma vez que é incorporado ao blockchain; para eles, é o princípio do caveat emptor, ou seja, recai sobre eles a responsabilidade de conferir a lisura de seu interlocutor. Para as organizações, tenha certeza de ter um mecanismo que permita que você desassocie um indivíduo de suas contribuições do bloco, seja como criador ou como alguém cujos dados foram registrados. Para ver mais discussões sobre como funciona o blockchain visite https://bitsonblocks.net/2016/02/29/a-gentle-introduction-to-immutability-of-blockchains/ e também http://blockchain.mit.edu/how-blockchain-works/ . Deixe seus comentários! E pode me seguir no Twitter em @WilliamMalikTM.
