~rlafuente

Bots de Mastodon: o que são, como fazer, e a botiqueta

Tecnicamente, um bot é uma conta que publica toots automaticamente, seja de forma regular ou em reacção a determinados sinais.

Na prática, são tão mais do que isso. A possibilidade de fazermos mini-máquinas de publicação automática veio mostrar-nos o seu potencial prático, humorístico, artístico, humano e até poético. Existe até uma instância dedicada exclusivamente a bots.

Os que por aí andam

Há os bots ferramenta que podemos mencionar para fazerem algo por nós, como imortalizar citações, reconhecer o texto de uma imagem ou aplicar filtros em fotografias.

Existem também bots que publicam regularmente textos gerados de forma mais ou menos aleatória, que vão das experiências mais simples até demonstrações notáveis de criatividade e escrita conceptual -- sobre isto, as obras da Allison Parrish e do Darius Kazemi são imperdíveis. E se formos para além do texto, há resultados deliciosos.

Finalmente há os bots que publicam de acordo com fontes externas, re-publicando alertas e emergências, previsões do tempo; ou então, ligados a API mais sofisticadas, dá para jogar xadrez por votação ou detectar aviões a passar por cima de uma certa localidade.

(esta não é de todo uma taxonomia formal ou sequer séria; se tiveres outras ideias sobre como discriminar entre tipos de bots, gostava de ouvir)

Como fazer um

Existem recursos para criar bots sem recorrer a código; no Twitter havia vários que nunca realmente explorei, porque com Python dá para fazer tudo. No Mastodon ainda não me sentei para andar à procura, mas gostava de saber o que por aí há.

Sujar as mãos com código dá-nos outro tipo de superpoderes. Para pôr a rolar um bot, precisas de acesso a uma shell; podes aproveitar um computador que tenhas sempre ligado, ou então usar um serviço que te dê acesso a uma shell SSH. Os comandos aqui destinam-se a sistemas GNU/Linux, mas devem também funcionar em Mac (não me perguntem pelo Windows).

Começamos por instalar localmente o módulo que nos dá os poderes de interagir com a API da tua instância. Há várias formas de instalar o módulo do Mastodon, como num Virtualenv, mas esta é a mais simples e rápida:

pip install --user mastodon.py

Depois, cria um ficheiro bot.py e cola este pequeno pedaço de código:

from mastodon import Mastodon
mastodon = Mastodon(access_token=MASTODON_ACCESS_TOKEN,
                    api_base_url=MASTODON_API_BASE_URL)
mastodon.status_post(text, visibility='unlisted')

É tudo o que é preciso! Vamos por partes:

• depois de importar, criamos o objecto mastodon que podemos usar para interagir com a API do Mastodon
• substitui o campo MASTODON_ACCESS_TOKEN pelo token de acesso que te foi dado quando registaste a aplicação na API da tua instância
• substitui o campo MASTODON_API_BASE_URL pelo endereço da instância
• o post é feito com a visibilidade não-listada para não interferir com as timelines locais -- já explico melhor.

Finalmente, coloca o script a correr regularmente num cronjob; corre o comando crontab -e e acrescenta a linha

@hourly /path/para/o/teu/bot.py

E está a rolar! Antes de activares o cron, corre o script um par de vezes para assegurar que está bem.

Botiqueta

Há uns anos a ~aiscarvalho e eu demos um workshop de bots de Mastodon (e de Twitter, mas passado é passado). Éramos uma dúzia a criar geradores de texto e fomos para o masto.pt pôr os nossos bots a cantar, o que arreliou bastante o administrador da instância: ele tratou de silenciar os nossos bots porque estavam a poluir a timeline local. À primeira ficámos irritados, então estávamos a trazer coisas tão giras e vêm logo assim. Mas depois lá concordámos que devíamos ter perguntado primeiro, pedimos desculpa e fomos ler sobre isso das timelines locais.

A timeline local é o ponto de cada instância onde se podem ler todos os toots públicos feitos por pessoas que dela fazem parte. É um sítio especialmente bom se estiveres numa instância temática, regional ou local, porque se encontram facilmente novas contas a seguir, e dá para conversas mais recatadas.

Ora, se um bot começa a emitir um ou mais toots a cada hora, começa a dominar a timeline local e a dificultar a leitura do resto, obrigando cada pessoa a silenciá-lo individualmente. Daí na maioria das instâncias existirem normas sobre toots não-listados -- as situações onde se deve evitar fazer toots públicos, como nos vários toots de um thread (o primeiro deve ser público, os seguintes não-listados) e quando existe política de bots, é quase sempre imposto que não façam toots públicos.

