Facebook Muda de Nome Rumo ao Metaverso

O Facebook costumava ser visto de forma positiva pelos usuários, pois conectava o mundo e aproximava as pessoas. Isso não é mais o caso. Tem havido escândalos após escândalos e os usuários agora associam o Facebook a todas as coisas negativas que o Facebook dizia combater.

Imagem: Pexels

Neste ponto da história, o Facebook não pode mais vencer a guerra para ganhar os corações e mentes das pessoas a respeito uma série de questões. Então, em vez disso, ele precisa construir “uma nova narrativa”. A empresa está, assim, abandonando o nome e a marca Facebook e se concentrando em uma nova visão em torno do chamado Metaverso.

Não importa se essa visão é possível ou não, ou se a realidade virtual (RV) vai ou não se tornar o próximo paradigma de interação social. O importante é que trata-se de um segmento novo e interessante para construir uma nova marca e Mark Zuckerberg não quer perder a oportunidade.

O metaverso em minha opinião, sempre foi um grande embaraço. O Second Life existe há 20 anos e ainda é uma novidade divertida. O que o Facebook quer é adicionar publicidade e conteúdos de marca e fazer um second-life mais caro devido aos requisitos de hardware de última geração [além de torná-lo mais lento, com uma interface mais difícil – porque é RV].

Ninguém descobriu ainda uma maneira de proporcionar uma boa experiência de usuário em sistemas de realidade virtual, e também nenhum “caso de uso matador”. Não acho que o Facebook seja particularmente capaz de lançar algo que possa competir com qualquer coisa que a Microsoft ou a Apple possam lançar. Todos os CEOs que compram essa ideia de metaverso só falam sobre o universo de possibilidades, mas sinto que a única possibilidade que estão eles perseguindo é construir um Wal-Mart na Times Square.

A maioria desses CEOs aponta com aprovação o execrável [filme] “Jogador 1” como exemplo de uma visão a ser realizada. Eu sinto muito, mas penso que um garoto excitado de 15 anos raspando os pêlos do corpo para ser mais aerodinâmico na RV, enquanto se envolve em extensos monólogos de autocongratulação sobre como ele é um cara legal por não sentir repulsa por sua namorada “rubenesca”, enquanto recita versos de Ghostbusters em uma série de vinhetas incoerentes do tipo “lembra disso?”, não é uma visão para o futuro.

É uma pena porque acho que há obviamente usos legítimos para a telepresença via RV. Ela pode ser a próxima fronteira da videochamada, o que parece estar de acordo com a missão declarada do Facebook de conectar o mundo. Mas, suspeito que na realidade tudo o que nós teremos será um videogame extremamente ruim em vez disso – será que eles também terão NFTs?.

Posso ver como pode ser frustrante administrar uma empresa cheia de esforços diferentes, alguns dos quais pretendem ser novidadeiros ou pelo menos representar uma mudança de direção. Mas, debalde todos os esforços, ainda assim não deixam de ser percebidos e lembrados como mais uma coisa azul.

Espero que essa jogada permita que Zuckerberg permaneça tecnologicamente relevante, ocupando o lugar ao qual seus dons pessoais o levaram, em vez de ficar atolado em questões sobre os padrões éticos [ou falta de] em suas plataformas usadas por adolescentes e crianças.

Idealmente, uma plataforma ética também poderia ser cultivada por meio de algum tipo de transferência de parte do poder tecnológico acumulado pelas Big Techs à comunidade, de alguma forma. Um dos maiores desafios para o futuro é, em minha opinião, permitir que tais sistemas éticos se desenvolvam de forma padronizada, mas de maneira diversa. Em um mundo ideal, cada nova comunidade ou grupo deve ter sua própria dinâmica psicológica e merece a oportunidade de existir sem ser arrastada para a mesmice da(s) plataforma(s) por um conjunto agressivo, irritado ou tóxico de usuários.

