Elon x Twitter: questões estratégicas das APIs e contas falsas no centro do conflito

Elon x Twitter: questões estratégicas das APIs e contas falsas no centro do conflito
Negócio virou um novelão imprevisível. Ilustração: Twitter/Loney-tunes; Montagem: R. Assef.

A audiência preliminar do caso Elon x Twitter está marcada para o dia 19 de julho. É o novo round do que seria o terceiro maior negócio da área da tecnologia, sendo somente inferior em valor às aquisições da desenvolvedora de jogos Activision Blizzard pela Microsoft (US$ 75 bilhões) e da empresa de armazenamento de dados EMC pela Dell (US$ 67 bilhões). Se não seria o maior em valor, já é o mais conflituoso.

Em abril, o bilionário Elon Musk, mundialmente conhecido por fundar e liderar empresas como a Tesla e a SpaceX, anunciou a compra da rede social Twitter por US$ 44 bilhões (R$ 238,5 bi). Em maio, suspendeu temporariamente a compra. Em julho, anunciou a desistência. Em apenas três meses, o negócio virou uma montanha-russa. O final será decidido pela Justiça americana.

Musk alega que a rede social não forneceu informações suficientes sobre as contas fake e isso é um descumprimento das cláusulas contratuais.  O advogado Mike Rindler  em carta dirigida ao diretor jurídico do Twitter reclama do não atendimento a questionamentos que quando foram finalmente respondidos as informações eram incompletas e inúteis. O Twitter nega a quebra contratual e acusa Musk de violar o acordo.

No centro da decisão pela desistência do negócio, está a discussão técnica e estratégica sobre as APIs ou Interface de Programação de Aplicações, traduzida da sigla em inglês. Vamos entender um pouco sobre o assunto do que está acontecendo (ou pelo menos tentar), até porque tudo indica que vai render.

O front das APIs

Os advogados de Musk reiteradamente reclamaram quanto ao nível de acesso aos APIs do Twitter, inclusive indicando que os desenvolvedores de outros clientes corporativos obtinham maiores limites. Isso para saber exatamente quantas contas são executadas por bots ou usuários inautênticos.

A rede social possui algo em torno de 230 milhões de contas. Admite menos  de 5%, ou 11 milhões,  de contas falsas,bots e spammers. É um número relativamente pequeno, considerada a dimensão da operação. Musk quer acesso aos dados para fazer uma avaliação independente e acusa o Twitter de não atender a sua reivindicação.

Segundo o portal da Forbes, a empresa prepara-se para dar ao investidor o acesso à API firehose para acesso a todos os tuítes postados que seriam aproximadamente 500 milhões por dia. Talvez isso satisfaça as exigências de Musk, mas tecnicamente parece pouco provável que seu time de desenvolvedores consiga analisar um volume tão grande de dados.

A alternativa poderia ser a API decadose, com disponibilização de 10% das entradas. Tudo também pode ser um blefe do Twitter, divulgado no mesmo dia de sua decisão de ingressar no judiciário e da recusa do megainvestidor em pagar a cifra original.  Quatro dias depois, a empresa ingressou na Justiça.

De qualquer forma, as APIs e contas falsas e bots estão na essência da disputa. Provavelmente, há outros interesses e estratégias no movimento dos dois players.

O que são as APIs?

Você já clicou em um número de telefone em um site e recebeu a opção de fazer a chamada via operadora do seu celular? É um exemplo de integração de sistemas permitido pelas APIs. É  um protocolo ou diretriz para conectar sistemas, softwares e aplicativos e no mais das vezes o objetivo é possibilitar a criação de novas funcionalidades  a automatizar processos que seriam manuais, como discar um número de telefone no exemplo mencionado.

Outros exemplos rotineiros são os serviços de rastreamento de encomendas e as previsões meteorológicas que aparecem no seu celular. Portanto, utilizamos as APIs mesmo ignorando a existência delas. A necessidade delas vai além de fazer sistemas diferentes “conversarem”. Servem para maximizar a experiência positiva do usuário ou cliente, com ganhos em eficiência e escalabilidade. São chamadas também de tradutores, justamente por intermediarem as funções de sistemas diversos.

A arquitetura de uma API é dividida entre cliente e servidor. Cliente é a aplicação que faz a solicitação e o servidor é o responsável pela resposta. Existem quatro formas de funcionamento de uma API a depender de quando e pelo que foi criada. Usualmente, uma API será baseada em SOAP (Simple Object Access Protocol) ou REST (Representational State Transfer). A  primeira é um protocolo e a segunda não é. E isso faz toda a diferença.

A SOAP é anterior à REST e limita  o envio e  resposta no formato XML. Sua sucessora é mais flexível  e se comunica  em diversos formatos, incluindo HTML e Java, e é mais leve.   Por suas características e funcionalidades , a REST é mais adaptada ao conceito de Internet das Coisas (IoT) pela interconexão de diversos objetos cotidianos com a rede de forma mais rápida.