Este é o primeiro ponto do que tentámos condensar na Ciberlândia como as boas práticas de construção de bots:

1. Apenas fazer toots não-listados
2. Assinalar no perfil que a conta é um bot (há uma opção para isso)
3. Se o bot fizer upload de imagens e vídeos, contacta os admins da instância

O ponto 2 serve para discriminar os tipos de conta nas estatísticas da instância e permitir distinguir claramente quando uma conta é um bot.

O ponto 3 prende-se com as duras realidades do alojamento: afixar um vídeo de 2MB por dia dá 730 MB por ano, o que é um peso razoável na conta mensal de alojamento. Os admins da tua instância podem ajudar-te a encontrar alternativas de alojamento ou métodos de compressão que possam facilitar a vida a todos os envolvidos.

Portugal adopta o bot

Na Ciberlândia damos as boas-vindas a bots interessantes, criativos e/ou úteis. Se tiveres interesse na arte de engendrar estas geringonças de publicação automática, há espaço para experimentar e gente por perto para tirar dúvidas.

E se souberes de bots interessantes em português ou outras formas promissoras de engendrar bots, manda-me um toot. (o mesmo para erros que possa ter feito e sugestões técnicas!)

Novo post

Já ao tempo que quero tirar o pó a este blog e voltar à prática de escrever publicamente sem complexos.

E claro, já vão meses desde que a vontade está aí, mas já explorei meia dúzia de estruturas de post e terminar algo fica sempre para o dia seguinte.

Por isso zás, segue este post para desbloquear e espero que resulte.

Pensar antes de instalar

E de repente, uma solução: as apps de rastreamento de contacto estão na ordem do dia. É boa ideia instalar?

Estão a chegar: as apps de rastreamento de contactos (ARCs) são apresentadas como uma possível esperança na luta contra o covid-19, como uma forma de nos prevenirmos coletivamente, e como um meio de reforçar o esforço epidemiológico para analisar o alastramento da doença. No entanto, elas levantam muitas questões que põem seriamente em causa a sua capacidade de corresponder a esses objetivos.

Uma das primeiras preocupações foi se uma ARC poria em causa a privacidade das pessoas, expondo o seu estado de saúde ou mesmo localização a sabe-se lá quem, e para isto surgiram um conjunto de abordagens com a privacidade como preocupação. Essas abordagens "privacy-first" têm procurado alguma consciência sobre as implicações de privacidade, embora não sejam apenas dessa ordem as consequências nefastas das ARCs. Neste tipo específico de ARCs que têm em conta a privacidade inclui-se a ARC desenvolvida pelo InescTec, que tudo indica que receberá o aval do governo português. Estas ARCs "amigas da privacidade" correspondem a um esforço genuíno de limitar o seu alcance, face a alternativas grotescas baseadas na geolocalização e cruzamento de dados, como no Reino Unido. Mas mesmo com essa preocupação, elas contêm riscos sérios que não são resolúveis tecnicamente.

Antes de entrar pelo lado técnico, importa ter o retrato total da problemática à volta das ARCs. É que neste momento as pessoas estão desesperadas por uma solução para o momento em que vivem. Estão desempregadas, com a integridade psicológica em risco, lidando com dramas familiares, sem capacidade de cuidar dos filhos a tempo inteiro ao mesmo tempo que trabalham à distância. O óbvio desespero que tais cenários motivam leva a uma adesão imediata a qualquer réstia de esperança numa solução mágica. As ARCs aparecem aqui como a esperança possível, que irá motivar muita gente a instalar uma app cuja eficácia não está de todo demonstrada e cujas consequências podem ser muito graves.

Os falsos positivos e negativos

Os modelos de ARC que estão a ser desenvolvidos recorrem ao Bluetooth para evitar o recurso à geolocalização (que exclui o anonimato). São medidos os "contactos" entre telemóveis, ou seja, os momentos em que dois aparelhos estão próximos durante um tempo suficiente para ser considerado um potencial contacto. Mais tarde, quando alguém é marcado como tendo covid-19, as pessoas com quem contactou receberão notificações do facto, sem haver transmissão direta da identidade das pessoas. Mesmo salvaguardando o anonimato, há um pormenor que não há como contornar: o falso positivo ou falso negativo.

