Psylo on Mysk Blog – In-Depth Cybersecurity & Mobile App Privacy Research

IP and DNS Leaks in WebKit Affecting Proxy Browsers and Apple iCloud Private Relay

Tue, 04 Aug 2026 00:00:00 +0000

Summary

Our proof-of-concept website leaks.psylo.app that detects the leaks

WebKit-based browsers on iOS and macOS can be built to route all web traffic through proxy servers. This is how all proxy browsers work on iOS, including iOS Tor browsers and our own browser, Psylo. Every network connection a web page makes is supposed to flow through the configured proxy, so websites only ever see the proxy’s IP address. We found three WebKit features that bypass the proxy configuration and send traffic directly from the device instead:

DNS prefetching resolves hostnames through the device’s normal DNS path, which reveals the user’s real DNS servers instead of the proxy’s. Available since iOS 26.0.
WebAuthn Related Origin Requests make the operating system’s credential service fetch a validation file directly from the device. This exposes the device’s real IP address. Available since iOS 18.0.
WebTransport opens a direct HTTP/3 connection and bypasses the proxy, which also exposes the device’s real IP address. Available since iOS 26.4.

These leaks also impact Apple’s iCloud Private Relay. It must be noted that VPNs are not affected, since they tunnel the device’s entire network traffic at the system level.

We’ve reached out to the Tor Project and the developers of Onion Browser on iOS about these issues.

To test the leaks, you can visit our proof-of-concept website at leaks.psylo.app.

Fixed in Psylo 1.3.1: Psylo now blocks dns-prefetch hints and disables WebTransport and WebAuthn by default. For websites that genuinely need these features, each one can be re-enabled through per-silo toggles. This explicit opt-in keeps the privacy trade-offs in the user’s hands. See Mitigations Introduced in Psylo 1.3.1 for details.

Background

Proxy Configuration on iOS and macOS

Introduced in iOS 17 and macOS 14, WKWebsiteDataStore.proxyConfigurations allows WebKit-based browsers route all of their own web traffic through proxy servers at the application level. This API is the foundation of proxy browsers on iOS: every network connection a web page makes is supposed to flow through the configured proxy, so websites only ever see the proxy’s IP address.

DNS Leak Reported by a Psylo User

This investigation started with a bug report from a Psylo user who noticed DNS leaks when visiting only certain websites, and we immediately started looking into it. Psylo routes all traffic from each silo through the Mysk Private Proxy Network (or the user’s own configured custom proxy), so DNS queries should all originate from the proxy server and never from the device. It also seemed odd that this only affected some websites, and not all.

As we dug deeper, we found the source of the DNS leaks, plus two more leaks that actually reveal the device’s real IP address. All three leaks live in WebKit, where they bypass the proxy settings provided by WKWebsiteDataStore.proxyConfigurations. Since Apple’s App Store policy requires every iOS browser to use WebKit, any iOS browser that relies on this API for proxying is affected, including all iOS Tor browsers and Psylo. These leaks are also present in Apple’s iCloud Private Relay. VPNs, on the other hand, are not affected by these issues, since the device’s entire network traffic is tunneled through the VPN at the system level.

iCloud Private Relay

iCloud Private Relay is Apple’s privacy feature for iCloud+ subscribers. When enabled, it proxies Safari’s (and only Safari’s) web traffic and DNS queries through a two-hop relay, designed so that no single party, not even Apple, can see both who you are and which sites you visit. As it turns out, all three leaks described in this article occur outside WebKit’s standard page-loading process, meaning Private Relay is susceptible to the same leaks.

1. DNS Prefetching

DNS prefetching lets a website ask the browser to resolve a hostname before it’s needed. So when later it needs to connect to that hostname, the lookup is already done and the connection starts faster. This is done through a <link rel="dns-prefetch"> HTML tag.

