Apple’s privacy promise, punctured
Apple sells iCloud Private Relay as a privacy feature for people who pay for iCloud+. In plain terms, it’s supposed to hide your IP address when you browse in Safari, so websites see less about where you’re and what device’s reaching them. That’s the bargain, and fewer network identifiers. Less easy tracking. Less chance that a site can pin you to a place, a household, or a pattern of late-night doomscrolling that your browser would rather keep to itself.
The problem is that the promise has a hole in it.
From there, New findings show that a set of browser-engine quirks can let a website recover a user’s real IP address even when Private Relay’s switched on. So the privacy layer’s there, but in some cases the address underneath still leaks through. That’s a rough look for a product marketed as a shield. If the shield sometimes leaves your name tag hanging out the back, people notice.
Private Relay is supposed to keep network identifiers out of easy reach. Those identifiers matter because they can reveal location at a rough but useful level, and they can help sites infer browsing habits across sessions. An IP address doesn’t tell the whole story, of course. It won’t name you or print your search history on a receipt. But it does give away enough to make tracking easier, which is why privacy tools obsess over it in the first place.
A privacy feature that leaks your real IP in the background is doing the opposite of what the box promises.
That’s why this finding lands harder than a garden-variety bug report. A typo on a settings page’s annoying. And a rendering glitch’s embarrassing. But a privacy service that occasionally hands over the very data it exists to hide creates a different kind of mess. It means the product can’t be treated as a simple on or off switch for anonymity. Users have to wonder when the protection applies, when it slips and whether the site they just visited learned more than it should have.
For iPhone users, the stakes are even more awkward because Safari is the browser Apple itself points to when talking up Private Relay. The feature lives inside the same system that asks people to trust Apple with passwords, payments, location prompts, plus enough personal history to make any security team sweat a little. That trust is the whole game. Once a privacy feature’s caught failing at the basic task it advertises, the marketing copy starts to sound less like reassurance and more like a punchline.
There’s also a broader issue here that goes beyond one unlucky site or one obscure edge case. If a browser can leak your real IP under conditions that look normal to the user, then the bug isn’t merely technical. It becomes a product problem, a trust problem, and, given Apple’s heavy privacy branding, a public one. Plenty of people buy into Apple’s privacy pitch because they want something simpler than juggling separate tools, extra settings, and browser-specific caveats. They want the device to do what it says on the tin. Reasonable ask, honestly.
That’s what makes this report awkward for Apple. The company’s spent years turning privacy into a selling point across tech news, ai policy chatter, digital culture debates and even power and politics arguments about who controls user data. Private Relay sits squarely inside that story. If it can leak the very address it was built to mask, then the gap between the promise and the product gets hard to ignore.
The next question is how that leak gets through in the first place. On the surface, nothing looks strange to the user. A page loads, a login flow runs, and the site still gets a crack at the real network details. That’s where the story gets less like a privacy brochure and more like a browser-engine headache.
How the leak slips past Safari
Apple says iCloud Private Relay hides a user’s IP address and browsing activity in Safari by sending web traffic through separate internet relays. Its iPhone setup guide for Private Relay and broader privacy features page describe the same basic promise in slightly different packaging: websites should see less about where you are and what you’re doing. That’s the pitch. The catch is that some login flows do not stay neatly inside Safari’s normal traffic path.
Passkeys are where this gets awkward. Built on the WebAuthn standard, they let a site ask for a credential stored on the device instead of a password typed into a box. On an iPhone, that often means Safari hands the job off to iOS itself. The browser starts the process, but the actual credential check can be handled by Apple’s system service for passwords and passkeys, which then talks to the website on behalf of the device. To the user, it looks like a routine sign-in. A Face ID prompt appears, a button gets tapped, and that’s that.
When the browser hands login work to the operating system, the privacy layer around Safari may never see the request.
That handoff is where the leak sneaks in. Private Relay is designed to proxy Safari’s web traffic, but the credential request triggered by passkey handling can leave through iOS’s own service rather than through Safari’s relay path. Once that happens, the site on the other end can receive the device’s real IP address. No drama, no warning banner, no visible failure. The user thinks they are simply logging in. The server thinks, “Ah, hello, here’s your actual network address.”
That distinction sounds fussy until you remember what an IP address gives away. It can point to a general location, a network provider and sometimes enough context to make browsing habits easier to track. Private Relay was sold as a way to blur that trail. Then the protection has a blind spot right in the middle of the experience it was meant to cover, if a login flow sidesteps the relay and sends the real IP anyway.
The interesting part, from a technical angle, is that the site doesn’t need to do anything especially clever. If it supports passkeys, it can trigger the WebAuthn flow and end up in the credential exchange. The same sort of handoff can still happen during the handshake, if it only pretends to support passkeys. In other words, the site doesn’t have to be a dedicated attacker with custom code. It just needs to ask for the credential flow in the normal way that modern login pages do. That makes the issue easier to stumble into, which is usually how the messy bugs show up in the real world.
A proof-of-concept site used by the researchers made the problem obvious. In testing, the page returned the device’s actual IP address instead of the one Private Relay was supposed to present. That’s a fairly brutal demo because it strips away the jargon. No packet capture tool’s needed to grasp the result. The browser says one thing. The network says another.
The broader annoyance here is that the leak happens at the moment users feel safest. People reach for passkeys because they’re meant to be simpler and less exposed than passwords. No shared secret to phish. No text message code to intercept. Just the device and the site, with the operating system doing the heavy lifting. The sign-in flow starts behaving like a privacy exception hidden inside a privacy feature, when that same convenience routes traffic around Apple Private Relay. That isn’t exactly the user experience Apple markets.
There’s also a practical wrinkle: any site that supports passkeys can trip the issue, so the problem is not tied to one app, one company, or one obscure corner of the web. A shopping site, a bank, a social platform, a workplace portal, all of them could become the place where the device speaks up with the real IP address while the user’s focused on Face ID and the little spinning indicator. For anyone who turned on iCloud Private Relay expecting Safari to keep the web at arm’s length, that’s a pretty direct real IP address leak.
And because the request’s generated by the phone itself, not by a visible page load in the browser, the failure’s easy to miss. There’s no obvious “relay off” state. No settings screen pops up to confess the detour. The page keeps loading, and the login succeeds. When it comes to the leak, it has already happened.
That, more than the technical jargon, is the awkward bit. The tool is working in the place you can see, then failing in the place you can’t. Next up is the part that makes this even less tidy: once the browser engine gets involved, the blast radius doesn’t stop at Safari.
Why the blast radius is bigger than one app
Because iOS makes every browser use Apple’s WebKit engine, this problem doesn’t stay neatly inside Safari. Chrome on iPhone, Firefox on iPhone, Edge on iPhone and the rest of the crowd all have their own icons and branding, but they still lean on the same rendering engine under the hood. That matters here. If the leak lives in WebKit or in iOS’s own networking and credential handling, changing browser apps doesn’t really change the plumbing.
Apple’s own materials describe iCloud Private Relay as a feature meant to hide your IP address and keep sites from tying your browsing session back to your network location. The company also gives developers guidance on how to prepare services for Private Relay traffic, which is Apple’s polite way of saying that websites and network operators should expect traffic to arrive in a slightly different shape than usual. That promise gets wobbly fast if a browser or device-side component leaks the same identifier the feature was built to obscure.
On iPhone, a different browser app does not automatically mean a different browser engine, and that’s how one privacy bug can spread farther than its label suggests.
The researchers testing this issue found that the problem isn’t limited to Safari in the ordinary sense. At least one Tor-based iPhone browser, OnionBrowser, also showed signs of exposure. That isn’t a small detail for anyone trying to use Tor on iPhone with a straight face. If a user goes out of their way to open a privacy-focused browser and still ends up handing out a real IP address in some situations, the app store category label starts to look a bit optimistic.
The interesting part is the nuance from OnionBrowser’s creator. Two of the issues, he said, come from iOS and WebKit itself. That tracks with the broader architecture problem. The app can only do so much when the operating system insists on steering traffic through Apple-controlled components. A third issue, though, does not affect OnionBrowser in its default setup. In other words, the browser has some room to avoid one leak path, but not the ones embedded deeper in iOS. That distinction matters, because it shows this isn’t one clean, fixable app bug. It’s a mixed bag of platform behavior, browser behavior, and configuration details.
The official Tor Browser from the Tor Project isn’t affected, and it remains the recommended Tor option. That recommendation’s doing a lot of work here. For iPhone users who want Tor-like protection, it is the version that avoids this particular mess rather than merely dressing up the same underlying engine in a darker theme. In a world where passkeys privacy and relay-based IP masking are already tricky enough to explain, that difference isn’t academic. It decides whether the user’s actually getting the protection they think they bought.
There’s also a less dramatic, but maybe more realistic, wrinkle. A website doesn’t have to be run by a malicious operator to end up with a user’s IP address. Plenty of sites collect it for routine reasons, from rate limiting to fraud checks to analytics that nobody in the room can quite stop talking about. Interesting. If a request leaks the real address during a login flow or credential check, that information may already be sitting in logs before anyone has a chance to call it a security incident. No attacker needs to be clever if ordinary infrastructure is already recording the data.
That’s what makes this iOS WebKit bug awkward for Apple. The company’s browser rules turn a flaw that sounds app-specific into something closer to a platform problem. And it works. One browser app is exposed, and then another. Then, if the same code path runs through iOS itself, the list gets longer without anyone installing anything new.
Even the wording around the feature starts to feel brittle. Private Relay’s marketed as a shield for your network identity, but on iPhone the shield depends on a stack that stretches from Safari to WebKit to iOS services that sit outside the browser window (and yes, that matters). If one layer leaks, the user doesn’t necessarily notice. The page still loads. And the login still works. The only thing that changes is the address the other side can see.
And that’s the part that ought to make Apple nervous. A privacy tool can survive a lot of inconvenience. It cannot survive being porous in the places users are least likely to inspect.
Apple’s privacy reputation is on the line
This latest leak lands awkwardly for a company that has spent years selling the idea that privacy can be packaged, preloaded and paid for monthly. Apple already had one bruise this year from a separate slip in Hide My Email, where real addresses were left visible for far longer than users would expect before the issue was fixed. That was the sort of bug that makes people squint at the fine print on Apple’s privacy features. Now Private Relay’s doing the same trick, except the mistake hits at the network level, where users assumed the walls were thicker.
A privacy feature that works only when nothing unusual happens is a pretty fragile promise.
Apple says it’s investigating the new report, which is the only sensible answer at this stage. Still, the broad shape of the problem is already clear enough to sting. Some of the leaks don’t appear to come from a single rogue app or a sloppy website. They seem to grow out of how iOS and WebKit are built, which means the fix sits with Apple itself rather than with third-party developers who merely happen to be in the blast radius. That matters because the company has sold Private Relay, passkeys and other bundled protections as part of a clean, integrated system. If the system leaks in a predictable way, the marketing starts to look a bit too tidy.
That’s where the reputational damage kicks in. Apple privacy products are only as persuasive as their worst failure in the real world. A feature can sound airtight in a keynote and still fall apart when a browser engine, a credential flow, or an app’s default behavior pulls traffic outside the path Apple intended. Users rarely think in those terms. They see a switch that says their IP address’s hidden, or an iCloud+ feature that promises a little more cover, and they take the hint. Fair enough. The whole point of buying the bundle isn’t to become a part-time network engineer just to see whether Safari’s behaving.
The recent Hide My Email problem made that point in a different register. There, the issue was that real addresses could surface when people expected a relay address to do the shielding. With Private Relay, the promise’s even simpler: hide the user’s network identity while they browse. If that can be bypassed by normal iPhone behavior, the trust gap gets wider fast. Users don’t need a full technical memo to feel the shift. They just need one login page, one passkey prompt, or one Tor browser session on an iPhone that doesn’t behave the way the privacy badge suggested it would.
There’s also a broader annoyance here. The leak isn’t some edge-case novelty that only affects hobbyists poking at obscure settings. It reaches into features Apple’s made easy to use on purpose. That convenience’s part of the pitch, but it also means the failure’s visible to ordinary people, not just security researchers. And once a privacy trait becomes easy enough for regular users to adopt, it also becomes easy enough for them to lose confidence in.
For now, the practical advice’s plain: treat Private Relay as useful, not magical; treat passkeys as convenient, not a privacy guarantee; and if you’re using Tor on an iPhone, remember that Apple’s browser rules still shape a lot of what happens under the hood. Anyone depending on these Apple privacy products has a fresh reason to keep expectations modest until Apple spells out what it can actually fix, and when.
