Google Chrome oferece API acessível apenas em `*.google.com`

 (twitter.com/lcasdev)
2 pontos por GN⁺ 2024-07-10 | 1 comentários | Compartilhar no WhatsApp
  • O Google Chrome oferece uma API que permite acesso apenas aos sites *.google.com a uso de CPU do sistema/aba, uso de GPU, uso de memória, informações detalhadas do processador e acesso a um backchannel de logging
  • Como a mesma API não é exposta a outros sites, surgiu a controvérsia sobre se um fornecedor de navegador pode conceder privilégios especiais ao seu próprio site
  • O DMA transforma em lei a ideia de que fornecedores de navegadores, como gatekeepers da internet, devem oferecer as mesmas funcionalidades a todos; dependendo da interpretação, expor informações extras apenas a propriedades do Google pode constituir violação do DMA
  • O Zoom pode ficar em desvantagem competitiva por não receber a mesma função de depuração de CPU oferecida ao Google Meet
  • Esse recurso é implementado como uma extensão interna do Chrome que não pode ser desativada e não aparece no painel de extensões; no Microsoft Edge e no Brave, a mesma funcionalidade também é oferecida apenas ao domínio *.google.com

Informações expostas pela API exclusiva de *.google.com

  • O Chrome fornece apenas aos sites *.google.com informações de estado do sistema e quase de depuração
    • Uso de CPU do sistema e da aba
    • Uso de GPU
    • Uso de memória
    • Informações detalhadas do processador
    • Backchannel de logging
  • A mesma API não é exposta a outros sites e só pode ser usada no domínio *.google.com

Forma de implementação e comportamento em navegadores derivados do Chromium

  • Esse recurso é implementado como uma extensão interna do Chrome que não pode ser desativada e não aparece no painel de extensões
  • O código-fonte está no caminho hangout_services do Chromium
  • Não estava claro se a mesma extensão também era incluída em outros navegadores derivados do Chromium, mas uma atualização posterior confirmou o seguinte comportamento
    • No Microsoft Edge, essa funcionalidade também é oferecida exclusivamente ao domínio *.google.com
    • No Brave, também há uma extensão pré-instalada que permite ao Google obter essas informações apenas em *.google.com, com comportamento igual ao do Chrome e do Edge

Questões de concorrência e regulação

  • Se um navegador fornecer informações do sistema apenas a um domínio específico do próprio fornecedor, outros serviços web terão dificuldade para implementar o mesmo nível de diagnóstico
  • O Zoom é citado como exemplo por não poder oferecer a mesma função de depuração de CPU do Google Meet, o que pode levar à questão de favorecimento do próprio serviço pelo fornecedor do navegador
  • Do ponto de vista do DMA, a principal questão continua sendo se o gatekeeper deve oferecer acesso igualitário às funcionalidades

Leituras relacionadas