When a page includes that tag, WebKit resolves the hostname through the device’s normal DNS path, regardless of any proxy set by the browser through WKWebsiteDataStore.proxyConfigurations. A page can embed unique per-visitor hostnames in these tags, then watch the queries arrive at its own authoritative DNS server from the visitor’s real network rather than the proxy’s.

This was the leak behind the original user report, and it explains why only some websites triggered it: without prefetch tags on the page, WebKit doesn’t perform this DNS lookup.

Private Relay doesn’t catch this one. It normally proxies Safari’s DNS queries, but these prefetch lookups skip it. The query reaches the authoritative server from the device’s real network even with Private Relay enabled.

Desktop Safari has supported <link rel="dns-prefetch"> since Safari 5, but iOS ignored it until iOS 26.0 (September 2025), when WebKit enabled it in the same change that removed iOS’s older, implicit speculative DNS prefetching (bug 285744, 290327@main; browser-compat data). That resolver had been rewritten the year before, to keep hostnames out of system logs during private browsing (bug 272190, 279199@main).

WebAuthn is the web standard behind passkeys. A passkey is normally bound to a single domain, but Related Origin Requests let an organization use one passkey across a small set of domains it owns.

To make that work, when a page requests a credential whose rpId differs from its own origin, the client first fetches https://<rpId>/.well-known/webauthn, a JSON file listing which origins may use that rpId.

That validation fetch doesn’t come from the browser’s network stack. WebKit hands WebAuthn ceremonies to the operating system’s credential service, which issues the HTTPS request itself, directly from the device and unaware of any proxy the host app configured. A page can set rpId to a host of its choosing, and the fetch fires even without user interaction: with mediation: "conditional" and no UI ever appears.

The same reasoning applies to iCloud Private Relay. Because the fetch is issued by the operating system’s credential service rather than by Safari, it never enters Private Relay’s proxied path. The destination server sees the device’s real IP address either way.

Apple announced the feature for iOS 18.0 / Safari 18.0 (September 2024) in WebKit Features in Safari 18.0. WebKit’s half of the plumbing landed earlier that year (bug 268426, 274592@main) and even shipped, inert, in iOS 17.4; the system component that performs the fetch only gained support in 18.0.

3. WebTransport

WebTransport is a low-latency alternative to WebSocket. It runs over HTTP/3 and QUIC, offers multiple independent streams plus unreliable datagram delivery, and can fall back to HTTP/2 where QUIC is unavailable.

Calling new WebTransport(url) opens a QUIC connection straight from the device. WebKit builds the connection with its own network parameters and never offers it the session’s proxy, so the server sees the device’s real IP address instead of the proxy’s.

Private Relay doesn’t help here either. WebKit builds the connection outside the web traffic that Private Relay proxies, so a WebTransport server learns the device’s real IP address even with Private Relay enabled.

There is one exception: Onion Browser’s “Silver” security level configures WebKit with Lockdown Mode, which disables WebTransport entirely, so Onion Browser users at the Silver level are not affected by this particular leak.

First traces of the API appeared in 2023 (bug 260810, 267408@main) but sat disabled until December 2025, when it was switched on for platforms with sufficient Network.framework support (bug 303453, 303860@main). It shipped publicly in iOS 26.4 (March 2026); see WebKit Features for Safari 26.4 and the Safari 26.4 Release Notes.

Mitigations Introduced in Psylo 1.3.1

We’ve addressed all three leaks in Psylo 1.3.1:

Psylo blocks dns-prefetch hints, so a page can no longer make your device resolve attacker-controlled hostnames.
WebTransport is disabled by default.
WebAuthn is disabled by default.

Passkeys and WebTransport have legitimate uses, so both can be re-enabled at any time through per-silo toggles. This keeps Psylo leak-free out of the box, while users who need one of these features on a given site can opt in explicitly, with a clear understanding of the trade-off.

Psylo 1.0 System Architecture [Updated]

Mon, 30 Jun 2025 09:17:00 +0500

