Por Que Funcionalidades Sociais com Foco em Privacidade São Difíceis

Criar funcionalidades sociais em uma plataforma como o Airbnb é um equilíbrio delicado. De um lado, hóspedes e anfitriões querem se conectar — ver quem mais está participando de uma Experiência, trocar mensagens, construir comunidade. Do outro, os usuários esperam controle absoluto sobre seus dados pessoais. Um hóspede que vai a uma aula de "Pasta Making with Nonna" pode não querer a mesma visibilidade de quando participa de uma sessão de "Goat Yoga" com um grupo diferente.

O time de engenharia do Airbnb resolveu isso repensando o modelo de identidade. A sacada principal: um usuário não é um perfil. Ao separar a entidade interna User do Profile público, eles permitiram visibilidade flexível e sensível ao contexto. Essa abordagem é um exemplo clássico de privacidade por design — e cheia de lições para qualquer dev construindo sistemas sociais com múltiplos contextos.

Para ver como um raciocínio arquitetural parecido se aplica a ferramentas de IA, dá uma olhada neste guia sobre conectar agentes de IA a ambientes de prototipagem na nuvem.

Airbnb privacy-first architecture diagram showing User ID and Profile ID separation for context-aware social features Algorithm Concept Visual

A Arquitetura Central: Separação entre User e Profile

O Airbnb introduziu dois identificadores distintos:

  • User ID – O identificador interno e estável da pessoa real. Contém PII completa (nome, email, telefone).
  • Profile ID – Um identificador público que representa como o usuário aparece em um contexto específico. Cada usuário pode ter vários Profile IDs.

Esse desacoplamento permite:

  • Sensibilidade ao contexto: Um Profile só é visível onde é relevante (ex.: uma Experiência específica).
  • Representação flexível: Usuários podem escolher diferentes níveis de detalhe para diferentes contextos (só primeiro nome, perfil completo, etc.).
  • Controles de privacidade: Como os Profile IDs não são ligados entre contextos, fica difícil correlacionar as atividades de um usuário.

Exemplo Real

Imagine que a Mariana participa de duas Experiências Airbnb:

  1. "Pasta Making with Nonna" – Ela escolhe ficar privada. O Profile A mostra só o primeiro nome, sem foto.
  2. "Goat Yoga" – Ela ativa as funcionalidades sociais. O Profile B mostra foto, estatísticas de hóspede e informações "Sobre mim".

Se o Alex participa só do "Goat Yoga", ele vê o Profile B completo da Mariana. Mas se o Alex navegar pelo "Pasta Making with Nonna", ele vê apenas "Mariana" — sem foto, sem ligação entre os dois perfis. O sistema impede a correlação entre contextos por design.

Exemplo de Código: Lógica Simplificada de Criação de Profile

# Pseudocódigo ilustrando a separação User/Profile
from dataclasses import dataclass
from typing import Optional

@dataclass
class User:
    user_id: str
    nome_completo: str
    email: str
    telefone: str

@dataclass
class Profile:
    profile_id: str
    user_id: str          # link interno, nunca exposto
    context_id: str       # ex.: experience_id ou listing_id
    nome_exibicao: str
    foto_url: Optional[str] = None
    is_privado: bool = False

def criar_profile_experiencia(user: User, experience_id: str, is_privado: bool) -> Profile:
    """
    Cria um profile específico para um contexto.
    Profiles privados mostram apenas o primeiro nome.
    """
    nome_exibicao = user.nome_completo.split()[0] if is_privado else user.nome_completo
    return Profile(
        profile_id=gerar_uuid(),
        user_id=user.user_id,
        context_id=experience_id,
        nome_exibicao=nome_exibicao,
        is_privado=is_privado
    )

Mobile app interface mockup of Airbnb Experiences social feature with privacy controls for guest profiles System Abstract Visual

Permissões: Acesso Mínimo com Himeji

O Airbnb usa o Himeji, um sistema de autorização próprio, para aplicar controles de acesso na camada de dados. O Himeji faz desnormalização configurável de relações no momento da escrita — quando um profile ou permissão muda, ele pré-computa as regras de acesso. Isso torna as verificações de permissão em leitura extremamente rápidas e escaláveis.

Decisões de design importantes:

  • Imposição na camada de dados: As permissões são verificadas no nível da query do banco, não apenas na interface. Isso evita vazamentos acidentais por endpoints de API.
  • Princípio do menor privilégio: Cada interação (hóspede-hóspede, hóspede-anfitrião, anfitrião-suporte) tem seu próprio limite de permissão.
  • Profile ID como chave de permissão: O acesso é concedido com base no Profile ID, não no User ID. Mesmo que um User ID vaze, ele não pode ser usado para acessar profiles de outros contextos.

Estratégia de Migração: Auditoria Automatizada + Revisão Humana

Distribuir os Profile IDs por toda a base de código do Airbnb foi um esforço de engenharia gigante. O time usou uma abordagem de cinco etapas:

  1. Auditoria automatizada – Scripts Python vasculharam o código em busca de padrões de acesso a dados de usuário.
  2. Mapeamento de times – Cada achado foi mapeado para o time dono via estrutura de diretórios.
  3. Revisão manual – Donos de código verificaram manualmente cada instância (uso interno vs. externo).
  4. Refatoração com IA – Ferramentas de IA sugeriram mudanças, mas engenheiros revisaram e refinaram cada atualização.
  5. Colaboração entre times – Engenharia, produto, privacidade, jurídico e mais se alinharam nas prioridades.

A segurança de tipos foi uma rede de proteção crítica. Profile IDs e User IDs receberam tipos distintos (ex.: ProfileId vs UserId em TypeScript) para que o compilador pegasse misturas. Testes automatizados e linters reforçaram os limites.

Para outro exemplo de como desenvolvimento assistido por IA pode acelerar prototipagem, veja este artigo sobre criar um agente Slack com a nova skill da Vercel.

Network diagram illustrating least-privilege access control and Himeji authorization system at Airbnb Technical Structure Concept

Limitações e Cuidados

  • Complexidade: A separação User/Profile adiciona indireção. Cada nova funcionalidade precisa considerar qual Profile ID usar, aumentando o overhead de desenvolvimento.
  • Educação do usuário: Hóspedes precisam entender por que têm múltiplos profiles e como controlar a visibilidade. Uma UX ruim pode gerar confusão.
  • Inferência entre contextos: Embora o sistema impeça a ligação direta, atacantes determinados podem inferir conexões através de metadados (horários de reserva, métodos de pagamento compartilhados).

Próximos Passos para Aprendizado

  • Estude frameworks de privacidade por design (LGPD, OWASP Top 10 para privacidade).
  • Explore controle de acesso baseado em atributos (ABAC) como alternativa mais flexível ao RBAC.
  • Experimente ferramentas de autorização na camada de dados como OPA (Open Policy Agent) ou soluções customizadas similares ao Himeji.

Conclusão

A abordagem do Airbnb para funcionalidades sociais com foco em privacidade é uma aula de arquitetura bem pensada. Ao separar User e Profile IDs, eles deram aos usuários controle granular sem sacrificar a comunidade. A combinação de ferramentas automatizadas, revisão humana e tipagem forte tornou a migração gerenciável em escala. Para qualquer desenvolvedor construindo sistemas sociais com múltiplos contextos, esse padrão vale a pena ser estudado — e adaptado.

Fonte: Blog de Engenharia do Airbnb

Este conteúdo foi elaborado com o auxílio de ferramentas de IA, com base em fontes confiáveis, e revisado pela nossa equipe editorial antes da publicação. Não substitui o aconselhamento de um profissional especializado.