Apple's NEURLFilter API

At WWDC 2025, Apple introduced an interesting new URL Filter API to respond to a key challenge we’ve talked about previously: the inherent conflict between privacy and security when trying to protect users against web threats. That conflict means that security filtering code usually cannot see a browser (or app’s) URLs to compare them against available threat intelligence and block malicious fetches.

Their presentation about the tech provides a nice explanation of how the API is designed to ensure that the filter can block malicious URLs without visibility into either the URL or where (e.g. IP) the client is coming from.

At a high-level, the design is generally similar to that of Google SafeBrowsing or Defender’s Network Protection — a clientside bloom filter of “known bad” URLs is consulted to see whether the URL being loaded is known bad. If the filter misses, then the fetch is immediately allowed (bloom filters never false positive). If the bloom filter indicates a hit, then a request to an online reputation service is made to get a final verdict.

Now, here’s where the details start to vary from other implementations: Apple’s API sends the request to an Oblivious HTTP relay to effectively “hide” the client’s network location from the filtering vendor. Homomorphic encryption is used to perform a “Private Information Retrieval” to determine whether the URL is in the service-side block database without the service actually being able to “see” the URL.

Requests are sent from WebKit and Apple’s native URLSession API. Browsers not built on Apple’s HTTPS fetchers can participate

Neat, right? Well, yes, it’s very cool.

Is it perfect for every use product? No.

Inherent in the system design is the fact that Apple has baked its security/privacy tradeoffs into the design without allowing overrides. Here are some limitations that may cause filtering vendors trouble:

1. Reputation checks can no longer discover new URLs that might represent unblocked threats, or use lookups to prioritize security rescans for high-volume URLs.
2. Determining which client device performed a reputation check (allowing a Security Operations Center to investigate any potential compromise) isn’t possible.
3. The fastest allowed Bloom filter update is 45 minutes.
4. There does not seem to be any mechanism to control what portions of a URL are evaluated such that things like rollups can be controlled.

You can learn more about Apple’s new API in the NEURLFilterManager documentation.

-Eric

Published by ericlaw

Impatient optimist. Dad. Author/speaker. Created Fiddler & SlickRun. PM @ Microsoft 2001-2012, and 2018-, working on Office, IE, and Edge. Now working on Microsoft Defender. My words are my own, I do not speak for any other entity. View more posts