Since Psylo isn’t currently open source, transparency is crucial to earn our users’ trust. We’re always ready to answer your questions and provide more details via X, Mastodon, and Bluesky.

Overview

Psylo 1.0.5 Architecture Diagram

Psylo is a privacy-focused web browser for iOS and iPadOS. Each browser tab, known as a silo, provides isolated storage, cookies, and even a unique IP address through integration with the Mysk Private Proxy Network. When browsing, traffic from each silo is securely tunneled through one of over 40 proxy servers within this network, which further routes traffic through Proton VPN exit nodes via WireGuard.

Subscribing through the App Store [Updated: 2025-09-04]

Psylo is offered as a subscription using Apple’s In-App Subscription system. A key goal for Psylo is maintaining complete user anonymity — we never want to know the identities of our users. Thus, users aren’t required to create accounts or provide any personally identifiable information (PII), such as names, emails, or phone numbers. Instead, Psylo leverages Apple’s subscription infrastructure, which does not share any PII with developers, keeping user identities anonymous to us.

Here’s how subscribing works:

Subscription Purchase: Users can subscribe to Psylo through Apple’s in-app purchase system. Alternatively, they may choose to try Psylo without subscribing, in which case Psylo relies on the App Store’s app transaction record rather than a subscription record. The app generates a random subscription ID, sent as an “App Account Token” alongside the transaction. (Note: If you already see a concern here, we address it later in this post.)
Signed App Store Transaction Objects: Apple issues both a signed subscription transaction and app transaction objects containing no PII, meaning we can’t trace subscription IDs back to individual users.
Transaction Validation: The Psylo app forwards both transaction objects to Psylo Server, our Swift-based backend responsible for subscription validation, authorization, bandwidth tracking, and other critical aspects of the system (more details in future posts).
Issuing Access Tokens: After validating and storing the transaction, Psylo Server returns a signed access token to the Psylo app.
Proxy Connection: Using this access token, the Psylo app establishes secure HTTPS tunnels from each silo to the Mysk Private Proxy Network.

Mysk Private Proxy Network

Central to Psylo’s design is the Mysk Private Proxy Network, currently comprising over 40 servers. Each silo can be configured to independently connect to any of the servers distributed globally in the following countries:

Canada
Germany
United States
United Kingdom
Japan
Australia
Brazil

Cloud Providers

Our infrastructure is built on servers and virtual machines from DigitalOcean, Hetzner, and Vultr. Each instance runs software which we fully control, and we’ve avoided managed services such as managed databases.

Proxy Servers

Each node hosts an HTTPS proxy server routing HTTPS traffic between silos and destination websites via a Proton VPN exit node. Proxy servers cannot inspect the contents of HTTPS traffic, although they do see destination hostnames. Our strict no-log policy ensures no host or IP data is logged or stored. Network requests remain in memory, never cached or persisted.

DNS Filtering [Updated: 2025-09-04]

DNS requests pass through the Mysk Private Proxy Network and are resolved using multiple providers, including Cloudflare, Control D, Quad9, dns0.eu, and OpenDNS. All DNS requests originate from our proxy servers, so none of these providers ever see DNS queries coming directly from your device.

This design provides two primary benefits:

DNS requests are invisible to ISPs or local network monitors. (iOS apps cannot configure custom DNS settings.)
Known tracking domains are filtered out, preventing websites using tracking scripts from receiving network requests from Psylo users.

Proton VPN Exit Nodes

We’re excited to reveal that we’re currently working with Proton VPN to provide VPN connections for each proxy server. Websites accessed via Psylo only see Proton VPN IP addresses, and Psylo users enjoy many of the benefits provided by Proton VPN.