É que o Bluetooth está longe de ser uma tecnologia milimétrica, e não foi desenhada para medir distâncias entre pessoas. Há "contactos" a 5 metros que podem ser registados, e contactos reais de meio metro que não o vão ser. Para complicar, o Bluetooth atravessa barreiras, registando um contacto mesmo quando há uma barreira de plástico, ou mesmo uma parede, entre as pessoas, registando um falso positivo. Será um cenário frequente em apartamentos: quantas vezes já vimos a coluna ou a TV do vizinho quando ligamos o Bluetooth no telemóvel para procurar aparelhos à nossa volta?

Podemos antever o resultado: uma rede de contactos falsa e incompleta, de utilidade epidemiológica muitíssimo questionável por conter tantos falsos positivos e negativos. Mas há uma consequência muito mais grave: muitas pessoas receberão notificações de contacto que não ocorreu na realidade. Não houve exposição, mas a notificação será enviada. As pessoas ficarão ansiosas, muitas a colocar-se em auto-quarentena até poderem realizar um teste, com implicações psicológicas e familiares que se somam ao tremendo stress que já todos sofremos. Se pensarmos que muitos destes casos serão falsos alarmes, está-se assim a criar uma nova fonte de ansiedade profundamente desnecessária, num momento em que ninguém no país precisa de mais.

O uso "voluntário"

Quando ligamos à nossa operadora de comunicações para resolver uma questão técnica, a voz automática informa-nos de que a chamada será gravada e, se não consentirmos, que temos de recorrer aos meios de comunicação alternativos. Em tempo de pandemia, o meio de contacto presencial está excluído. Se o nosso problema necessitar de resolução urgente, não confiaremos no e-mail para obter uma resposta célere, e a única forma que temos à disposição de obter uma resposta imediata é consentir na gravação da chamada.

É assim que algo que surge como uma aparente escolha, com consentimento informado, se torna na verdade uma discreta imposição para aceitar condições que não admitiríamos noutra circunstância. É este fenómeno que também vai ocorrer com as ARCs e o seu carácter de adesão voluntária. É perverso argumentar que quem não quer, não precisa de aderir.

Olhemos para o que se passou na Índia, onde existe uma ARC promovida pelo governo, de uso voluntário. Muita gente está a ver barrada a sua entrada em farmácias, onde só se entra quando se mostra que a app está instalada no telemóvel. Os estafetas de entrega de refeições do Zomato são obrigados a ter a app instalada, senão não podem trabalhar. Alguns condomínios vedam o acesso a serviços aos condóminos que não provam ter a app instalada, e provocam o maldizer de vizinhos em relação a quem prefere não instalar.

Resumindo: é voluntário, mas obrigação existe de facto, na forma que a app se torna mediadora do acesso que temos a serviços essenciais, trabalho e ao nosso próprio domicílio. Nota-se muito a falta de qualquer contributo sociológico, etnográfico ou filosófico na concepção das ARCs, uma omissão que tem de ser destacada: é mais uma lacuna motivada por uma vontade solucionista de focar o debate nos pormenores técnicos e minimizar o valor de qualquer outro ângulo. Esta leveza na apresentação das ARCs como de uso "voluntário" tem de ser questionada.

Big brother? Não é bem isso

Vários dos proponentes das ARCs têm avançado o mesmo slogan de que "não se trata de um Big Brother". Têm razão, e devemos evitar a fácil condenação de que correspondem a uma conspiração por parte do Estado (ou privados) que apenas procuram um pretexto para acumular poder. Tem a ver com o desespero que tanto cidadãos como políticos estão a sentir na falta de qualquer solução mágica. A Comissão Europeia faz parte deste grupo desesperado: estava até há bem pouco tempo sob fortes críticas de não conseguir coordenar uma resposta conjunta à crise, até aparecer o pretexto das ARCs, que estão agora a ser propostas (e quase impostas) sem testes, análises profundas ou sequer uma especificação do valor real dessas apps. Tem de ser e pronto.

Esta é a doutrina solucionista: reduzir os problemas complexos a cenários preto e branco que só podem ser resolvidos com soluções tecnológicas. Essa doutrina reduz o discurso aos pormenores de implementação e descarta qualquer consideração fora dessa esfera. Neste caos em concreto, ela propõe falsamente uma dicotomia entre a app e o confinamento, ou em sentido mais lato, entre a salvação e o marasmo. Podemos recordar que antes de se falar de ARCs, a linha comummente aceite era que até à cura ou vacina não encontraremos soluções mágicas. Agora a solução existe -- uma ARC -- muitas vezes sem qualquer menção concreta das suas vantagens. Ela é apresentada como algo que tem de ser. A sua introdução contempla pouco ou nenhum debate. Não podemos, mesmo com a ansiedade coletiva em busca de soluções, apressar adoções em massa com implicações sociais fortes.

