Você está acessando os arquivos da categoria Relatórios ICANN.

Relatório BC Fevereiro 2021

(*) Nivaldo Cleto

Já há alguns anos a ICANN se esforça para se adequar à General Data Protection Regulation (GDPR) da União Europeia, que trouxe uma demanda maior por privacidade de todos aqueles que possuíssem clientes europeus, e uma subsequente necessidade de um maior cuidado com os dados guardados no banco de dados WHOIS, que contém as informações pessoais dos donos de qualquer domínio que faça uso de um TLD genérico (como “exemplo.org”). O conflito dos diferentes interesses faz com que o processo se arraste sem previsão de término, apesar de certo progresso ter acontecido recentemente.

No entanto, a União Europeia possui o objetivo claro de estabelecer maior protagonismo na era da informação do que anteriormente, e já prepara um novo conjunto de leis que também terão alcance transnacional, conhecido como Digital Services Act Package (DSA). Se a lei anterior tratava de privacidade e afetava as empresas de maneira indireta, a nova proposta é especificamente direcionada a regular a atuação dos empreendimentos que façam negócios dentro do bloco.

Dentre as propostas trazidas pelo DSA, muitas que devem se tornar lei em 2 ou 3 anos, existe um tema comum da demanda por uma maior cobrança por transparência nas operações das empresas, particularmente daquelas consideradas como “plataformas”, como é o caso das grandes mídias sociais. Se tornará necessário que essas empresas sejam muito mais claras com as autoridades europeias a respeito de como seus sistemas operam e como decisões são tomadas em relação a conteúdo.

O DNS em si é citado diretamente e existe uma série de provisões associadas ao sistema, algo que chamou a atenção da comunidade ICANN. Diversas questões são abordadas na parte de segurança digital da proposta, e demandam acompanhamento sério e clareza no que significam. O foco está na diretiva conhecida como NIS 2, que se aplica a todos atores da cadeia de resolução do DNS, ou seja, todas as partes contratadas da ICANN.

Algo que é explicitamente articulado é que há uma obrigação da manutenção de um banco com os dados como os do WHOIS, com a diferença de ele ser privado. Além disso, algo vigorosamente debatido nos últimos anos pela comunidade aparece de maneira absoluta na proposta: é necessário que os dados sejam acurados. Ou seja, os registrars ou revendedores possuem sim a obrigação de garantir que os dados que estão no banco de dados são legítimos, algo que mudaria drasticamente a dinâmica de registro de nomes de domínio.

Outro ponto importante é o de que registrars passariam a ser requeridos não apenas acatar notificações de conteúdo indesejado de autoridades nacionais e suas forças policiais, mas também seriam forçados a manter um canal aberto de reclamações para o público geral, o que também modificaria a dinâmica do funcionamento do sistema e abriria muito mais espaço para, por exemplo, ações de ativismo, o que por sua vez necessitaria a contratação de mais funcionários ou terceirizados para lidar com o influxo.

Se a ICANN foi surpreendida com a GDPR, a intenção como DAS parece ser de antecipar ao máximo o possível o que pode vir a acontecer. A comunidade e a organização parecem estar em alinhamento de que é de alta prioridade monitor o desenvolvimento dessas leis, algo que é um sinal positivo.

 

(*)  Nivaldo Cleto é membro do Comitê Gestor da Internet no Brasil e da ICANN Business Constituency

Relatório janeiro BC

(*) Nivaldo Cleto

Começamos os trabalhos de 2021 da Business Constituency (BC) com uma ação inovadora para o grupo, que é a de trazer a voz do empresariado de tecnologia envolvido na ICANN para processos externos que tenham impacto direto nos temas sobre os quais deliberamos. Nesse caso, submetemos uma carta para a Mozilla em resposta ao “Mozilla DNS over HTTPS (DoH) and Trusted Recursive Resolver (TRR) Comment”.

Antes de explicar o teor de nossos comentários, é importante lembrar do que se tratam as questões de DoH e TRR. A tecnologia de DNS over HTTPS (DoH) surgiu como uma resposta ao crescente número de incidentes de crime cibernético, e essencialmente faz com que os pedidos enviados por um usuário para o acesso a um nome de domínio qualquer sejam feitos de forma encriptada.

No entanto, o que torna esse padrão particularmente interessante (e potencialmente problemático) é que essa encriptação é feita misturando os pedidos de acesso a nomes de domínio com o tráfego do protocolo HTTPS, que é a forma encriptada de se requisitar informações de um website e, hoje em dia, já se tornou padrão para a maioria dos websites. O resultado disso é que se torna difícil para uma parte externa interceptar ou tentar identificar o que está acontecendo dentro daquela conexão em geral.

Para processar esses pedidos de acesso a nomes de domínios encriptados, é necessário enviá-los para um resolvedor capaz de lidar com a tecnologia DoH, um serviço no momento oferecido por algumas grandes empresas como Cloudflare e Google, além de uma pequena quantidade de grupos de porte menor. Conforme a Mozilla se encaminha para tornar o DoH, o mecanismo padrão em todas as do browser Firefox, ela está desenvolvendo uma lista de Trusted Recursive Resolver (TRR). Essas são entidades que adotam certos compromissos de ética e privacidade descritos aqui.