A key benefit of using Proton VPN as our network’s exit nodes is “clean” IP addresses. Since our proxy servers are hosted by cloud providers, many popular websites—such as Reddit and YouTube—typically block or restrict traffic originating from datacenter IPs. By routing traffic through Proton VPN exit nodes, we’ve successfully restored reliable access to these websites. We plan to continue our collaboration with Proton VPN as we scale our service.

No-Logs, Bandwidth Reporting

The Mysk Private Proxy Network strictly adheres to a no-log policy. We do not log any personally identifiable information, IP addresses, browsing history, or DNS requests. Bandwidth usage is monitored solely for quality assurance and abuse prevention. To further enhance privacy, all reported bandwidth is rounded down to the nearest 50 MB increment, minimizing the granularity of information contained in usage reports.

Trade-offs and Future Improvements

For Psylo 1.0, we’ve had to take many technical decisions to balance usability, privacy, and technical feasibility. Below we want to address 2 1 main trade-offs we’ve identified in this initial release:

~~A notable trade-off involves the randomized subscription ID and sharing it with Apple. Although not ideal, we believed this was an acceptable trade-off for the following reasons:~~

Users can easily share Psylo subscriptions across multiple devices linked to one Apple account or restore subscriptions seamlessly after app reinstalls. Psylo automatically restores subscriptions without additional authentication.
~~Even in scenarios involving data breaches or court orders compelling disclosure, information would remain limited to approximate bandwidth usage (rounded to the nearest 50 MB).~~

In the future, we aim to eliminate sharing subscription IDs with Apple entirely by introducing a “subscription restore token” system, where users securely store tokens in their preferred password managers. This approach would place more burden on users, but would eliminate the need to share the randomized subscription ID with anyone, including Apple.

Starting with Psylo 1.0.5, we no longer share the randomized subscription ID with Apple when users subscribe. We’ve significantly redesigned how Psylo Server manages subscriptions, enabling us to offer free trials without requiring users to commit to Apple’s In-App Purchase system. This change also paves the way for introducing alternative payment options in the future, including cryptocurrency.

Bandwidth Caps

As highlighted in our announcement post, Psylo sets a conservative 50 100 GB/month bandwidth cap per user to safeguard network integrity from potential abuse. However, we intend to increase or eliminate these limits entirely as we get a better understanding of how our system performs in production. Our long-term goal is to remove bandwidth caps and eliminate bandwidth tracking completely.

Questions? Comments?

We hope this provided insight into Psylo and the Mysk Private Proxy Network. If you’d like to learn more or have more questions, reach out to us via our social media:

Download Psylo Today!

Psylo is available for iOS and iPadOS through monthly or annual subscriptions, with a free 7-day trial offering full access to all features. ~~Use the discount code PSYLOPARTY for 30% off your annual subscription.~~

Introducing Psylo — A New Kind of Private Web Browser

Tue, 17 Jun 2025 09:17:00 +0500

Psylo — A New Kind of Private Browser

Why a Web Browser?

Funny enough, we didn’t initially set out to build a whole web browser.

As occasional privacy researchers, we and many others have noted how native apps utilize extensive tracking SDKs. These SDKs collect all kinds of data to “fingerprint” users, aiming to track them across different apps and even across devices, primarily for targeted advertising. This is not limited to the usual suspects, like free mobile games and social media apps, but also business apps like Microsoft Outlook, which include various advertising and tracking SDKs.

To their credit, Apple has consistently improved privacy measures, notably introducing App Tracking Transparency in iOS 14, App Store Privacy Nutrition Labels, and Privacy Manifests. Their latest efforts even restrict app developers from certain APIs that can potentially be misused for tracking without disclosure. However, despite Apple’s best efforts, companies continue to discover new methods to circumvent these protections, as we previously discussed here.

One common practice to avoid the invasive tracking of native apps is to use web-based versions offered by apps such as X, Instagram, LinkedIn, and others. Web apps inherently have fewer permissions and significantly reduced fingerprinting capabilities compared to their native app counterparts. iOS and iPadOS also conveniently support adding Progressive Web Apps (PWAs) directly to the Home Screen, making them as easy to open as regular native apps.