Temos ainda demasiado poucas pistas para o que aí vem, considerando que estamos a definir o precedente para o nosso futuro próximo: aceitaremos apps e engenhos tecnológicos como forma de mediação social? O Primeiro-Ministro, na sua entrevista recente na RTP, não sugere uma solução vinda do Estado, mas um ecossistema de apps de uso voluntário. Seria ótimo termos em mãos a informação sobre o que se pretende implementar em Portugal, mas não existe ainda qualquer documento formal a descrever o que se está a preparar, apenas comentário de imprensa. Não pode ser assim, se estamos a falar de uma decisão sócio-política com implicações que ainda não conseguimos quantificar enquanto sociedade, mas cujo desfecho definirá as nossas existências nos tempos que aí vêm.

Há ainda outros focos de preocupação que o espaço deste artigo não chega para albergar. Estamos na D3 a preparar um recurso para ajudar cada pessoa a decidir se é boa ideia instalar ou não a app: o rastreamento.pt ainda está a ser montado, mas dá para deixar lá o e-mail para receber um aviso quando estiver pronto, e assim poder ter os factos no sítio na altura de decidir se é boa ideia instalar uma app destas ou não.

tags: ARCs

Dicionários visuais com emoji no Inkscape

Uma vez, ao usar o telemóvel com o Eduardo (o nosso filho de 2 anos) ao lado, deu para reparar no interesse dele nos emoji. Experimentámos deixá-lo brincar com o teclado do ecrã um par de vezes e ele entusiasmou-se bastante a selecionar e a procurar mais emoji, dizendo os objetos que reconhecia. Noutra altura mais tarde, ocorreu-nos que as várias categorias e diversidade nos emoji podiam ser uma boa base para treinarmos o vocabulário com ele, em vez de dependermos de livros infantis de vocabulário cujas escolhas editoriais nos costumam deixar perplexos.

Durante a sesta de hoje, começámos à procura. Não encontrámos modelos prontos a imprimir numa rápida pesquisa, e percebemos que era melhor construirmos os nossos próprios. A seguir decidimo-nos a encontrar forma de usar o Inkscape (a nossa ferramenta preferida para design vetorial) para dispôr graficamente os conjuntos de emoji, mas não se mostrou trivial empregar fontes de emoji.

Encontrámos uma boa surpresa numa package pronta a instalar em Debian: inkscape-open-symbols. É um conjunto extenso de coleções de ícones de vários tipos, colocados à disposição na paleta de símbolos do Inkscape – um recanto desta ferramenta que não conhecíamos ainda. A coleção do inkscape-open-symbols é impressionante, incluindo pictogramas da AIGA, símbolos de diagramas elétricos ou ícones vindos do Material Design, Wordpress, GitHub e outros – todos eles recursos que nos vão dar jeito um dia. E, claro, lá encontramos os emoji da coleção Emoji One[^1].

Uma pequena amostra do que a coleção do inkscape-open-symbols nos tem para dar.

Antes de ele acordar da sesta, conseguimos fazer o layout de duas páginas e imprimi-las, uma com emoji relativos à alimentação e outra com meios de transporte. Foi útil podermos compôr a nossa versão e lidar com algumas das decisões editoriais que não esperávamos encontrar: Incluímos fast food e doces que ele não conhece, como hamburgeres ou donuts? Na falta dos autocarros dos STCP que ele conhece, é melhor usar uma camioneta ou um "school bus" amarelo à americana? Os livros não nos costumam dar a escolher, e valeu a pena o trabalho adicional para conseguirmos acabar com algo mais familiar e mais nosso.

Os emoji são uma condensação injusta e demasiado concisa da diversidade do mundo – falta lá encontrar um prato de bacalhau ou rissóis, limusines (ele adora) ou trotinetes. Apesar disso, para este modesto fim que procurávamos hoje, deram muito jeito depois de os imprimir e prender na parede.

[^1]: Uma outra descoberta deste empreendimento foi que a coleção EmojiOne passou a chamar-se JoyPixels e deixou de ser livre, com os acrescentos feitos desde esta mudança a ser sujeitos a licença paga. Como o conjunto original continua de acesso livre, serve para os nossos propósitos atuais, mas é uma pena. Outros virão.