Temos ainda o protocolo Websocket que, ao contrário do REST, é um protocolo com estado, ou seja, exige uma resposta específica do servidor, significando uma maior dependência na relação cliente-servidor e menor rapidez nas transações. A retenção das informações e das sessões anteriores também dependem do servidor, o que não é exigido em protocolos sem estado (Stateless Protocol) ou diretrizes como a REST. A quarta forma é o protocolo RPC que não vem ao caso no momento.

O mais importante é reter que no protocolo sem estado cada requisição ou mensagem é tratada como um evento independente e não há necessidade de armazenar os dados dessa comunicação exceto no caso de exigências legais ou investigativas.

Há que se observar que as APIs podem ser públicas ou privadas, compostas ou de parceiros. As primeiras são autoexplicativas. Quanto às demais, resultam na combinação de duas APIs e as acessíveis somente por desenvolvedores externos (parceiros).

O Twitter usa APIs justamente para que você possa acessá-lo a partir de dispositivos móveis e até mesmo por sua Smart TV, e usa a diretriz REST pelas peculiaridades  – rapidez, interconexão, menor complexidade, menor dependência com o servidor. E é claro, é uma API pública.

É, eu sei, entender é mais difícil que usar. Porém, precisei de todo um raciocínio para responder a seguinte questão: O que as APIs têm a ver com bots ou perfis fake, que impedem a conclusão da aquisição do Twitter segundo Elon Musk? É que trataremos a seguir.

Fato ou Fake?

Há duas características REST que podem ser interessantes para perfis fake e, principalmente, para bots. Primeiramente, é preciso dizer que bot não é sinônimo de spam ou de conteúdo fake ou malicioso. São programas bastante úteis, rodados em redes sociais para divulgar notícias, campanhas de saúde e auxiliando na interação como na timeline do Facebook. Portanto, banir os bots não é uma opção.

 No Twitter executam interações simples, como retweetar. Bots maliciosos espalham informações erradas, manipulam opiniões, estimulam fraudes financeiras, atiçam conflitos, influenciam eleições. Como as entradas no microblog são consideradas eventos independentes em um protocolo sem estado, fica mais difícil rastreá-los. Outros desafios técnicos para sua detecção incluem rostos gerados por inteligência artificial em seus perfis e contas coordenadas.

As espécies de contas podem se sobrepor. Um bot pode ser criado para postar spam. Então podemos ter uma conta falsa que é, ao mesmo tempo, bot e spammer, mas nem sempre. O grau de dificuldade de identificação  e eliminação é imenso. Para combater as ameaças, investimentos em novas tecnologias é fundamental.

Contas hackeadas, compradas ou alugadas e troca de identificadores compõem um cenário de pesadelo na luta contra o uso irresponsável ou criminoso do microblog.

Daí o ceticismo de Elon Musk sobre a estimativa de 5% de bots e fakes nos servidores do Twitter. Seriam aproximadamente 11 milhões de contas entre 200 milhões. Dadas as dificuldades técnicas, parece razoável duvidar desse número.

Porém a recusa em concluir o acordo pode acobertar outra intenção. Em maio, Musk declarou que o Twitter valeria menos devido justamente ao número de contas falsas e bots. Outro fator com possibilidade de influenciar a decisão é a queda geral dos valores das companhias baseadas em tecnologia. Com essas variáveis, é provável que o megainvestidor queira negociar abaixo da oferta inicial de compra.

Outra linha de frente apareceu na própria ação judicial. Musk acusa o Twitter de acelerar o processo. Prefere que o julgamento aconteça no final de fevereiro de 2023. Alega a complexidade dos fatores envolvidos. Realmente, chegar a um número aproximado de bots e spammers parece algo inatingível.

O Twitter, ao contrário, tem interesse em resolver a questão logo, até setembro. Isso para não deixar a companhia pendurada numa negociação arrastada de longo prazo. Suas ações tiveram uma queda de 11,25% após o anúncio do fundador da Tesla. Com certeza, Parag Agrawal, CEO do Twitter, e seus executivos e acionistas temem mais prejuízos.

A juíza do caso da Chancelaria de Delaware tem histórico de ordenar a conclusão de acordos. Sob quais serão as bases é uma incógnita. Pode manter o valor acordado, um risco considerável para Musk, ou pode redefinir o valor entendendo justas as alegações do bilionário.

Pode também suspender o acordo, mas parece improvável. O fato continua sendo impossível saber o que sai da cabeça de um juiz, tanto por aqui como nos EUA. E o caso virou um novelão que vale a pena acompanhar


Quer escrever na Prensa?

Junte-se a uma comunidade de Creators que estão melhorando a internet com artigos inteligentes, relevantes e humanos. Além disso, seu artigo pode fazer parte do Projeto de Monetização, e você pode ganhar dinheiro com ele!

Clique aqui para se cadastrar e venha com a gente!


Topo