However, as we will discuss, web browsers themselves aren’t immune to more advanced fingerprinting techniques, even when used alongside VPNs. This is where we saw an opportunity for something new.

Web Silos, or Isolated Web Sessions

Last October, we started building an app simply focused on creating fully isolated web sessions, tailored specifically for PWAs. Each isolated session (what we call a silo) gets its own dedicated storage, cookies, and cache, fully separate from other silos. On top of that, we built our own proxy network, initially with just 5 servers.

An early version of Psylo

This early app proved quite promising. For instance, you could have a silo for your personal X account through a proxy in Germany, another silo for Instagram via a US proxy, and a separate silo for another account through Canada. These silos are fully isolated, each with separate data storage and even distinct IP addresses, significantly reducing cross-site and cross-session tracking.

That said, we already knew our work was far from over, and addressing fingerprinting required more than simply masking IP addresses.

Fingerprinting: Languages, Timezones, Canvas, and Lots More

But first, what is fingerprinting?

Fingerprinting is a technique that attempts to track a user across different apps and websites, without the need have a unique user ID that could be shared across those apps. It works by gathering subtle signals and characteristics about the user’s device, such as phone model, system language, timezone, IP address, and even graphics rendering quirks (known as canvas fingerprinting). More advanced techniques even consider factors like average scroll speed and mouse movement patterns.

As a simple example, consider this basic set of characteristics collected by Website A from an unknown user:

Phone Model: iPhone 14 Pro Max
Operating System Version: iOS 18.4.1
System Locale: English (Canada)
System Timezone: Europe/Madrid
IP Address: 79.127.215.215
IP Address Country: Paris, France (through a VPN)
Browser Window Size: 405x865

Here we have a user who uses an iPhone 14 Pro Max, running iOS 18.4.1, from Canada, currently in Spain, their IP address is in Paris, and their browser window has a size of 405x865 pixels. That exact combination of characteristics would constitute a fingerprint, and Website A can share it with Website B. Later, when a user who happens to have those same fingerprint characteristics (i.e. iPhone 14 Pro Max, from Canada, in Spain, etc.) visits Website B, it can make a good guess that it’s the same user who visited Website A earlier.

Now let’s say that same user switched to a different VPN server in Denmark. With all other factors remaining unchanged, it would still be a fairly good guess that it’s the same user. The likelihood of another user sharing those exact same combination of characteristics (i.e. same phone model, OS, language, timezone, browser window size, etc) is low.

As this is a simple fingerprinting example with only 7 factors, the resulting fingerprint is “fuzzy” and guesses about the user’s identity may not be reliable. Actual fingerprinting techniques include dozens of factors, with each added factor making the fingerprint “sharper,” thus more likely to reliably identify a user.

The goal of any anti-fingerprinting system is to make the user’s fingerprint as fuzzy as possible, making it more difficult to accurately track them.

Now for a real example

For a real example of fingerprinting, let’s look at Fingerprint, which offers fingerprinting as a service to other websites and apps, with the stated goal to “Identify Every Visitor” to “Stop fraud, detect bots, or delight customers.”

Fingerprint successfully generated the same visitor ID for 2 distinct Safari 18.4 profiles

We tested out their service by simply visiting their homepage, which displays our unique fingerprint, using Safari 18.4 for Mac. For this test, we created 2 new browsing profiles ensuring they don’t share any cookies or data and visited https://fingerprint.com from 2 separate IPs via VPN. Despite our attempt to cover our tracks, Fingerprint successfully generated the same visitor ID for both windows.

Beyond a VPN

Despite using a VPN through Denmark, a website can still infer your country and where you might be traveling based on timezone