Relatos de pedagogias remotas

Tal como todos os professores, fui recentemente confrontado com a urgência de passar a um modelo de ensino à distância. E tal como a maioria, encontrei-me muito pouco preparado para essa transição de emergência. Volvido mais ou menos um mês desde o momento em que se tornou claro que teríamos de dar aulas à distância, aproveito agora para documentar alguns dos princípios, reflexões e conclusões que estão a motivar a minha metodologia para esta estranha forma de fazer escola.

Algum contexto antes de continuar. A Ana Isabel Carvalho e eu começámos em setembro a dar aulas no departamento de Design de Comunicação da ESAP, com disciplinas dedicadas ao design na web. Neste semestre, estou eu a dar uma cadeira sobre design de interfaces, após uma introdução ao código na web no primeiro semestre, enquanto que a Ana leccionou uma cadeira de projeto e design para a web. Estar apenas eu a dar aulas neste semestre revelou-se um acaso afortunado para as coisas correrem menos mal -- a quarentena imposta mais tarde fez com que um de nós tivesse de estar mais presente nos cuidados ao nosso filho. Nesses entretantos, a Ana e eu fomos trabalhando bem mais do que seria saudável para conseguir chegar a um sistema de aulas à distância que pudesse ser sustentado durante um par de meses (um cenário pessimista na altura, mas agora revelou-se acertado). Apesar de ser eu quem está a dar as aulas e a acompanhar os trabalhos, toda a construção dos sistemas e métodos que vou descrever neste e em futuros posts são um sério trabalho de equipa.

Após algum nervosismo inicial, o diretor do curso deixou-nos à vontade para ensaiar e avançar com as metodologias que sentíssemos adequadas. Daí, tentámos endereçar esta situação como um problema de design. Sabíamos já que vários alunos estavam com as suas rotinas despedaçadas e alguns ainda a ter de trabalhar em empregos muito exigentes, particularmente em época de crise. Também vimos como primeira prioridade assegurar a privacidade e integridade de quaisquer plataformas que empregássemos, obrigando a olhar para além das soluções "cloud" do costume. E finalmente, sentimos necessidade de questionar e ir mais além do que os modelos convencionais de e-learning, com plataformas holísticas que tentam mediar todo o processo de aprendizagem e avaliação (Moodles e afins).

A nossa experiência de vários anos a trabalhar à distância enquanto designers com clientes no estrangeiro tem sido particularmente útil. O nosso contacto com a área do jornalismo de dados também nos familiarizou com os MOOCs, de eficácia variável mas que introduzem muitos novos métodos e tácticas de transmitir conhecimento por via digital. Com isto, sentimos que poderíamos analisar as partes do processo pedagógico, retirar as que não nos servem, e idealizar metodologias e workflows que pudessem responder à necessidade de uma framework estável que pudesse sustentar as nossas aulas online.

Assim, identificámos um conjunto de premissas a que precisaríamos de dar resposta:

• Assincronia. Mesmo mantendo as rotinas pré-crise e propondo a continuação de aulas à mesma hora que o habitual, é preciso dar resposta a quem não pode estar presente -- não é preciso enumerar os casos e possibilidades em que pessoas confinadas podem ter os seus planos e prioridades alterados. Por isso, procurámos formas que não prejudicassem quem não tem um horário regular, e permitir nesses casos o acesso a tudo o que se passou antes, ao ritmo possível de cada pessoa.
• Software livre e open source. Já há mais de uma década que usamos exclusivamente ferramentas livres nos nossos contextos profissionais, artísticos, pessoais e experimentais. Sabíamos existir uma boa variedade de ferramentas promissoras vindas da comunidade livre; sabemos também das estratégias questionáveis de entidades proprietárias que disponibilizam ferramentas atractivas (Zoom, Google Classroom, MS Teams, entre muitos outros) que apresentam também riscos para a privacidade e autonomia. Por isso, a nossa escolha recairia sempre em ferramentas cujo código é aberto e cuja reutilização é livre.
• Autonomia e self-hosting. A única forma de termos controlo sobre as ferramentas que usamos é, para além de evitar soluções proprietárias e preferir o open source, tê-las instaladas nos nossos próprios servidores. Por sorte, tínhamos acabado de adquirir um computador desktop decente para o nosso escritório cuja utilidade ficou limitada com a quarentena, pelo que podíamos utilizá-lo como servidor para alojar as plataformas que precisássemos -- e foi neste ponto que a nossa experiência com o self-hosting (instalar e manter plataformas no nosso próprio servidor) se mostrou preciosa. Poderíamos ter enveredado por um alojamento convencional na cloud que nos pouparia algumas dores de cabeça, mas não pouparia a carteira. Como tínhamos o computador à mão, foi uma possibilidade que aproveitámos.

