O Catálogo que Não Espia.
Marketplace entrega recomendação personalizada sem nunca ver o histórico do usuário.
Cenário
Usuária do marketplace cifra perfil de comportamento (8 dimensões: categorias, preço, frequência). Marketplace ranqueia catálogo sob cifra.
Problema
Personalização hoje exige profile persistente em servidor. LGPD aperta. Consent fatigue derruba conversão. FHE quebra esse trade-off.
Garantia
Servidor processa scoring sob cifra. Devolve ranking. Nunca vê o perfil. Sem profile persistente, sem risco regulatório, sem fadiga de consentimento.
Definir os parâmetros.
Antes de cifrar o perfil de comportamento, escolhemos os parâmetros CKKS. CKKS é o esquema natural para ranking de catálogo sobre vetores de features.
Capacidade · CKKS
O que cada termo significa
CKKS (esquema "aproximado") — Família FHE para números reais. Ruído de aproximação controlado (~10⁻¹⁰). Padrão para sistemas de recomendação, busca semântica e ranking — exatamente o que e-commerce precisa.
8 192 slots — Cada ciphertext é um vetor de 8 192 valores. As 8 dimensões de comportamento ocupam 8 slots; um único ciphertext carrega o perfil completo do usuário.
Profundidade multiplicativa 3 — Quantas multiplicações encadeadas. Para ranking sobre 5 produtos, profundidade 3 sobra.
~128 bits de segurança — Padrão da indústria. Quebrar a chave exigiria ~2128 operações.
Base RLWE — Mesmo problema do ML-KEM/ML-DSA padronizados pelo NIST como criptografia pós-quântica.
Chaves geradas no browser.
Diferente do modelo tradicional onde o servidor controla tudo, aqui é o BROWSER do usuário que gera o par de chaves. A chave secreta vive em IndexedDB ou similar. O marketplace só recebe a chave pública.
Geração
Por que browser-side
Inversão de poder — Em e-commerce tradicional, o usuário entrega histórico ao marketplace via cookies/server-side. Sob FHE com chaves browser-side, o usuário detém o controle: pode revogar, exportar, deletar — e o marketplace literalmente perde acesso.
Lattigo via WASM — Lattigo (Go) compila para WebAssembly e roda em qualquer browser moderno. Geração de chaves em ~50 ms é viável sem afetar UX.
Storage local — A chave secreta é persistida em IndexedDB (criptograficamente protegida pelo browser). Sobrevive a fechar a aba. Não vaza para o servidor nem com o usuário tentando.
Perfil cifrado localmente.
As 8 dimensões abaixo são projeções didáticas do user embedding. Em produção real, o vetor tem 128-512 dimensões vindas de um modelo two-tower treinado no próprio catálogo.
8 dims (projeção didática)
Em produção: embedding two-tower 128-512 dim
Two-tower model — Amazon, Mercado Livre e Shopee usam arquiteturas two-tower: uma tower aprende embeddings de usuários (histórico → vetor denso), outra tower aprende embeddings de produtos. A recomendação é produto interno entre os dois vetores.
Treinado no próprio catálogo — Os embeddings são aprendidos offline com pares (usuário, produto clicado) sobre milhões de interações. São vetores densos de 128-512 floats, não features interpretáveis.
Nesta demo — Usamos 8 dims com nomes legíveis para clareza didática. Em produção real, o que muda é a dimensão (128-512 vs 8). O pipeline FHE permanece idêntico.
Escalabilidade — CKKS processa 128 dims em ~20 ms e 512 dims em ~60 ms. Para ranking Top-100 sobre Top-1000 pré-filtrado, tempo total fica em 5-10 s — aceitável para o primeiro paint da homepage.
O que o marketplace recebe.
Apenas 1 MB de bytes pseudoaleatórios. O marketplace não tem como reconstruir o perfil — nem agora, nem depois. Resolve dois problemas regulatórios simultaneamente.
Bytes que chegam
74 65 78 74 4d 65 74 61
44 61 74 61 22 3a 7b 22
53 63 61 6c 65 22 3a 7b
...
Os dois problemas que resolve
1. Consent fatigue — Pesquisas mostram que conversão de funis com banners de consentimento explícito caiu 15-35% nos últimos 24 meses. O usuário cansou. Sob FHE, a tela de consentimento pode ser drasticamente simplificada porque o marketplace tecnicamente NUNCA tem dado pessoal para "tratar" no sentido legal da LGPD.
2. Risco regulatório — Multa LGPD por uso secundário de dado é o calcanhar de aquiles do varejo digital. Sob FHE, o uso secundário fica matematicamente impossível. Reduz exposição a multas, class actions, e dano reputacional pós-breach.
Catálogo ranqueado sob cifra.
Para cada produto do catálogo (5 nesta demo, milhões em produção real), o marketplace computa um score de afinidade fazendo produto interno entre os pesos do produto (públicos) e o perfil do usuário (cifrado).
O algoritmo · loop por produto
for prod in catalogo {
// pesos do produto (públicos)
ptW := encoder.Encode(prod.pesos)
// Mul cifrado × público
ctMul := evaluator.Mul(ctPerfil, ptW)
// soma slots = produto interno
ctScore := evaluator.InnerSum(ctMul)
evaluator.Add(ctScore, prod.bias)
}
Performance e escala
Como escala? Para milhões de produtos, o marketplace pré-filtra com busca tradicional não-personalizada (Top 100 por categoria), e aplica scoring FHE apenas no Top 100. 100 × 40 ms = 4 segundos. Aceitável para personalização que carrega após o primeiro paint.
Ranking decifrado.
Top 5 (calculado sem o servidor ver o perfil)
- iSmartphone Premium 256GB+1.61
- iiHeadphone Bluetooth+1.58
- iiiBota Couro Italiana+1.36
- ivTablet Educacional+1.32
- vVestido Floral Verão+0.43
Validação matemática.
Marketplace desonesto.
- 1 — Inferir perfil do ranking5 scores, 8 dimensões. Sub-determinado.
- 2 — Sessões repetidasSó revela ordem relativa, nunca valores absolutos.
- 3 — Recuperar skInviável.
Recomendação privada.
Fluxo
- Browser cifrou perfil de comportamento
- Enviou ciphertext ao marketplace
- Marketplace ranqueou 5 produtos sob cifra (197 ms)
- Browser decifrou e mostrou top 5