VPNs alone can’t quite counteract fingerprinting, since all they can do is mask your IP and potentially block known tracking scripts and domains. To see this for yourself, we made this proof-of-concept web page that relies on simple JavaScript calls to infer your country, potentially revealing if you’re traveling to another country via your system’s timezone settings, even if connected via VPN.

This is one place where Psylo really shines. Not only does every silo get a unique IP address through our proxy network, but it also matches the locale and timezone of its associated proxy server. For example, if a silo connects through a German proxy, it automatically adjusts the browser’s language and timezone accordingly, making those fingerprint factors similar to actual users from Germany, thus making your fingerprint fuzzier.

Psylo also includes more common anti-fingerprinting measures, such as canvas randomization, typically only found in desktop versions of privacy-focused browsers such as Brave, but not on iOS. This is due to Apple limiting apps to use the system-provided WKWebView. We were able to achieve this through a client-side JavaScript solution, which powers many of our anti-fingerprinting measures.

Pyslo can successfully evade the advanced fingerprinting techniques used by Fingerprint. (Test performed on the same iPhone using Psylo 1.0.0 in June 2025)

Early Beta, and Realizing We’re Building a Browser

We seeded the first beta of Psylo in February. That version of Psylo was far more limited compared to the version we’re releasing today: Only 5 generic proxies (which didn’t specify a country), a rudimentary browser user interface (it wasn’t supposed to be a browser, after all), and most importantly it was missing the Default Browser Entitlement that Apple selectively grants to developers of browser apps. Despite its name, this entitlement not only grants browser apps the ability to become the user’s default browser of choice. It also provides all-important browser features, such as password manager integration, passkeys, Service Workers, and even better performance.

Even then, the initial reaction we got to Psylo was encouraging, but we struggled to convey what we thought Psylo should be: It wasn’t a browser, it was intended for using PWAs through our private proxy network. As silly and obvious as it sounds now, we were actually building a browser but didn’t quite want to admit it yet…

So now that we’ve committed to building a browser, the first step was to apply to Apple for Default Browser Entitlement. Not knowing what to expect, we filled this form and sent it off to Apple. Luckily, 3 weeks later we got this email from Apple granting us the Default Browser Entitlement.

We're a browser vendor now!

Mysk Private Proxy Network

We’ve gotten this far into the post without discussing a major component of Psylo: our scalable global network of no-log proxy servers, which we call the Mysk Private Proxy Network. Currently consisting of 40+ proxy servers worldwide, it’s designed to scale as we grow our service. Psylo seamlessly integrates with Mysk Private Proxy Network, allowing per-silo proxy connections.

From the outset, we established the following primary design requirements for our proxy network:

Our Software: The system must operate exclusively on software that we either developed ourselves or maintain complete control over. This requirement is essential not only to meet the other criteria listed below but also to ensure we’re fully aware of any limitations within our system.
No Logs: The system must never log or otherwise store any personally identifiable information or browsing data, including but not limited to IP addresses, DNS requests, and any other data that could potentially identify a user.
No User Accounts: The system must be accessible without requiring users to create an account—in fact, the system must have no notion of user accounts whatsoever. The only information the system should recognize is whether a connection to the proxy network is associated with an active subscription. Subscription tracking must rely exclusively on randomized identifiers.
Bandwidth Tracking and Abuse Prevention: The system must track bandwidth usage for each subscription to prevent abuse and maintain quality of service for all subscribers. It must also have the capability to block subscriptions deemed abusive from accessing the network.

We believe we’ve successfully implemented all of the above requirements in the initial rollout of the Mysk Private Proxy Network, with the most challenging being requirements (3) and (4).

We absolutely did not want to force users to create and manage accounts with us (unlike some other browsers, which may no longer exist), nor did we even want user accounts as an option. Our primary concern is simply verifying whether an anonymous user accessing the proxy network holds an active subscription.