O self-hosting é uma estratégia trabalhosa: foram precisas várias dezenas de horas para montar, configurar, afinar, colocar no ar e desenhar tácticas de manutenção para cada uma das ferramentas que usamos. No final, a recompensa é um sistema que controlamos integralmente, sem dependência de fornecedores, e com total autonomia: sabemos onde estão os nossos dados (e os dos nossos alunos), sabemos que estão seguros -- não totalmente porque há sempre possíveis riscos, mas bem mais do que se confiássemos num serviço cloud com servidores do outro lado do mundo e termos de serviços profundamente armadilhados.

Vou tentar detalhar nos próximos posts os pormenores da nossa implementação técnica, mas importa já expôr as ferramentas que adotámos:

• Rocket.chat para conversa em texto, do mesmo tipo de plataforma que o Slack. Esta tem-se revelado fundamental como alternativa a aulas por videoconferẽncia, que sentimos ser um meio limitado que não responde à premissa da assincronia (um assunto a desenvolver num post em breve). A esta plataforma chamámos "Recreio": porque na escola é o local onde nos reunimos em caso de emergência, mas também devido a uma expressão popular de que às vezes se aprende mais no recreio do que na sala de aula (um pouco taxativa, mas a mensagem é que no recreio também se aprende!).
• Um mini-site com vídeos que vamos gravando com os conteúdos programáticos. Dos MOOCs retirámos a conclusão que vídeos curtos (máx. 15 min) a expôr assuntos individuais são o melhor formato para este tipo de meio. Recorremos ao OBS (Open Broadcasting Studio) para os gravar, VidCutter para os editar e cortar, ffmpeg para converter para mp4, e um gerador de sites estáticos que escrevemos para os publicar.
• Um Raspberry Pi com um webserver para os alunos poderem publicar os seus trabalhos. Como a área das nossas disciplinas é a web, é algo que precisávamos e que, felizmente, já havíamos implementado e testado no primeiro semestre com os alunos, pelo que já estava tudo no sítio para continuar.
• Open Streaming Platform para transmitir diretos, um formato mais próximo do Twitch ou Youtube Live do que da videoconferência tradicional. Inicialmente, pareceu uma possibilidade útil para aulas à distância, mas foi rapidamente suplantada nos nossos planos pelo Recreio/Rocket.chat. Mesmo assim, vamos fazer experiências mais à frente para determinar se é um formato com potencial de complemento para as outras duas plataformas.

Até agora já decorreram 3 semanas de aulas (excluindo as férias da Páscoa), pelo que já pudemos tirar várias conclusões. Vou tentar documentá-las em mais posts, bem como ir mais a fundo sobre como cada plataforma tem funcionado e as pormenores interessantes que tem potenciado. Felizmente, sentimos que estamos a obter bons resultados dado o carácter de emergência que todo este esforço tem tido. E faz sentido partilhá-los, porque este novo paradigma de ensino vai ter muita presença nos próximos tempos, e temos de falar sobre isso.

tags: ensino-à-distância

O Zoom é um perigo

Este é um assunto que tem pairado nas comunidades e meios relacionados com a cultura digital, mas fora deles a percepção dos problemas do Zoom tem sido pouca. Alinhei este texto para não ter de repetir argumentos sempre que me vão perguntando porque é que recomendo que não se use o Zoom.

O Zoom é uma plataforma de videoconferência que está a ganhar ampla atenção graças às novas necessidades de comunicação que a confinação coletiva tem imposto. Universidades, empresas e organismos públicos têm investido em licenças dessa plataforma -- é parte integrante do Colibri, uma iniciativa pública da FCT. Também tem sido um recurso para amigos e familiares manterem contacto com recurso a um interface fácil e funcionalidades giras.

No entanto, aparentemente longe dos olhos da grande maioria da imprensa portuguesa e da percepção pública por cá, o Zoom contém um conjunto inaceitável de falhas e más práticas que a tornam um risco enorme. A cada dia têm saído mais notícias sobre os buracos e práticas moralmente questionáveis da empresa.

