A OpenAI implementa sistemas de cookies de rastreamento? Investigações técnicas publicadas em 20 de setembro de 2026, pelo pesquisador de segurança independente Buchodi, demonstram que, quando a OpenAI implementa mecanismos de cookies de rastreamento em vitrines comerciais de terceiros, os clientes web iniciam rotinas de identificação que transmitem eventos de navegação externos de volta aos coletores de publicidade da plataforma. Essa infraestrutura concentra-se em um identificador persistente rotulado como __obi, configurado com permissões entre sites e classificado na documentação oficial como um cookie de análise, em vez de um componente de marketing. Embora a arquitetura do protocolo estabeleça o pré-requisito técnico para associar interações comerciais a identificadores anônimos persistentes ou vinculados a contas, capturas de tráfego externo confirmam a transmissão para endpoints de ingestão na borda, mantendo a verificação final de junções em bancos de dados do lado do servidor inalcançável por observação externa.
Realinhamento do setor e análise de notícias
A interseção da inteligência artificial generativa e da monetização comercial atingiu um momento crítico após divulgações técnicas publicadas por meio da análise técnica de Buchodi sobre coleta de anúncios entre sites. A investigação independente examinou como as sessões de clientes que interagem com o ChatGPT se relacionam com a atividade web subsequente em domínios comerciais externos. Em vez de operar inteiramente dentro de interfaces isoladas, as interações do lado do cliente iniciam rotinas de identificação em segundo plano que retransmitem metadados de navegação para a infraestrutura de ingestão de publicidade.
Em resumo
- Emissão de identificador entre sites: Um cliente web que visita
chatgpt.comobtém um token JSON Web Token (JWT) de sincronização OBI de curta duração, que é trocado por um cookie persistente de um ano chamado__obino domínio.openai.com. - Transmissão de cookie pré-execução em testes observados no Chrome Android: Ao buscar scripts externos de medição de anúncios em
bzrcdn.openai.com, a pilha de rede do navegador anexa automaticamente o__obiantes da execução do JavaScript do lado do cliente. - Coleta de DOM e formulários via pixel: Tags de medição de anunciantes implantadas analisam entradas de formulários, elementos HTML renderizados e barramentos de gerenciadores de tags, transmitindo indicadores geográficos e strings de caminho de URL para os endpoints da OpenAI.
A análise empírica monitorou trocas de rede ao vivo em uma extensa estrutura de testes de vários meses. O conjunto de dados avaliou 23.929 solicitações HTTP individuais geradas em 936 pixels de anunciantes hospedados em 1.029 nomes de host únicos. As descobertas confirmaram que atividades comerciais externas — incluindo interações com catálogos de produtos, buscas de itens e funis de checkout — transmitem regularmente para endpoints de ingestão da OpenAI acompanhadas por tokens persistentes de cliente.
No dispositivo de teste do pesquisador, valores idênticos de __obi foram transmitidos de 12 sites comerciais distintos operando sob 13 configurações de pixel separadas, incluindo portais como Chewy, Wayfair, ThriftBooks, Eventbrite, HelloFresh, Coursera e SeatGeek. Na amostra de tráfego mais ampla, 12 de 30 valores distintos de __obi apareceram em vários contextos de anunciantes, com um valor observado em dez domínios comerciais separados.
Linha do tempo de resolução de identidade entre sites
| Fase do evento | Ação do protocolo | Escopo técnico e limite de isolamento |
|---|---|---|
| Inicialização da sessão | POST /sync-token |
O JWT RS256 vincula uma conta ou identificador de sujeito anônimo a um token de 60 segundos |
| Persistência de cookie | Set-Cookie: __obi |
SameSite=None marca o cookie como elegível para trânsito entre sites |
| Atribuição comercial | GET /sdk/oaiq.min.js |
A pilha de rede do navegador anexa o cookie durante a recuperação inicial do script |
As definições oficiais dentro da Política de Cookies da OpenAI classificam o __obi entre os cookies de análise, atribuindo à entrada uma validade operacional de 365 dias. Como a arquitetura de consentimento da OpenAI rege o __obi por meio de consentimento de análise em vez de controles dedicados de marketing, rejeitar apenas o consentimento de marketing não impediu a implantação de cookies nos testes observados.
Desconexão arquitetural interna
A mecânica operacional que rege o __obi baseia-se em um pipeline de troca de três estágios que conecta sessões de navegador do cliente, endpoints de coleta de publicidade e vitrines comerciais de terceiros. Os rastreamentos de rede ilustram como uma asserção criptográfica transitória se traduz em um identificador duradouro do lado do cliente.
O processo origina-se em chatgpt.com. O navegador do cliente gera 16 bytes de entropia e despacha uma solicitação HTTP para o backend da plataforma:
POST /backend-api/bazaar/obi/sync-token
Sessões não autenticadas invocam /backend-anon/bazaar/obi/sync-token. O serviço de emissão interno, identificado pela reivindicação iss do JWT como chatgpt-wadi, retorna um JSON Web Token assinado por RS256 contendo reivindicações de identidade que mapeiam a entropia aleatória para metadados internos da conta.
{
"iss": "chatgpt-wadi",
"aud": "bzr.openai.com",
"purpose": "obi_sync",
"operation": "set",
"consent_decision": "analytics_allowed",
"consent_policy_version": "user_granular_consent_v1",
"sub": "«redacted: 64-hex account subject»",
"subject_type": "account_user",
"obi": "«redacted: 22-char identifier»",
"exp": "«iat + 60s»"
}
O payload assinado impõe um período de expiração de 60 segundos (exp). O navegador do cliente encaminha imediatamente este token para o domínio de publicidade programática da OpenAI via solicitação POST assíncrona:
POST https://bzr.openai.com/v1/obi/sync
Os servidores de borda da OpenAI processam o token e respondem com cabeçalhos HTTP instruindo o navegador a armazenar o cookie persistente.
HTTP/2 200 OK
Set-Cookie: __obi=«redacted»; Domain=.openai.com; HttpOnly; Max-Age=31536000; Path=/; SameSite=None; Secure
Atribuir SameSite=None juntamente com a flag Secure marca o cookie como elegível para transmissão entre sites onde o navegador host permite cookies de terceiros. Diferente de cookies de aplicativos padrão com escopo SameSite=Lax ou restritos a subdomínios de origem direta, o __obi anexa-se a solicitações de saída entre sites endereçadas a *.openai.com.
+-------------------------------------------------------------------------+ | [ FLUXO CONCEITUAL DO PROTOCOLO: TROCA DE TOKEN OBI E PIXEL DE ANÚNCIO ] | +-------------------------------------------------------------------------+ | | | [ Sessão do Navegador do Usuário (chatgpt.com) ] | | | | | +---> Solicitar Token de Sincronização: POST /backend-api/.../sync-token | | | Resposta: JWT RS256 de 60s (Sujeito da conta ou anônimo) | | | | | +---> Trocar Token: POST bzr.openai.com/v1/obi/sync | | Resposta: Set-Cookie: __obi (SameSite=None; 1 ano) | | | +-------------------------------------------------------------------------+ | [ Vitrine do Comerciante (Site do Varejista com Pixel da OpenAI) ] | | | | | +---> Navegador busca: <script src="bzrcdn.../oaiq.min.js"> | | | * PILHA DE REDE DO NAVEGADOR ANEXA __obi NA BUSCA DO SCRIPT * | | | | | +---> Pixel reúne texto do DOM, barramentos do gerenciador de tags e entradas | | | | | v | | [ Endpoint de Ingestão da OpenAI (bzr.openai.com/v1/sdk/events) ] | | Transmitido: CEP + Valores Hashed + Caminho de URI Sanitizado | | | +-------------------------------------------------------------------------+
As vitrines parceiras completam o ciclo de comunicação. Varejistas que anunciam por meio do ChatGPT incorporam o script de medição de conversão da OpenAI (oaiq.min.js). Quando um usuário navega até um comerciante integrado, o navegador analisa a tag de script:
GET https://bzrcdn.openai.com/sdk/oaiq.min.js
Como a solicitação corresponde ao escopo curinga .openai.com, a pilha de rede do navegador anexa o __obi à recuperação inicial do script. Essa transmissão ocorre antes que o JavaScript do pixel seja executado, o que significa que a lógica do lado do cliente dentro do pixel não pode contornar a solicitação credenciada. No entanto, bloqueadores de conteúdo em nível de rede, sumidouros de DNS ou extensões de navegador que bloqueiam o domínio da solicitação impedem a conexão inteiramente.
Capturas de rede revelam que o SDK de medição extrai atributos em nível de página em quatro canais rotulados:
Classificações de dados de ingestão do pixel
| Canal de Origem | Mecanismo de Coleta | Escopo Técnico e Exposição de Campos |
|---|---|---|
in (Entrada Explícita) |
Parâmetros da API do Comerciante | Valores de transação, identificadores de produto, símbolos de moeda |
fm (Coleta de Formulários) |
Intercepção de entrada DOM | Valores de entrada de formulário, elementos de checkout, entradas de contato |
ht (Travessia DOM) |
Análise de HTML Renderizado | Cabeçalhos de conteúdo, strings de confirmação, elementos de texto |
js (Hooking de Gerenciador de Tags) |
Intercepção de Camada de Dados | Hooks em window.dataLayer.push e matrizes de tags Adobe |
O tráfego observado registrou 685 eventos de coleta automatizada em fontes de DOM e tags (fm, ht e js) em comparação com 255 parâmetros fornecidos pelo comerciante (in). O SDK inspeciona arquiteturas de tags padrão, analisando dados passados para pipelines do Google Tag Manager e Adobe Analytics. Identificadores pessoais, como endereços de e-mail, números de telefone e nomes completos, são processados com hashing SHA-256 antes do trânsito. Em contraste, indicadores geográficos — incluindo país, região, cidade e CEPs — transitam em texto simples. Atributos de CEP apareceram em 100 capturas distintas em 28 nomes de host.
Estruturas de URL também transitam para endpoints de ingestão. Embora os parâmetros de consulta sejam omitidos, os componentes de origem e caminho permanecem intactos. Registros observados confirmaram caminhos que representam consultas de referência médica, fluxos de trabalho de gestão de dívidas financeiras e formulários de entrada de litígio chegando aos endpoints de coleta.
Sistemas desacoplados e contenção do navegador
A mecânica do trânsito de cookies entre sites reflete variações arquiteturais fundamentais em motores web modernos. Diferentes navegadores impõem padrões distintos de particionamento de estado, determinando se identificadores de terceiros podem ser transmitidos através de limites de origem.
Arquiteturas de isolamento de cookies de navegador
| Ambiente de Navegador | Modelo de Isolamento de Armazenamento | Manuseio entre sites SameSite=None |
Manuseio de caminho observado |
|---|---|---|---|
| Chrome para Android | Compartilhamento de perfil de cookie | Entrega entre sites suportada quando cookies de terceiros são permitidos | Transmissão verificada em testes; sujeito a configurações de cookies de terceiros do usuário e corporativas |
| Apple Safari (WebKit) | Prevenção Inteligente de Rastreamento | Bloqueia armazenamento de terceiros por padrão | Bloqueado por padrão neste caminho observado entre sites |
| Chrome no iOS | Runtime WebKit aplicado | Sujeito a restrições de armazenamento do WebKit | Bloqueado por padrão neste caminho observado entre sites |
| Mozilla Firefox | Proteção Total de Cookie | Particiona jars de cookies por site de nível superior | Estado de terceiros particionado por padrão; interação __obi específica não testada independentemente |
| Navegador Brave | Particionamento de armazenamento Shields | Particiona e bloqueia estado entre sites | Estado de terceiros particionado/bloqueado por padrão; interação __obi específica não testada independentemente |
Conforme detalhado na documentação do visão geral de prevenção de rastreamento do WebKit, ambientes WebKit restringem o armazenamento entre sites por padrão. A Prevenção Inteligente de Rastreamento (ITP) suprime cookies de terceiros em chamadas de rede externas, impedindo que vitrines de comerciantes no iOS Safari e iOS Chrome transmitam o __obi. Da mesma forma, as especificações arquiteturais da Mozilla sobre Proteção Total de Cookie e particionamento de estado de origem detalham como os jars de cookies são particionados por origem de nível superior, isolando cookies criados sob openai.com de páginas de comerciantes externas.
A investigação reproduziu especificamente o mecanismo completo no Chrome para Android. Conforme documentado nas políticas de gerenciamento de cookies do Google Chrome, cookies de terceiros configurados com SameSite=None; Secure são permitidos em buscas de rede entre sites, a menos que o usuário ou administrador do dispositivo habilite o bloqueio de cookies de terceiros, facilitando a comunicação entre vitrines e endpoints de publicidade da OpenAI.
Comparação de classificação de consentimento e comportamento observado
| Atributo de Avaliação | Escopo declarado da política de cookies | Implantação em runtime observada |
|---|---|---|
| Atribuição Categórica | Classificado como cookie de análise | Configurado com SameSite=None; Secure para entrega entre sites |
| Reivindicação de consentimento avaliada | Distinto das configurações oai_consent_marketing |
Regido exclusivamente por analytics_allowed em tokens decodificados |
| Resultado da rejeição de marketing | Destinado a reger o uso de publicidade e promocional | Observado como ativo em solicitações de comerciantes quando apenas o consentimento de marketing foi recusado |
| Perfil de Coleta de Dados | Descrito como avaliação de uso e desempenho do serviço | Carrega dados de formulário de checkout, CEPs em texto simples e caminhos de URI |
A categorização aplicada ao __obi nas políticas legais da OpenAI introduz importantes questões de governança. A OpenAI fornece escolhas de consentimento distintas para análise (oai_consent_analytics) e marketing (oai_consent_marketing). Cada token de sincronização decodificado durante os testes técnicos continha o atributo consent_decision: analytics_allowed.
Como o serviço de emissão de token subjacente vinculou a geração à preferência de análise, recusar apenas cookies de marketing não interrompeu a emissão ou transmissão de __obi no fluxo de teste observado. Essa estrutura levanta questões sob padrões internacionais de governança de dados sobre se a medição de conversão de anúncios em vários sites alinha-se à análise funcional básica ou justifica a classificação como telemetria de marketing.
Avaliações de engenharia devem manter distinções estritas entre o trânsito de rede observado e o manuseio de dados de backend. Logs de tráfego confirmam que portais de comerciantes transmitem __obi juntamente com indicadores de pedido, atributos de formulário e caminhos de URL para bzr.openai.com, recebendo um status HTTP 202 Accepted. Embora a incorporação de identificadores de sujeito em nível de conta dentro do token de autorização inicial torne a resolução da conta tecnicamente plausível por design, observações de rede externa não podem confirmar independentemente se os sistemas de backend da OpenAI vinculam esses eventos de entrada aos históricos de conversação do usuário.
Lista de verificação de engenharia e cronogramas de verificação
Equipes de engenharia corporativa que gerenciam portais web e frotas de endpoints devem avaliar configurações de tags de terceiros para garantir que scripts externos estejam em conformidade com padrões corporativos de privacidade e manuseio de dados.
Lista de verificação de governança de tags para webmasters corporativos
Ingestão de script e auditoria de tags
- [ ] Auditar modelos de aplicativo para localizar dependências que carregam recursos de
bzrcdn.openai.com. - [ ] Avaliar se a Integridade de Subrecurso (SRI) ou a hospedagem com versão fixada se alinha aos modelos de implantação do fornecedor.
- [ ] Revisar configurações de gerenciamento de tags para verificar se as tags de marketing acessam barramentos de transação internos.
Revisão da camada de dados e manuseio de campos
- [ ] Avaliar limites de acessibilidade em estruturas
window.dataLayereadobeDataLayer. - [ ] Revisar se CEPs e campos de endereço exigem redação antes de despachos de tags externas.
- [ ] Revisar a configuração de “Correspondência Automática” no Gerenciador de Anúncios da OpenAI para avaliar se a análise de DOM é apropriada para fluxos de trabalho de checkout.
Verificação de Política de Segurança de Conteúdo (CSP)
- [ ] Revisar diretivas
connect-srcpara definir destinos autorizados para beacons de telemetria de saída. - [ ] Avaliar políticas
script-srcpara impedir a execução de scripts externos não revisados. - [ ] Validar funis de checkout e de entrada de clientes para garantir que caminhos confidenciais permaneçam protegidos de beacons de terceiros.
Configuração de endpoint e higiene de armazenamento
Configuração de frota de dispositivos móveis
- [ ] Avaliar perfis de configuração do Chrome para Android em dispositivos corporativos gerenciados.
- [ ] Avaliar o impacto operacional da habilitação de restrições de cookies de terceiros em endpoints gerenciados.
- [ ] Revisar a implantação de configurações de navegador focadas em privacidade onde os requisitos de negócios permitirem.
Auditoria de higiene de identidade e sessão
- [ ] Monitorar o tráfego de saída da rede corporativa para chamadas recorrentes em direção a
bzr.openai.com. - [ ] Estabelecer rotinas regulares de manutenção de perfil em sessões de navegador não gerenciadas.
- [ ] Confirmar que designs de formulários corporativos evitam expor entradas de usuário em texto simples a contextos de script ambiente.
A implementação de Políticas de Segurança de Conteúdo estruturadas e a revisão dos limites de ingestão de tags podem ajudar as equipes de engenharia a reduzir a exposição não intencional de dados de terceiros durante transações comerciais.
Perguntas Frequentes (FAQ)
Rejeitar apenas o consentimento de marketing interrompe o cookie __obi?
Por que o Safari no iOS bloqueia esse rastreamento enquanto o Chrome no Android o permite?
Sites de comerciantes terceiros podem ler o cookie __obi diretamente?
Implicações práticas e perspectivas futuras
O exame técnico da estrutura do cookie __obi ilustra o relacionamento em evolução entre plataformas de IA conversacional e arquiteturas de publicidade online. Por anos, sistemas de publicidade digital utilizaram mecanismos de estado de navegador para conectar o engajamento do usuário em sites independentes. Aplicar esses padrões de medição a interfaces conversacionais introduz novas considerações. Usuários frequentemente inserem detalhes profissionais, técnicos e pessoais sensíveis em plataformas conversacionais sob a suposição de que esses ambientes permanecem separados de redes de publicidade mais amplas.
Se a telemetria do comerciante for finalmente resolvida para identidades em nível de conta, como o design do protocolo parece permitir, essa combinação criaria perfis comportamentais incomumente ricos. À medida que agentes de IA gerenciam cada vez mais tarefas práticas — como agendamentos, reservas de viagens e compras de produtos — os limites operacionais entre a utilidade conversacional direta e o perfil comercial exigirão uma definição cuidadosa.
Navegar nesta transição exige que equipes de engenharia apliquem uma governança disciplinada em propriedades web. Organizações que gerenciam sites voltados para o cliente devem auditar integrações de scripts de terceiros, revisar exposições de dados em gerenciadores de tags e aplicar Políticas de Segurança de Conteúdo precisas. Em paralelo, padrões de armazenamento de navegador em evolução continuam a limitar o compartilhamento de dados ambiente entre sites em plataformas. A privacidade de longo prazo em ambientes web modernos dependerá de limites técnicos robustos do lado do cliente, e não apenas de declarações de política.
Referências
Share this article