Em princípio, isso gera um resultado positivo de aumento de privacidade e confiabilidade para o usuário final. Por outro lado, questões importantes tem de ser levantadas. Primeiro, o resolvedor vira um poderoso agregador de dados, que sabe o que o usuário acessa enquanto o próprio provedor de serviços de Internet (ISP) do usuário não sabe. Além dos riscos de tornar alguns algumas gigantes ainda mais fortes, em diversas partes do mundo (o Brasil incluso), o ISP precisa manter os dados de acesso de seus clientes para uso policial. Certos países também fazem a censura de certos websites em nível nacional, algo que é subvertido pelo DoH. Também existem diversos outros temas, como mecanismos de controle parental, que não mencionaremos por questão de brevidade.

Atualmente a lista de Trusted Recursive Resolvers da Mozilla conta com três nomes: Cloudflare, Comcast e NextDNS. Desses, o padrão do browser é utilizar a Cloudflare, com a qual já estão em parceria há diversos anos e que garante que trata com muita seriedade a privacidade do usuário, algo que de modo geral é respaldado pela reputação da empresa. A consulta da Mozilla trata exatamente de entender quais critérios devem ser cobrados de futuros TRRs.

Em nossa opinião, é importante que se olhe para as normas estabelecidas dentro do contexto da ICANN, onde a comunidade global se reúne para estabelecer regras relativas a nomes de domínios. Tendo há muitos anos representado os interesses dos pequenos e médios empreendedores dentro desse espaço, já observamos vitórias e derrotas para o setor, mas a questão é exatamente que existem processos que podem ser acompanhados e influenciados. Um resolvedor operando DoH pode alterar ou desconsiderar decisões tomadas pela comunidade ICANN sem dever maiores explicações para ninguém, algo que vemos como negativo.

Por isso saudamos a iniciativa da Mozilla e trazemos comentários que consideramos importantes para o processo. Segue abaixo a tradução para o português de nossa carta originalmente submetida em inglês, cuja escrita foi liderada pelos empresários brasileiros da BC:

 

“É um prazer contribuir para esta consulta pública que está sendo realizada pela Mozilla, e gostaríamos de elogiar os esforços da organização para avançar os debates sobre este importante assunto.

A comunidade da ICANN tem se concentrado por mais de duas décadas no desenvolvimento de políticas para o DNS por meio de processos ascendentes baseados em consenso, usando o modelo de múltiplas partes interessadas para alcançar o equilíbrio entre diferentes pontos de vista e chegar a consensos satisfatórios.

Reconhecemos o valor da inovação e do desenvolvimento de novas tecnologias, como DNS over HTTPS (DoH), que têm o potencial de aumentar a privacidade das consultas DNS.

Por outro lado, também vemos alguns de seus aspectos como preocupantes. Em particular, queremos destacar a legitimidade do desenvolvimento de políticas baseadas em consenso em órgãos técnicos e de participação múltipla, como a ICANN.

Estamos de acordo com nossos colegas do Comitê Consultivo At-Large da ICANN (ALAC) que ‘está claro que o DoH pode ter um impacto direto no DNS e no sistema de servidores raiz que a ICANN apoia’.

Na ‘Security/DOH-resolver-policy’ da Mozilla, em ‘Blocking & Modification Prohibitions’, reconhecemos que é afirmado que ‘A parte que opera o resolvedor não deve, por padrão, bloquear ou filtrar domínios, a menos que especificamente exigido por lei na jurisdição em que opera o resolvedor.’

No entanto, isso não contempla totalmente o escopo das decisões meticulosamente tomadas pela comunidade da ICANN. Nós também, por exemplo, supervisionamos a adição de entradas à zona raiz, algo que não é considerado atualmente pelas políticas da Mozilla.

É nossa principal intenção com este comentário destacar a importância do cumprimento das decisões multissetoriais tomadas pela comunidade da ICANN, para que possamos manter uma Internet única e interoperável.

É também digno de nota para vários de nossos membros que essas tecnologias podem impactar significativamente a capacidade dos ISPs de cumprir as obrigações legais e regulamentares de seus governos regionais, sejam elas relacionadas a registro de atividades, proteção de propriedade intelectual, controles dos pais, cibersegurança ou qualquer propósito. Este é um assunto que precisa ser esclarecido no futuro, para evitar consequências não intencionais, como a evasão forçosa ou tentativas de bloqueio do DoH por atores estatais.

Diante de tudo isso, convidamos a Mozilla a considerar a importância de criar mecanismos para garantir que provedores de DoH (ou similares) confiáveis ​​não se desviem do consenso da comunidade global e preservem a obrigação de aderir a essas políticas.

Obrigado pela oportunidade de comentar sobre este assunto.”

 

(*)  Nivaldo Cleto é membro do Comitê Gestor da Internet no Brasil e da ICANN Business Constituency