The uncomfortable part of the new WebKit privacy report is not that obscure browser features exist. It is that they can slip around the privacy boundary users think they bought.
Security researchers Talal Haj Bakry and Tommy Mysk say they found three WebKit paths that can bypass browser-level proxy settings on iOS and macOS: DNS prefetching, WebAuthn Related Origin Requests and WebTransport. Their write-up says the same behaviors can affect Apple’s iCloud Private Relay, exposing DNS or real IP information in specific cases. Mysk says Psylo 1.3.1 now blocks or disables the affected features by default.
GearPulse’s view: this matters because privacy tools are sold emotionally. People do not enable Private Relay, Tor-style browsers or proxy browsers because they enjoy network diagrams. They do it because they want a simple promise: the website should not see where I really am. When that promise depends on which browser subsystem made the request, ordinary users are asked to trust machinery they cannot inspect.
What Mysk says is leaking
The report is specific enough to avoid panic and serious enough to avoid shrugging.
Mysk says WebKit-based browsers can use WKWebsiteDataStore.proxyConfigurations to route web traffic through proxy servers. That is important on iOS because Apple requires third-party browsers to use WebKit. If a privacy browser relies on that API, the expectation is straightforward: page traffic should go through the proxy, not directly from the device.
Mysk’s finding is that some WebKit-adjacent features do not follow that route.
| Leak path | What Mysk says happens | Reader translation |
|---|---|---|
| DNS prefetching | WebKit resolves hostnames through the device’s normal DNS path. | A site may see DNS activity from your real network rather than the proxy. |
| WebAuthn Related Origin Requests | The operating system credential service fetches a validation file directly. | A passkey-related check can reveal the device’s real IP address. |
| WebTransport | WebKit opens a direct HTTP/3 connection outside the proxy configuration. | A WebTransport server can see the real IP instead of the proxy IP. |
Mysk says DNS prefetching became relevant on iOS 26.0, WebAuthn Related Origin Requests date to iOS 18.0 behavior, and WebTransport shipped publicly in iOS 26.4. The researchers also make a key caveat: VPNs are not affected in the same way because a VPN tunnels the device’s full network traffic at the system level.
That distinction matters. This is not “all privacy tools are useless.” It is more precise: browser-level proxying and Private Relay can be bypassed by particular browser or OS-level request paths.
Why iCloud Private Relay is in the conversation
Apple’s own support materials describe Private Relay as a privacy feature for iCloud+ subscribers that helps protect browsing activity in Safari by separating who you are from where you are going. Apple’s help pages also make clear that Private Relay has compatibility limits, including cases where websites, networks or services need to see an IP address or perform network filtering.
Mysk’s report lands in a sharper place than normal compatibility. The researchers argue that the affected requests occur outside the standard page-loading route Private Relay is meant to cover. If that is accurate, the issue is not merely a website asking for an exception. It is a browser stack leaking around the privacy path.
That is why the story stings. Apple has spent years positioning privacy as a product feature, not just a settings page. Private Relay is part of that identity. When a real-world edge case shows that “private” depends on which internal component made the connection, it reminds users that privacy promises are only as strong as the boring implementation details.
What users should and should not do
No, this does not mean every iPhone user needs to delete Safari or panic about passkeys. The attack surface described here is narrower than a normal malware scare. A site would need to trigger one of these paths, and the useful exposure depends on the user’s setup and the feature involved.
But the practical advice is different depending on who you are.
| User type | Practical response |
|---|---|
| Casual Safari user with Private Relay | Keep devices updated, understand that Private Relay is not a full-device VPN, and avoid treating it as anonymity software. |
| Proxy-browser user on iOS | Check whether your browser has mitigations for DNS prefetching, WebTransport and WebAuthn behavior. |
| Tor-style browser user on iOS | Watch for guidance from your browser maintainers, because iOS WebKit rules constrain what they can control. |
| High-risk user | Prefer a trusted full-device VPN or stronger isolation model where appropriate, and do not rely on a single browser privacy feature. |
| Developer | Test privacy claims against browser APIs that make requests outside normal fetch/navigation paths. |
The Mysk disclosure says Psylo now blocks DNS prefetch hints and disables WebTransport and WebAuthn by default, with per-silo toggles for users who need them. That is a sensible product response because it puts the trade-off in front of the user instead of hiding it in defaults.
The bigger Apple problem
Apple’s iOS browser-engine policy makes this more than a Psylo issue. If every iOS browser has to sit on WebKit, then a WebKit privacy bug becomes a category problem. Alternative browser vendors can wrap, block, toggle and warn, but they cannot simply ship a different engine with a different network stack on iPhone.
That has been one of the long-running tensions in Apple’s browser policy. The company argues the approach helps security, performance and platform consistency. Critics argue it limits real browser competition. A leak like this gives the critics better ammunition because it shows how a shared engine can make a shared privacy flaw travel widely.
There is also a trust lesson for Apple. Privacy branding works when users feel the default is protective and understandable. It weakens when the answer becomes “Private Relay protects these requests, except the ones issued by a different subsystem, unless you use this other tool, depending on the API.” That may be technically accurate. It is not a confidence-building user story.
Bottom line
The WebKit proxy leak disclosure is relevant because it turns browser privacy from a marketing promise into an implementation audit.
My take: the lesson is not that Private Relay is worthless or that every user needs a VPN tomorrow. The lesson is that browser-level privacy is fragile when modern web features can trigger network activity outside the path users think they selected.
For Apple, this is exactly the kind of bug that needs a clean, public fix trail. For privacy-browser makers, it is a reminder that defaults matter. For users, the simplest rule is still the best one: if hiding your real network is truly important, do not rely on a single convenience feature without understanding its limits.
Support independent GearPulse articles at buymeacoffee.com/gearpulse.site.