Airbnb's Privacy-First Social Features: User and Profile Separation
Airbnb designed new social features with privacy at their core by distinguishing between internal User IDs and context-specific Profile IDs. This architectural decision enables granular control over data visibility, allowing users to customize their public presence for different experiences while preventing inadvertent data correlation. The implementation involved extensive code auditing, permission management via an in-house authorization system, and company-wide collaboration.
Read original on Airbnb EngineeringAirbnb is evolving into a more social ecosystem, aiming to foster connections among guests while strictly adhering to privacy principles. This involves empowering guests to control what information they share and with whom, especially in shared experiences. The core architectural solution to this challenge is the deliberate separation of `User` and `Profile` entities, each with distinct identifiers and access controls.
User vs. Profile: A Foundational Privacy Design
At the heart of Airbnb's privacy-first approach is the clear distinction between a User and a Profile. A `User` represents the complete, internal record of an individual, including sensitive data like names, emails, and account details. This is the canonical identity within Airbnb's systems. A `Profile`, on the other hand, is a public-facing subset of a `User`'s information, tailored for specific contexts. This design allows for different representations of the same user, such as a Host Profile, a Guest Profile, or even Experience-specific Guest Profiles.
Key Decoupling: User ID vs. Profile ID
To enable this context-aware privacy, Airbnb introduced two distinct types of identifiers: * User ID: Represents the internal, unique user entity. A user has only one User ID. * Profile ID: Identifies how a user appears in a specific context. A single User ID can be associated with multiple Profile IDs. This decoupling is crucial for context-awareness, flexible representation, and enhanced privacy controls, making it challenging to link profiles across different contexts without explicit user consent. For example, Marie attending 'Pasta Making' and 'Goat Yoga' can have two separate Profile IDs, each with different visibility settings, preventing others from easily correlating her attendance across experiences.
Granular Access Control with Himeji
To enforce these privacy boundaries, Airbnb utilizes Himeji, their in-house authorization system. Himeji applies least-privileged access principles, ensuring that users (or systems) only see the data they explicitly need. A significant architectural feature of Himeji is its ability to perform configurable relation denormalization at write time. This optimization allows for extremely fast and scalable permission checks at read time, maintaining a seamless user experience even as privacy requirements grow more intricate.
Implementation Challenges and Solutions
- Automated Auditing: Python scripts scanned the codebase for user data access patterns to identify migration candidates.
- Team Ownership Mapping: Findings were mapped to owning teams based on directory structure for efficient task assignment.
- Manual Review: Code owners manually reviewed identified instances to differentiate internal-only from externally used data access.
- AI-powered Refactoring: AI tools suggested code changes, with engineers providing oversight and refinement.
- Company-wide Collaboration: Cross-functional alignment (engineering, product, privacy, legal) was critical for successful prioritization and migration.
The migration also emphasized type safety and automated testing to prevent accidental mix-ups between User IDs and Profile IDs, ensuring robust data isolation. This comprehensive approach underscores the complexity of building a privacy-first social platform at scale.