Sinceramente, me deprime que esse revival do termo metaverso esteja sendo levado a sério e que provavelmente irá grudar no vocabulário como o desprezível termo “nuvem” e, pior, que o desenvolvimento dessas tecnologias esteja sendo conduzido por uma empresa como o Facebook.

Pessoalmente não estou interessado na visão particular de Mark Zuckerberg sobre o metaverso. Em vez disso, tenho medo de quantos mais caminhos errados podemos tomar no modo como desenvolvemos nossa tecnologia da informação e a aplicamos na sociedade. A visão FOSS [Free Open-Source Software – software livre] da computação, em que o progresso do software é compartilhado e atua como um equalizador, e onde as pessoas controlam o comportamento do seu software é o que precisamos, e não um lixo novo e melhor de vigilância-vigilância-propaganda-usuário-hostil [Agora em 3D!]

Voltaremos ao tema, certamente.

Multiplique sua Estimativa por Pi

A estimativa de projetos é uma arte hermética, em nenhum lugar isso é mais verdadeiro do que no desenvolvimento de sistemas computacionais. Certa vez, ouvi falar de uma misteriosa confraria de numerólogos, que multiplicavam suas estimativas de tempo por π. A prática supostamente dava a eles uma margem de segurança suficiente para definir novos requisitos, testes, iteração e outras mudanças aleatórias no escopo do projeto.

Imagem: Pexels

Isso me pareceu curioso e arbitrário, mas fiquei intrigado. Depois de refletir um tanto, pude colocar a conjectura da estimativa circular (CEC) em bases matemáticas sólidas.

Alguém – um designer, seu líder, o produtor executivo, um amigo, sua mãe – pede que você faça algo. Você pensa um pouco, faz algumas anotações, considera o que é necessário e apresenta um projeto e uma estimativa de tempo para a conclusão.

Mas as coisas mudam. Acontece que havia algumas coisas que seu designer/ líder/produtor/ amigo/mãe esqueceu de mencionar e, à medida que você fazia o trabalho, sugiram algumas ideias para estender o projeto um pouco mais. Seu escopo cresceu.

E é claro que nem tudo correu bem. Sua primeira tentativa foi um fracasso [instrutivo]. Então você focou na segunda tentativa e acabou criando uma serie de problemas que demoraram um tanto mais para serem ajustados. Você gastou dois dias extras para encontrar uma solução alternativa. Em suma, você seguiu um caminho positivamente tortuoso até seu objetivo.

Quanto tempo demorou a sua jornada em comparação com o plano original? Parece que os numerólogos estavam certos…

E aí está – não importa o que você pense quando começa um projeto. Depois de passar pela pesquisa, design, discussões, protótipos, falhas, testes, rotatividade de requisitos e todos os outros caprichos do processo criativo, você certamente terá gasto π vezes o tempo que você planejou originalmente.

Alguns podem questionar meu rigor matemático e até mesmo contestar o que acredito ser a conclusão incontestável. Alguém poderá alegar que o multiplicador correto não é de fato π – mas 2, ou √2, ou e, ou a razão áurea φ. No entanto, não conheço ninguém que chegue a alegar que o multiplicador seja < 1.

Independentemente de quaisquer inclinações numerológicas, o argumento é que você se permita admitir que no início de um projeto você a) não tem o panorama completo, b) você não sabe como as coisas vão se encaminhar, e c) há trabalho pela frente sobre coisas que você ainda não tem ideia.

Nenhuma quantidade de planejamento e análise de tarefas pode mudar isso, então não tente. Em vez disso, dê a si mesmo uma reserva de tempo plausível e então mergulhe no trabalho.

Ah, e aquela lista de tarefas que você fez no fim de semana passado? Não é por acaso que você conseguiu concluir apenas cerca de um terço dos itens da lista. 😉

Os Perigos do Software Evidencial – ou Quem Garante o Bafômetro?