Falhas de segurança deliberadas e imperdoáveis

A minha brilhante cunhada partilhou comigo há pouco um pormenor preocupante: até há bem pouco tempo, as reuniões não estavam protegidas por password, sendo apenas necessário um link em que os últimos 10 dígitos eram diferentes. Bastava experimentar números à sorte para ir parar a reuniões de outras pessoas, muitas delas privadas.

Ao procurar um pouco, encontramos relatos de trolls que exploram falhas de segurança estúpidas como esta para se meterem em reuniões dos Alcoólicos Anónimos a dizer como beber é que é bom. A prática já ganhou um nome: zoombombing, e já há relatos de ferramentas para explorar esta e outras omissões de segurança elementar.

Se o Zoom falha em proteções tão simples, verdadeiras obrigações elementares dentro da indústria, seria de esperar que ouvíssemos falar de mais casos graves. Pois bem, têm saído a cada dia e foi-se descobrindo que:

• Já há processos em tribunal contra o Zoom por enviar em massa os dados dos utilizadores para o Facebook, sem qualquer menção do facto ou pedido de autorização aos seus utilizadores, incluindo informação de utilizadores que não têm conta no Facebook.
• O instalador do Zoom em Mac tinha uns hacks muito manhosos para ultrapassar as seguranças legítimas do sistema, sendo a instalação feita sem autorização do utilizador.
• Era possível aceder a links privados e pessoais de pessoas que estavam anonimamente na reunião, informação essa que era partilhada com membros do programa de prospeção de vendas do Linkedin.
• Os dados dos utilizadores e as chaves de encriptação têm passado por servidores na China, país que se distingue pela vigilância total das suas redes nacionais, sendo-lhe entregues de bandeja as únicas formas de proteção para as nossas mensagens e comunicações permanecerem privadas. Quando se tem acesso a uma chave de encriptação, tudo o que ela protege passa a ser integralmente legível.
• Um conjunto de peritos investigou a criptografia do Zoom e foram descobertas numerosas anomalias e implementações incompetentes. Esse artigo também expõe de forma preocupante as implicações das relações da empresa com a China.
• Numa funcionalidade pensada para chefes controleiros, o Zoom vigia a atividade do computador dos utilizadores e junta informação sobre os programas a correr e grava a imagem da janela que está aberta. Quem dirige a chamada pode espiar que programas as outras pessoas usam.

Todos estes pontos não são simples falhas de segurança a ser "consertadas", como tem tentado defender o departamento de relações públicas do Zoom. São funcionalidades deliberadas para contornar as defesas do sistema dos utilizadores e "facilitar" o acesso da aplicação, o que tem a consequência de escancarar as portas dos computadores de cada um de nós e permitir a intrusão por parte de gente pouco escrupulosa. É muito importante destacar este pormenor: o Zoom tem a prática de negligenciar a integridade e segurança de cada um para introduzir riscos desnecessários. Não se tratam de meras "falhas" advindas de programação preguiçosa. Mas também as há:

• Um bug permitiu a extração de passwords no Windows, bastando ter a aplicação aberta para ficarmos vulneráveis a esse ataque.
• Outra falha, desta vez em Mac OS, tornou possível o acesso não autorizado à webcam e microfone, abrindo também o risco de termos o nosso computador controlado totalmente por outra pessoa sem o sabermos.

O Zoom acaba de capitular e fazer um mea culpa público algo postiço, a publicar consertos para as mazelas acima descritas, e a prometer mais cuidado com a segurança das pessoas. Todas estas falhas estiveram na plataforma durante anos até agora, em que o número de pessoas a precisar de soluções semelhantes disparou, e está a ser feito um escrutínio preciso por investigadores de todo o mundo aos buracos de segurança e privacidade do Zoom. É doloroso ver como foi profundamente negligenciada qualquer preocupação com os dados pessoais de milhões de pessoas que usam (e por vezes são obrigadas a usar) esta plataforma.

Dá para confiar?

É um risco enorme continuar a usar o Zoom

O Zoom passou de 10 milhões para 200 milhões de utilizadores desde o início da pandemia. Esse número ainda está para crescer bem mais. Ao mesmo tempo, a empresa de exploração espacial de Elon Musk, SpaceX, já proibiu totalmente o uso do Zoom nas suas comunicações internas e externas. Várias instituições de ensino também já estão a re-equacionar a sua adoção. [Mesmo antes de publicar este texto, saiu a notícia de que Nova Iorque proibiu as suas escolas de usar o Zoom.]

