Psylo founders disclose three WebKit proxy leaks affecting iCloud Private Relay

Mysk shipped Psylo 1.3.1 to close the paths, which the researchers say can expose a device's IP address or DNS infrastructure.

By · Published

Why it matters

A privacy browser can configure its proxy correctly and still lose control when WebKit or an operating-system service opens a separate connection. Psylo's patch protects its users, while the reported behavior also reaches other proxy browsers and Apple's iCloud Private Relay.

A network diagram or data flow, subtly revealing a hidden leak point (woodcut or scratchboard)

Talal Haj Bakry (@hajbakri) and Tommy Mysk (@tommymysk), the founders behind the Psylo privacy browser, disclosed three WebKit behaviors on August 4th that they say can bypass browser-level proxies and expose a user's real network. The pair also shipped Psylo 1.3.1, which blocks or disables the affected features.

The investigation began with an unusually specific customer complaint. A Psylo user noticed that DNS information leaked on certain websites while other sites behaved as expected, according to Bakry and Mysk's technical disclosure. The founders traced that report to DNS prefetching, then found two additional paths involving passkeys and WebTransport.

That sequence matters for Psylo. Bakry and Mysk built the browser around the premise that each isolated tab, which they call a silo, can route through a separate proxy while keeping its cookies and storage apart. Mysk says its Private Proxy Network offers more than 40 proxy locations.

The founders developed Psylo from years of mobile privacy research, releasing the browser in June 2025 after an earlier beta grew beyond its original scope. Their latest finding came from testing the Apple framework underneath that product, where application code has limited authority over connections initiated elsewhere in WebKit or the operating system.

Three routes around the proxy

WebKit's WKWebsiteDataStore.proxyConfigurations API lets an application send its web traffic through specified proxy servers. In a privacy browser, the intended result is straightforward: websites receive the proxy's IP address, while DNS requests originate from the proxy infrastructure.

Bakry and Mysk say three features escape that route:

  • DNS prefetching: A website can use an HTML hint to ask the browser to resolve a hostname before it is needed. The researchers found that WebKit sends this lookup through the device's ordinary DNS path. A site controlling the destination hostname could therefore observe the visitor's normal DNS infrastructure rather than the proxy's.
  • WebAuthn Related Origin Requests: This passkey feature checks whether related domains are authorized to share a credential. The researchers say the operating system's credential service fetches the validation file directly, outside the browser's configured proxy, exposing the device's IP address to the destination server.
  • WebTransport: This API establishes low-latency connections over HTTP/3 and QUIC. Bakry and Mysk found that WebKit creates the connection without applying the browser session's proxy configuration, allowing the server to receive the device's real IP address.

The timelines differ. WebAuthn Related Origin Requests have been available since iOS 18.0, according to the disclosure. DNS prefetching arrived on iOS in September 2025 with iOS 26.0, following a WebKit change that added support for explicit dns-prefetch hints. WebTransport shipped publicly with iOS 26.4 in March 2026, as documented in WebKit's release notes.

Bakry and Mysk published a proof-of-concept testing page that attempts each technique. Their disclosure is the basis for the claims about how the three paths behave.

Apple's browser rules widen the exposure

Apple's App Review Guidelines generally require applications that browse the web to use the appropriate WebKit framework. Developers can apply for alternative browser-engine entitlements in the European Union and Japan, but most iOS privacy browsers remain dependent on WebKit's networking behavior.

That dependency leaves proxy-browser developers responsible for a privacy boundary they do not fully control. An application can configure ordinary page traffic correctly while a WebKit feature or operating-system service creates a separate connection without the same proxy settings.

Bakry and Mysk say the issue reaches iOS Tor browsers that rely on the same proxy API. They contacted the Tor Project and the developers of Onion Browser, an open-source iOS browser that routes traffic through Tor. The researchers identified one narrower exception: Onion Browser's Silver security level disables WebTransport through Apple's Lockdown Mode configuration, preventing that particular connection path.

System-level VPNs operate differently. Because they tunnel traffic at the device level, Bakry and Mysk say the three application-level proxy bypasses do not escape a properly configured VPN tunnel.

Private Relay shares the boundary

The founders also tested the behaviors with Apple's iCloud Private Relay, the iCloud+ feature designed to protect Safari browsing through two separate relays. Apple says Private Relay encrypts DNS records and separates a user's identity from the websites being requested.

Bakry and Mysk say DNS prefetching, the WebAuthn validation fetch and WebTransport connections take place outside the normal Safari traffic path handled by Private Relay. Under their tests, DNS prefetching exposed the device's DNS infrastructure, while the other two techniques exposed its real IP address.

The disclosure puts Apple and a much smaller browser maker on the same side of the underlying boundary. As of August 5th, Psylo's US App Store listing showed 37 ratings and a 4.4 score. That public footprint is modest, yet a report from one Psylo user led its two founders to examine behavior affecting Apple's own paid privacy service.

Psylo trades compatibility for safer defaults

Psylo 1.3.1 blocks HTML DNS prefetch hints entirely. It also disables WebTransport and WebAuthn by default in every silo, according to both Mysk's disclosure and the version notes on Apple's App Store.

Those choices close the reported paths inside Psylo, while creating compatibility costs. Disabling WebAuthn can prevent passkey flows from working. Disabling WebTransport can affect sites that depend on the newer networking API. Psylo lets users re-enable either feature for an individual silo, making the privacy exposure an explicit setting instead of an invisible consequence of loading a page.

The patch shows the advantage a focused product can have when a platform-level abstraction fails. Bakry and Mysk could not change WebKit's networking implementation, so they narrowed Psylo's exposed feature set and gave users per-session controls. The harder problem sits below the app: browser developers need proxy settings to govern every connection a page can trigger, including work delegated to operating-system services.

Reader comments

Conversation for this story loads after sign-in.