Advanced Browsing Protection (ABP) in Messenger is designed to enhance user privacy while simultaneously providing warnings about potentially harmful links. This sophisticated feature operates within the framework of end-to-end encryption (E2EE), ensuring that direct messages and calls remain secure. However, it extends its protective capabilities to links shared in these encrypted communications, alerting users to unsafe websites that may compromise their personal information.
At its core, ABP utilizes on-device models to analyze links shared in chats, but it goes a step further by employing a dynamic watchlist of millions of potentially malicious sites. This proactive approach to link safety is underpinned by a complex system of cryptographic primitives, all meticulously engineered to prioritize user privacy.
Private Information Retrieval – The Starting Point for ABP
The foundation of ABP is akin to a cryptographic primitive known as private information retrieval (PIR). In a classical PIR scenario, a client queries a server that holds a database to determine whether a specific item is present. The goal is to minimize the information the server learns about the client’s query. While theoretically, the server could send the entire database to the client for independent querying, practical limitations arise due to the size and the need for frequent updates.
To enhance this process, an oblivious pseudorandom function (OPRF) can be employed, along with the division of the database into multiple shards. However, this method presents challenges, particularly with URL-matching queries, which do not align with exact matches. Additionally, the client must indicate which shard to query, creating a balance between privacy and efficiency.
- OPRFs excel with exact matches, but URL queries often require a more nuanced approach.
- The need for the client to specify the shard introduces a trade-off between privacy and operational efficiency.
While alternative cryptographic constructions exist to mitigate these trade-offs, they may not yet be practical for large-scale applications, leaving room for future advancements in this area.
How ABP Handles Prefix Queries for URLs
ABP’s database comprises URL domains, which may not always correspond to exact matches. For instance, if “example.com” is in the database, a query for “example.com/a/b/index.html” should still yield a match. To facilitate this, a privacy-preserving URL-matching scheme is essential.
One approach considered was to execute multiple parallel queries for each path prefix of the URL, which, while effective, risks leaking additional information about the client’s query. To address this, the server groups links by domain, allowing the client to request a single bucket corresponding to the domain and check all path components for membership.
This method, however, can lead to unbalanced bucket sizes, particularly when many blocklisted URLs share the same domain. To counter this, the server performs a pre-processing step to generate a “ruleset” that balances the buckets, ensuring that the client can efficiently access relevant information without compromising privacy.
Pre-processing Rulesets
The server generates a ruleset that maps hash prefixes to specific path segments, allowing the client to compute a bucket identifier efficiently. This iterative process ensures that any URL with a blocked prefix hashes to the correct bucket, provided the blocklist does not contain redundant entries.
During the lookup process, the client applies the same ruleset to compute the bucket identifier and sends it to the server, along with OPRF-blinded elements for each path segment. The server then responds with the bucket contents and OPRF responses, allowing the client to check for matches and flag unsafe URLs.
Safeguarding Client Queries
To further protect client queries, additional mechanisms are employed. AMD’s SEV-SNP technology creates a confidential virtual machine (CVM) that processes hash prefixes securely. This environment allows for the establishment of a secure channel between the client and the CVM, ensuring that sensitive information remains protected.
Confidential Computing
The CVM generates attestation reports that verify the integrity of the application logic running within it. These reports contain essential information, including a public key for secure communication. Clients can verify these reports to establish trust before transmitting sensitive data.
Oblivious RAM
To prevent exposure of memory access patterns, the server employs techniques such as loading multiple copies of the database into memory and utilizing Path ORAM to optimize access efficiency while maintaining privacy.
Using Oblivious HTTP
To enhance privacy further, a third-party proxy processes client requests through the Oblivious HTTP (OHTTP) protocol, stripping identifying information before forwarding them to the server. This additional layer of anonymity helps obscure client identifiers, such as IP addresses.
The ABP Request Lifecycle
The lifecycle of an ABP request unfolds in several stages:
Pre-processing/background phase:
- The server periodically updates the URL database and computes a balanced ruleset.
- These buckets are loaded onto a trusted execution environment (TEE) using ORAM.
- The TEE generates a keypair, embedding the public key in an attestation report.
- The attestation report and ruleset are shared with clients through a third-party proxy.
- Clients verify the report and store the public key and ruleset locally.
On each client request:
- The client calculates the bucket identifier for the clicked link.
- This identifier is encrypted for the specific CVM instance.
- The client computes OPRF requests for each path segment of the URL.
- The encrypted identifier and OPRF requests are sent through a third-party proxy.
- The server precomputes OPRF responses and retrieves the corresponding bucket contents.
- The server returns the encrypted responses to the client.
- The client decrypts the response and checks for matches, flagging any unsafe URLs.