No Lawfare Blog, Susan Landau escreve um excelente ensaio sobre os riscos apresentados pelos aplicativos usados em dispositivos de coleta de evidências (um bafômetro é provavelmente o exemplo mais óbvio). Bugs e vulnerabilidades nessa classe de equipamento podem levar a evidências imprecisas. Para compor o problema, a natureza proprietária do software torna difícil para a equipe de defesa dos réus examiná-lo. A seguir um brevíssimo resumo da essência do material.

Imagem: iStock

[…]

Os engenheiros de software propuseram um teste de três partes.

Primeiro, o tribunal deve ter acesso ao “Log de erros conhecidos”, algo que deve fazer parte de qualquer bom projeto de software desenvolvido profissionalmente.

Em seguida, o tribunal deve considerar se as provas apresentadas podem ser afetadas materialmente por um erro de software. Ladkin e seus co-autores observaram que a maioria das funcionalidades não apresentará erro, mas o momento preciso em que o software registra o uso do dispositivo pode facilmente estar incorreto.

Finalmente, os especialistas em confiabilidade recomendaram verificar se o código adere a um determinado padrão da indústria usado em uma versão não computadorizada da tarefa (por exemplo, os contadores sempre registram todas as transações – portanto, o software usado na contabilidade também deve registrar).

[…]

Objetos inanimados há muito servem como prova em tribunais: a maçaneta da porta contendo uma impressão digital, a luva encontrada na cena de um crime, o resultado do bafômetro que mostra um nível de álcool no sangue três vezes o limite legal. Mas o último desses exemplos é substancialmente diferente dos outros dois. Os dados de um bafômetro não são a entidade física em si, mas sim um cálculo de um software a respeito do nível de álcool no hálito de um motorista potencialmente bêbado. Desde que a amostra de respiração tenha sido preservada, pode-se sempre voltar e testá-la novamente em um dispositivo diferente.

O que acontece se o software cometer um erro e não houver mais nenhuma amostra para verificar? Ou, e se o próprio software produzir a evidência contra o réu? No momento em que escrevemos este artigo, não havia nenhum precedente no qual a lei permita que o próprio réu examine o código subjacente.

[…]

Dada a alta taxa de erros em sistemas de software complexos, meus colegas e eu concluímos que, quando programas de computador produzem uma prova, os tribunais não podem presumir que o software probatório seja confiável. Em vez disso, a acusação deve disponibilizar o código para uma “auditoria contraditória” pelos especialistas designados pelo réu[1]. E para evitar problemas em que o governo não tenha o código para que este seja inspecionado, os contratos de compras governamentais devem incluir a garantia de entrega do código-fonte do software adquirido – código que seja mais ou menos legível pelas pessoas – para cada versão do código ou dispositivo.

Ler o trabalho na íntegra [em inglês] em Lawfare Blog.

* * *

O comentário pertinente é: o Estado pode exigir calibração regular do bafômetro, mas quem os inspeciona? Há garantia de que o poder público multará a polícia por não verificar se os bafômetros estão calibrados de forma adequada além de estar também funcionando corretamente? E quem calibra os calibradores?

Se nenhuma amostra da respiração for retida, apenas o registro da observação do software, como a leitura de um bafômetro é essencialmente diferente de um boato ou palavra-de-boca? Será porque o bafômetro é “tecnológico”? Assumir que o instrumento é mais preciso que uma testemunha humana, apenas porque é tecnológico, gera outros grandes problemas conceituais.

Mas acho que o ponto mais amplo é este: dada a quase total falta de responsabilidade da indústria do software, a inescrutabilidade do código proprietário e a qualidade duvidosa da maioria do software comercial, um tribunal – que busca a verdade – não deve acolher prima facie evidências que consistam exclusivamente do resultado de um software.

Este não é um problema técnico, mas um problema legal causado por políticas inadequadas: a indústria do software precisa de regulamentação, responsabilidade e reforma das leis de direitos autorais.

[1] Um especialista que consultei – que um dia estará escrevendo neste espaço, gentilmente me explicou [o que agradeço penhoradamente] que esse protocolo não existe no ordenamento brasileiro. Mas da explicação depreendo que a lei brasileira pode comportar soluções análogas a essa.