Estou convencido de que, mais tarde, veremos correr muita tinta sobre a responsabilidade de entidades que recomendaram -- quando não impuseram mesmo -- o uso do Zoom e as consequências que tal implica para a integridade dos dados e comunicações dos seus trabalhadores, alunos, professores e outros. Todas essas entidades falharam na sua responsabilidade e obrigação de analisar os pormenores de uma plataforma e não apenas ficarem-se pela lista de funcionalidades que encontraram na home page.

E se formos a argumentar "bom, mas agora já estamos a usar por isso nada a fazer", só posso dizer que estou bem convencido que em breve vamos receber a notícia de um ataque ao Zoom em que os dados pessoais dos trabalhadores fiquem comprometidos (uma data breach) e, no pior dos casos, publicados. Com o amadorismo já demonstrado, e a enorme atenção que o Zoom está agora a ter, parece-me um cenário particularmente plausível. Quem quiser aceitar a possibilidade de, mais à frente, dar bastante trabalho ao seu departamento jurídico quando for altura de lidar com as consequências de tal cenário, está à vontade para continuar.

Enquanto isso, também estamos um pouco órfãos de informação fidedigna sobre as plataformas que estão a ser recomendadas: o Público incluiu o Zoom na sua lista das melhores aplicações para teletrabalho, elencando a fofinha lista de funcionalidades, que é fácil de encontrar, e sem qualquer menção aos riscos que na altura da publicação da notícia já eram conhecidos. Em boa verdade, cito o Público por ser o jornal diário que assino, e não encontrei qualquer publicação ou entidade em Portugal que já tivesse reportado esses alertas (com a habitual excepção do Shifter, que costuma estar atento). Mas é nesta altura que precisamos mesmo do jornalismo rigoroso. Já não há a desculpa de que a tecnologia é um universo à parte.

O Zoom é um perigo. A melhor jogada é parar agora de usar o Zoom.

Mas nem toda a gente tem a oportunidade de pôr de parte o Zoom, sendo obrigada a tê-la instalada no seu computador pessoal pela sua entidade patronal (aliás, consigo já ouvir o bater dos teclados de advogados sindicais). Para estes casos há duas listas úteis, elaboradas pela ProtonMail e pela Mozilla Foundation, que ajudam limitar os riscos do uso desta perigosa plataforma quando não temos mesmo alternativa.

Decerto que o Zoom apresenta uma enorme conveniência nas funcionalidades que nos dá, e não é uma tarefa simples encontrar bons substitutos em determinados contextos. Mas as alternativas existem. Este texto já tem bem mais caracteres do que gostaria, pelo que me fico por recomendar o Jitsi Meet para dar conta de quaisquer necessidades de videochamada ou videoconferência. Há também listas de aplicações livres e open source para teletrabalho e ensino à distância, como esta da Free Software Foundation Europe ou esta da sua congénere portuguesa ANSOL.

Estes tempos de incerteza obrigam-nos a reações e soluções rápidas, muitas vezes de improviso. Mas não se pode fazer o outsourcing dessas soluções sem se compreender em que nos estamos a meter. No caso do Zoom, é um risco que ninguém precisa, sejam patrões, assalariados, professores, alunos, amigos, diretores ou funcionários públicos. Já estamos a lidar com perigos que cheguem para agora ter mais um com o Zoom.

Um olá, mundo

Porque o primeiro post a isso obriga, cá vai disto. Nunca consegui a disciplina e perseverança para tornar a escrita avulsa uma coisa mais regular, mas faço mais uma tentativa. Tenho andado com experimentações e dilemas que exigem alguma documentação, exigência essa amplificada por amigos que insistiram para publicar algumas das minhas impressões.

Para já, este blogue vai servir principalmente para a documentação das experiências de ensino à distância que a ~aiscarvalho e eu estamos a levar a cabo na ESAP. A confinação obrigou a uma re-definição total das metodologias pedagógicas, e decidimo-nos por uma abordagem que envolvesse o self-hosting das ferramentas que necessitávamos, e que essas ferramentas sejam livres (open source). Já vou falar mais disso nos próximos dias.

Também andava há uns tempos à procura de um poiso para algumas notas mais ou menos técnicas sobre cruzamentos de áreas que vou tocando: F/LOSS, cultura livre, design, tipografia, tildes, a dimensão sócio-política das ferramentas digitais, hacks, sysadmin e por aí. Sem promessas, é um dia de cada vez.