1 comentários

 
GN⁺ 2024-07-10
Comentários do Hacker News

  • Pelo nome hangout_services, parece uma gambiarra antiga que virou dívida técnica, feita para facilitar o desenvolvimento do Google Hangouts
    Provavelmente servia para enviar dados de telemetria diretamente para a equipe do Hangouts. O Hangouts foi o primeiro app a implementar videochamadas no navegador, e isso depois virou o WebRTC. Esse módulo expõe uso de CPU/GPU/RAM e informações de hardware que o app normalmente não conseguiria ver. O Google provavelmente vai ver esse thread no Twitter e simplesmente remover isso. O Hangouts já é um produto morto e, mesmo que algum código do lado do servidor ainda use isso, hoje o WebRTC tem um alcance muito maior, então a equipe do Chrome provavelmente monitora desempenho diretamente de forma multissite

    • Não, isso está sendo usado no Google Meet agora. Se você abrir o painel de "Troubleshooting" do meet.google.com no Chrome, verá o uso total de CPU do sistema em tempo real :)
    • Independentemente da invasão de privacidade, isso não é claramente uma questão de antitruste? O Google está abusando do domínio do navegador para dar vantagem ao próprio produto no mercado de videoconferência
    • Talvez isso sirva para ajustar finamente qual qualidade de stream de vídeo usar, rastreando uso de CPU/GPU etc.
      Não é padrão, mas parece algo totalmente plausível para um app nativo fazer

  • Acho que posso dar um pouco de contexto sobre essa parte. Para referência, sou ex-funcionário do Google
    Trabalhei no GVC, a plataforma interna de videoconferência do Google. Em 2010–2011, muitos dos equipamentos de videoconferência da empresa eram aparelhos proprietários como Cisco Tandberg, que eram caros e também tornavam custoso equipar milhares de salas de reunião. Mais ou menos na mesma época, outra equipe estava desenvolvendo o Hangouts, e não lembro bem se naquela época ele já se chamava Google Meet ou se esse nome veio depois. Acho que o nome Hangouts foi adotado quando o produto foi integrado ao Google+. A configuração do GVC variava, mas a mais comum era uma combinação All-in-One (AIO) de monitor/computador, que era um PC Intel completo. Por isso, a plataforma GVC era uma distribuição Linux customizada, projetada para se comunicar com serviços do Google e distribuir atualizações de software. Ela também mantinha distribuições antigas em caso de falha de boot, e havia várias questões como a nomeação dos equipamentos. Também era preciso dar suporte a vários tipos de hardware: painéis touch, câmeras PTZ grandes, múltiplos microfones e assim por diante. No fim, o Hangouts virou a stack base do GVC e substituiu quase todos os Tandberg, economizando muito dinheiro. Esse sistema com certeza ainda era usado em 2017; depois disso, não sei. Como o monitoramento também fazia parte disso, se existe uma API exclusiva para *.google.com, é preciso olhar com atenção. Pelo tweet sozinho, não dá para saber se o Google consegue consultar todas as instâncias do Chrome no mundo ou se isso só é possível em google.com. Ainda assim, pelo nome hangouts_services e pela restrição de domínio, parece bem provável que isso seja suporte de monitoramento para Chrome embarcado do GVC. Posso estar errado

    • Acho que não é isso. Acabei de fazer uma chamada no Meet no Firefox, e ao clicar no botão de solução de problemas, o gráfico de CPU fica desativado e aparece a mensagem "experimente usar o Chrome para ver o uso de CPU"
      No Chrome dá para ver o uso de CPU, embora eu não saiba se é do Meet ou do sistema inteiro, mas em qualquer um dos casos isso não parece ser algo possível com uma API comum. Testei com alguns processos yes em segundo plano e é claramente o sistema inteiro. E, de resto, confusão de nomes sempre acontece, mas GVC é um nome realmente claro e bom
    • História interessante, mas não parece ter nenhuma ligação, nem remota, com este caso. Quem operava a plataforma GCV com uma distribuição Linux customizada não teria escolhido “vamos colocar uma extensão customizada nossa em todas as instalações do Chrome no mundo” como forma de reportar estatísticas da máquina
      Dá para testar diretamente em qualquer página *.google.com:
      chrome.runtime.sendMessage("nkeimhogjdpnpccoofpliimaahmaaome", {"method":"cpu.getInfo"}, (resp) => { console.log(resp); });
    • Não entendo muito bem a distinção entre “o Google consegue consultar todas as instâncias do Chrome no mundo” e “isso só é possível em google.com”
      Parece que a API só é exposta a conteúdo executado em *.google.com, mas isso ainda é praticamente o mesmo que dizer “o Google consegue consultar todas as instâncias do Chrome que visitarem os sites dele”. Mesmo que você não use serviços do Google, o Chrome por padrão busca o conteúdo da página de nova guia no Google, então na prática isso chega bem perto de 100%. Não acho que esteja sendo usado de forma maliciosa, mas se o Google consegue diagnosticar problemas assim e concorrentes na mesma área não conseguem, continua sendo um problema. O Zoom não tem uma API dessas, tem?
    • Nunca trabalhei no Google, mas essa explicação não faz muito sentido para mim
      Você quer dizer que, para observar o uso de CPU em um appliance interno da plataforma interna de videoconferência, eles colocaram esse plugin empacotado no Google Chrome para usuários em geral?
    • Interessante. Talvez a maior parte do Google também não soubesse até agora que isso era possível
      Neste momento, provavelmente há dezenas de gerentes de produto abordando o líder técnico do próprio produto com um “olha só, me escuta...”

  • Essa funcionalidade parece ter sido adicionada em outubro de 2013: https://github.com/chromium/chromium/commit/422c736b82e7ee76...
    É o commit que empacota a extensão Hangouts Services no Chrome. BUG=291271, URL de review: https://codereview.chromium.org/35873003. A URL de review em questão é https://codereview.chromium.org/35873003

  • Não sei exatamente o que é essa API nem por que ela existe, mas o Firefox também faz algo parecido
    Há APIs especiais que só podem ser usadas em domínios da Mozilla e do Firefox, como para instalação de extensões ou auxílio na experiência da primeira execução. Um post de blog relacionado apareceu no Hacker News há menos de 12 meses, mas é difícil de achar

    • Não é quase a mesma coisa
      A API é pública e documentada, e a lista de permissão de domínios está na UI e no about:config. A versão da Play Store no Android é a exceção, porque lá esconderam tudo, aparentemente para transformar o navegador em puro lixo. E, se você levar um bom caso de uso e pedir educadamente no Bugzilla, parece provável que os desenvolvedores ao menos considerem adicionar domínios padrão
    • Isso é para sites diretamente relacionados à operação do navegador. Já o Chrome está expondo APIs usadas por um produto separado do Google, como o Google Meet
      Como isso usa um monopólio em um mercado, o de navegadores, para obter vantagem em outro, o de videoconferência, pode até ser uma violação antitruste
    • Escrevi há muito tempo sobre a parte do UITour: https://www.mkelly.me/blog/content-uitourjs/
      É uma abordagem bem padrão entre navegadores. O risco deveria ser mais ou menos do mesmo nível de alguém falsificar o domínio de onde o navegador baixa atualizações de software e, se você realmente odiar isso, dá para desligar nas configurações
    • No mês passado foi compartilhado um commit do Quirks.cpp do WebKit [0]. Talvez não seja o que você estava procurando, mas tem uma sensação parecida
      [0] https://news.ycombinator.com/item?id=40631439
    • Essas APIs estão relacionadas a recursos do navegador e onboarding. Não foram colocadas lá para favorecer outros produtos da Mozilla em relação a produtos semelhantes de outras empresas

  • Só para constar, trabalho no Google, mas não no Chrome nem nessa API
    Acho que a explicação é bem comum. Por exemplo, se você abrir o Google Meet e iniciar uma reunião vazia, ou seja, uma “reunião instantânea”, e depois clicar em “…” e em “Solução de problemas e ajuda”, aparecem vários gráficos de estatísticas, incluindo uso de CPU. Também parece sugerir educadamente que você feche abas se a máquina estiver sob carga durante uma chamada no Meet. É bem útil, então às vezes eu consulto isso. Pensando de novo, não tenho certeza se a sugestão para fechar abas realmente existe; o que eu de fato usei foi só a tela de estatísticas

    • Ao contrário da explicação de que isso é “bem comum”, isso não é nada comum. É um exemplo perfeito de dar ao próprio produto uma vantagem competitiva desleal
      Usuários do Meet recebem orientação sobre por que a reunião não está funcionando direito, mas se Zoom, Teams e Slack não conseguem fazer o mesmo, a experiência de uso do Meet inevitavelmente fica melhor. Também não é estranho que todos os outros serviços de reunião insistam tanto para que você use o app de desktop. O app de desktop do Google Meet em breve será o Chrome
    • Na verdade, esse é justamente o ponto. Outras ferramentas de videoconferência não podem oferecer esse tipo de opção de depuração e, como você acabou de dizer, essa função é útil
    • O concorrente Zoom tem uma versão para navegador. Ele consegue usar essa API para diagnosticar problemas de desempenho? Se não consegue, reguladores europeus podem se interessar por isso
      Talvez essa seja uma das razões pelas quais o Meet funciona bem no navegador e o Zoom não, especialmente quando há muitos participantes na reunião, levando usuários do Zoom a usar o app nativo se quiserem desempenho adequado
    • Que máximo que o Google criou um navegador anticompetitivo que oferece recursos úteis só para ele mesmo
      Obrigado ao funcionário do Google por dizer explicitamente a parte que normalmente tentariam deixar passar em silêncio
    • Alavancagem de poder monopolista não é algo comum, é ilegal

  • Parece que houve um pequeno erro ao mudar o título do envio em relação ao original. Pelo que entendi, é o seguinte
    O Chrome tem uma extensão embutida que usa APIs públicas do Chrome, que outras extensões do Chrome também podem usar facilmente. O problema é que, quando essa extensão se comunica com os próprios domínios do Google, ela compartilha essas informações, mas outros sites não podem fazer isso. Não existe uma “API especial escondida”

    • O “especial” significa que ela é embutida no Chrome, e não instalada pelo usuário como outras extensões
      E “escondida” significa que ela não aparece na lista mesmo se você for em chrome://extensions. E, como já foi dito, isso também é uma API do Chrome
    • Se você colar isto no console do Chrome DevTools em um site do Google, parece uma API especial:
      chrome.runtime.sendMessage( 'nkeimhogjdpnpccoofpliimaahmaaome', { method: 'cpu.getInfo' }, response => { console.log('CPU Info:\n', JSON.stringify(response, null, 2)); } );
    • Mesmo sendo uma “extensão embutida”, se ela não puder ser desativada, então continua sendo parte do navegador
    • Também há uma explicação inocente e simples. Dá para imaginar que parte das funções do navegador não é implementada em C++ compilado/vinculado, mas como um web app assinado do google.com
      Seria estranho se um código do navegador implementado como PWA tivesse que pedir permissões separadas para acessar informações do sistema. Afinal, isso faz parte da própria função do navegador. Outro uso dessas APIs privadas, existente há muito tempo, é integrar o navegador Chrome com sites do Google dedicados que fornecem funções essenciais, como a Chrome Web Store, permitindo instalar e remover extensões a partir de uma página web
    • Funcionalmente, é a mesma coisa

  • Isso parece usar a API chrome.system.cpu, à qual qualquer extensão pode acessar se tiver a permissão "system.cpu"
    https://developer.chrome.com/docs/extensions/reference/api/s...
    Todas as permissões solicitadas por essa extensão podem ser vistas aqui:
    https://source.chromium.org/chromium/chromium/src/+/main:chr...

    • Sim, e esse é exatamente o problema. O Google está empacotando no Chrome uma extensão que não tem relação com o funcionamento do próprio navegador, dando ao Hangouts, que é outro produto, acesso privilegiado
      Outros apps de videoconferência não têm esse tipo de acesso, a menos que o usuário passe pela grande etapa extra de instalar manualmente uma extensão separada

  • Não é muito surpreendente. É algo bem típico do Google. A questão é se isso também existe em outros navegadores Chromium. E no Edge, Brave, Chromium e Ungoogled Chromium?

    • Não sei quanto aos outros, mas o ungoogled chromium provavelmente não tem isso, porque ele deliberadamente embaralha todas as partes do código onde aparece a string "google" para evitar esse tipo de coisa
    • No Edge isso está ativado. Se você abrir a solução de problemas do Google Meet no Edge, dá para ver a CPU do sistema
      Se fizer isso no Firefox, aparece a mensagem “para ver o uso de CPU, experimente usar o Google Chrome”

  • O Safari também tem recursos exclusivos para a Apple. Por exemplo, ao fazer login em outros sites com uma conta Apple, ele pode exibir uma caixa de diálogo especial que funciona de forma diferente de passkeys ou do preenchimento automático de senha
    Nos outros navegadores, ele faz você passar por um fluxo baseado em redirecionamento. Sempre tive curiosidade sobre como isso é implementado em JavaScript. Seria algo como WebAuthn com argumentos proprietários?

  • O Google já fez esse tipo de coisa antes. Os detalhes estão meio vagos na minha memória, mas acho que o Native Client só funcionava no Hangouts por causa de uma allowlist em nível de domínio, ou algo assim