Nos últimos meses, o YouTube tem testado novas medidas de combate ao uso de bloqueadores de anúncios. Atualmente, essas medidas estão em fase de testes A/B, e uma de minhas contas faz parte do grupo experimental. Desenvolvi um filtro que ajuda a evitar parcialmente uma das técnicas, chamada "buffering falso", utilizando o uBlock Origin (e também no navegador Brave, já que ambos usam as mesmas regras de filtro). Este filtro já faz parte das listas de filtros padrão, portanto não é necessário adicioná-lo manualmente.

Um dos problemas que os usuários têm encontrado é o "buffering falso". Nesse caso, os vídeos demoram a carregar devido a um buffering intenso, mas isso ocorre apenas no início do vídeo, sem qualquer buffering no meio. O que acontece é que esse buffering representa 80% do tempo dos anúncios que você teria assistido, o que significa que, mesmo com o buffering falso, você ainda economiza tempo utilizando um bloqueador de anúncios.

O InnerTube é a API interna de primeira parte do YouTube, utilizada pelo cliente web e pelos aplicativos móveis para interagir com vídeos e obter detalhes sobre eles. Embora existam alguns endpoints legados que não passam pelo InnerTube, nenhum deles é relevante hoje. Os endpoints do InnerTube têm um formato como https://www.youtube.com/youtubei/. Um desses endpoints é o /youtubei/v1/player, que o cliente web chama quando você clica em um vídeo para obter dados sobre a URL e URLs de transmissão do GVS.

O GVS (Google Video Services) serve como um serviço para transmitir vídeos do YouTube, do Google Drive e do Google Photos. Para transmitir um vídeo do GVS, é necessário obter uma URL de /videoplayback do InnerTube. As URLs do GVS são assinadas e têm um tempo de expiração (geralmente de 6 horas), o que significa que você não pode construí-las por conta própria, sendo necessário obtê-las do InnerTube. Uma peculiaridade do GVS é que ele não é apenas hospedado nos data centers do Google; provedores de internet podem instalar servidores do Google Global Cache em sua infraestrutura para fornecer vídeos do YouTube sem necessidade de enviar tráfego para fora da rede do provedor.

A origem do buffering falso se relaciona ao fato de que o InnerTube está fornecendo streams do GVS que oferecem um tempo de espera de 80% da duração do anúncio na primeira solicitação de /videoplayback (para o vídeo de conteúdo, não para os anúncios). Por exemplo, se o anúncio dura 15 segundos, você receberá um tempo de espera de 12 segundos ao bloquear os anúncios. Esse tempo de espera sempre ocorre se você estiver no teste A/B, independentemente de o YouTube achar que você está usando um bloqueador de anúncios.

Para evitar esse tempo de espera até que o anúncio inassistível termine, a solução é não receber um anúncio inicialmente. Se você definir a propriedade playbackContext.contentPlaybackContext.isInlinePlaybackNoAd como verdadeira nas solicitações do player, o InnerTube não fornecerá anúncios e, portanto, não incluirá tempo de espera nos streams do GVS.

Embora essa abordagem tenha suas limitações, como quebrar transmissões ao vivo e causar um breve piscar do player de vídeo, a principal solução alternativa encontrada foi contornar um script de bloqueio que o YouTube adiciona ao HTML do frontend. Esse script trava alguns objetos globais, impedindo que códigos posteriores os sobreponham com um Proxy que altere seu comportamento. Para contornar isso, ao invés de usar JSON.stringify, a solução encontrada foi usar Object.assign, que também manipula o corpo da requisição antes de ser enviado.

Agradecimentos aos mantenedores do uAssets pela ajuda nesse processo.