Thoughts on Responsible Disclosure
First, a little bit of background about us: We’re a team of two behind Psylo, a privacy-focused browser for iOS and iPadOS with built-in access to our own proxy network. Before Psylo and over the past six years or so, we’ve published several security and privacy findings on this blog, focused mostly, but not exclusively, on Apple platforms. We’ve also been quite active on X and Mastodon, sharing our findings along with our frustrations with Apple’s handling of security and bug reports.
We’ve done our best to handle any security findings responsibly: report them privately to Apple and any other affected vendor, then wait for a fix before saying anything publicly. The most recent example was a vulnerability in macOS Archive Utility that bypassed the macOS sandbox and system privacy protections. We considered it serious enough to truly warrant keeping its details under wraps until Apple released a fix.
These WebKit leaks were different from anything we had dealt with before because they marked the first time a system-level issue directly affected our own product. Setting aside the specific history and circumstances involving us and Apple, the dilemma came down to one question:
How do you approach responsible disclosure when a system-level vulnerability directly affects your own users?
We don’t think there is a clear-cut or universal answer. Nor do we believe responsible disclosure can follow a one-size-fits-all approach or a single fixed playbook. The right approach, in our view, is one that allows researchers to exercise judgment based on the nature and severity of the vulnerability, how easily it can be exploited, how responsive the vendor is, and, most importantly, whether users have any way to protect themselves before a fix becomes available. In the case of these leaks, we had mitigations we could ship for Psylo users and a practical workaround that iCloud Private Relay users could apply without waiting for Apple. We’ll get to those in a bit.
At a more basic level, we see the goal of security research as reducing risk for all users across the broader technology ecosystem, not only the users of our own products. Coordinated disclosure is one way of achieving that goal: it gives vendors time to develop fixes before details of a vulnerability become public. But coordinated disclosure is a means of reducing risk, not an end in itself. In some situations, including this one, we believed the traditional process would have left users at greater risk than the approach we ultimately took, as we will argue here.
We first became aware of a DNS leak in Psylo in late June 2026 after a user reported it to us. During our investigation, we found two additional issues that could expose a device’s real IP address. All three originate in WebKit, meaning they affect not only Psylo but also iOS browsers that rely on WebKit’s browser-level proxy configuration, including iOS Tor browsers, as well as Apple’s iCloud Private Relay.
These leaks do not bypass a properly configured, full-device VPN because a VPN routes the device’s network traffic through a tunnel at the system level. This fact played an important role in how we ultimately decided to handle the issues.
In an ideal world, we would report the issues to Apple, Apple would acknowledge them, we would have some follow-up discussions, and a fix would ship within a reasonable timeframe. Unfortunately, our previous experiences with Apple led us to expect lengthy delays, inconsistent communication, and, in some cases, denial of the issue’s impact entirely. Take a moment to look at the report timeline for CVE-2026-28910, which took Apple more than five months to fix after our initial report.
That’s not just our own experience with Apple, either. Researchers at EasyOptOuts reported to Apple in June 2025 that Hide My Email could expose the real address behind a private alias, the very thing the feature is supposed to protect. Apple finally addressed it in July 2026, roughly 13 months later. So the core premise of Hide My Email was broken for more than a year before a fix finally arrived from Apple, even though Apple was fully aware of the issue.
So that’s where we found ourselves after discovering these leaks: WebKit issues were undermining the core privacy promise of Psylo, and our previous experiences suggested that a fix from Apple was many months away at best, if it came at all. We weren’t willing to wait months, let alone a whole year, sitting on these leaks while following the normal path of responsible disclosure. Plus, there wasn’t even a guarantee that Apple’s fix for iCloud Private Relay would extend to third-party browsers.
But let’s say, for the sake of argument, that we had approached Apple before disclosing the issues publicly. What should we have done about Psylo in the meantime?
Should we knowingly leave our users exposed while waiting for Apple to release a system-level fix? That was out of the question for us. We could not continue making Psylo’s privacy promises while knowingly leaving those leaks unaddressed.
Or should we quietly ship our own mitigations without publicly explaining why? We didn’t think that was acceptable either. Security fixes deserve transparency, especially when they involve tradeoffs: Psylo’s mitigations block DNS prefetching and disable WebTransport (a relatively new web standard) and WebAuthn (the technology behind passkeys) by default. Because these changes can affect website compatibility, users needed to know why those APIs are disabled and understand the implications of re-enabling them.
With all that in mind, and with the goal of minimizing risk for as many users as possible, here is what we did:
We first approached the Tor Project and the developers of Onion Browser for iOS privately. As soon as we had working mitigations for all three leaks in Psylo, we shared our findings and solutions with them so they could evaluate similar protections for their own users. We also told them when we planned to disclose the issues and confirmed that they had no objection to us releasing the Psylo update. Only then did we ship our mitigations in Psylo 1.3.1 and disclose the issues publicly.
What about iCloud Private Relay users? As mentioned earlier, these leaks do not bypass a properly configured, full-device VPN. While waiting for Apple to release a fix, iCloud Private Relay users could protect themselves by using one. This video from Techlore is an excellent guide to choosing a privacy-focused VPN. This is also consistent with Onion Browser’s longstanding recommendation that users pair the browser with the Orbot Tor VPN app, since WebKit has leaked IP addresses in similar ways before. The availability of this practical workaround for iCloud Private Relay users made us much more comfortable disclosing the issues before Apple had released a fix.
However, a full-device VPN would not have been a suitable workaround for Psylo users. Psylo is designed so that each tab, or silo, uses its own proxy connection and therefore has a distinct IP address. With a VPN enabled, the WebKit leaks would instead expose the VPN exit server’s IP address and DNS resolver. Those values would be shared across all silos, creating common network identifiers that websites could use to link activity between silos that are supposed to remain separate.
Following the disclosure, we filed a bug report with Apple and shared our disclosure blog post. Apple quickly updated the report’s status to indicate that a fix would arrive in fall 2026. Just days later, it moved up the timeline to summer 2026. Then, on August 17, Apple unexpectedly introduced changes in iOS 27 beta 6, iOS and iPadOS 26.6.1, and macOS Tahoe 26.6.2 that prevent the leaks from bypassing iCloud Private Relay.
Although the fixes were not explicitly mentioned in Apple’s security release notes for macOS Tahoe 26.6.2 or iOS and iPadOS 26.6.1, our testing confirms that the leaks affecting iCloud Private Relay are no longer reproducible on the updated versions. We had never seen Apple act this quickly on any of our previous bug reports.
Importantly, however, Apple’s fix is specific to iCloud Private Relay. It does not correct the WebKit proxy behaviour used by Psylo and Onion Browser, where the leaks remain reproducible without app-level protections. This confirms one of our original concerns: a fix for Private Relay would not necessarily extend to third-party proxy browsers. The mitigations in Psylo and Onion Browser therefore have to remain in place for now.
We cannot be absolutely certain that our public disclosure and the subsequent media pressure accelerated Apple’s response. What we do know is that Apple’s fixes arrived much faster than our previous experiences had led us to expect. We’re quite satisfied with the outcome: Psylo users were protected immediately, the Onion Browser team shipped their own mitigations, and Apple released fixes for iCloud Private Relay within approximately two weeks, far sooner than the 13 months Hide My Email users had to wait.
This might not have been a perfect disclosure process, and reasonable people may disagree with our decision. We’d love to hear your thoughts on responsible disclosure and our reasoning. You can reach us on X and Mastodon. Could we have done things differently? Let us know!