Since Psylo is an iOS and iPadOS app, the default method for offering subscriptions is through In-App Subscriptions. Again, to Apple’s credit, when users make a purchase through the App Store’s In-App Subscription system, developers never receive any personally identifiable information associated with those purchases. This fits nicely with requirement (3), allowing Psylo users to subscribe without creating an account or revealing their identity to us. It also opens the door for potentially offering alternative payment methods in the future.

Regarding requirement (4), it was essential for us to ensure the proxy network could be maintained and scaled effectively as our user base grows. To achieve this, we built our own monitoring system. However, our primary concern remained preventing abuse of the proxy network. For this initial rollout, we decided to err on the side of caution and set bandwidth limits at ~~50 GB~~ 100 GB per month per user. In the coming months as we gain a better understanding of how the system performs in production, we’ll happily consider increasing these bandwidth limits for all our users.

Details, Details, Details

There are so many further technical details about Psylo and the Mysk Private Proxy Network that we’d love to explore further: such as how we handle proxy authentication, strange and unexpected quirks of WKWebView, challenges with Cloudflare, SwiftUI shenanigans, issues with different cloud providers, the weird and possibly shady world of proxy providers, securing our Swift-based application server, remote app configuration, localization, and much more. We’ve gained a tremendous amount of knowledge during the nine months we spent developing Psylo and plan to share more insights over the coming months.

What’s Next?

Releasing version 1.0.0 of a new product is always nerve-racking, especially for an app like Psylo, with so many moving parts. So many thoughts cross our minds: How will it be received? Did we miss something so glaringly obvious in our system design? What if the system crashes and doesn’t hold up under load?

We are also very aware of how many features Psylo 1.0.0 still lacks and how much better it can become. However, we’ve reached a point where we believe this initial release is compelling enough to share with the world.

The most frequent request during our beta period was an Android version. While it’s too early to commit, an Android version will surely be on the table if the iOS version proves successful.

We really look forward to your hearing your thoughts and feedback. Psylo is available today for iOS and iPadOS through monthly or annual subscriptions, with a free 7-day trial offering full access to all features. ~~Use the discount code PSYLOPARTY for 30% off your annual subscription.~~

Contact & Support

For any comments, feedback, or support requests, you can reach us via our social media accounts:

Acknowledgements

First, we would like to extend our heartfelt thanks to all of our followers on X, Mastodon, and Bluesky. Special thanks goes out to our beta testers, whose valuable feedback significantly helped shape Psylo. If you participated in our beta testing and would like a special discount, please contact us through any of our social media channels.

During development, we found BrowserLeaks immensely useful for testing our anti-fingerprinting measures.

Psylo on Mysk Blog – In-Depth Cybersecurity & Mobile App Privacy Research

IP and DNS Leaks in WebKit Affecting Proxy Browsers and Apple iCloud Private Relay

Summary

Background

Proxy Configuration on iOS and macOS

DNS Leak Reported by a Psylo User

iCloud Private Relay

1. DNS Prefetching

2. WebAuthn Related Origin Requests

3. WebTransport

Mitigations Introduced in Psylo 1.3.1

Psylo 1.0 System Architecture [Updated]

Overview

Subscribing through the App Store [Updated: 2025-09-04]

Mysk Private Proxy Network

Cloud Providers

Proxy Servers

DNS Filtering [Updated: 2025-09-04]

Proton VPN Exit Nodes

No-Logs, Bandwidth Reporting

Trade-offs and Future Improvements

Sharing Subscription ID with Apple [Updated: 2025-09-04]

Bandwidth Caps

Questions? Comments?

Download Psylo Today!

Introducing Psylo — A New Kind of Private Web Browser

Why a Web Browser?

Web Silos, or Isolated Web Sessions

Fingerprinting: Languages, Timezones, Canvas, and Lots More

But first, what is fingerprinting?

Now for a real example

Beyond a VPN

Early Beta, and Realizing We’re Building a Browser

Mysk Private Proxy Network

Details, Details, Details

What’s Next?

Contact & Support

Acknowledgements