Na semana passada, pesquisadores revelaram falhas de segurança nas configurações de proxy da Retransmissão Privada (Private Relay) do iCloud+, que também afetam navegadores baseados no WebKit que utilizam a API ¹Application programming interface, ou interface de programação de aplicações. de proxy para privacidade, expondo o endereço IP dos assinantes do serviço. Pois bem, não demorou muito para que surgisse o primeiro processo relacionado ao caso.

A ação coletiva foi movida pelo escritório jurídico Clarkson, que você talvez lembre pelo envolvimento no processo sobre o adiamento dos recursos de inteligência artificial (IA) apresentados durante a WWDC24, o que resultou em um acordo o qual previu o pagamento de US$250 milhões a clientes em dezembro do ano passado.

Como sambemos, a Retransmissão Privada oferece proteção para ocultar o seu endereço IP e dificultar a ciência sobre os seus acessos na web por parte de provedores de internet e terceiros, direcionando o seu tráfego para duas camadas de proteção.

O novo caso menciona o problema na Retransmissão Privada que faz a sua barreira ser burlada nos iOS em qualquer site compatível com as Chaves-senha (Passkeys) — algo que acontece pois o dispositivo do usuário faz uma requisição web fora do próprio navegador sempre que o usuário faz login, ignorando o Private Relay — e acusa a Apple de publicidade enganosa, declarações falsas ou deturpadas e fraude.

[A Apple] sabia, ou deveria saber, que as declarações contestadas eram falsas, enganosas, fraudulentas e ilegais, no momento em que a ré fabricou, comercializou, anunciou, rotulou e vendeu as assinaturas [do iCloud+].

Convidada a comentar o caso pelo 9to5Mac, a Apple ainda não se pronunciou sobre o tema. Tim Giordano, um dos sócios do escritório, por outro lado, disse que a empresa traiu a confiança de usuários “expondo-os ao mesmo rastreamento, criação de perfis e segmentação sobre os quais a Apple os alertava”.

O texto completo da ação coletiva pode ser conferido nesse link [PDF].

Notas de rodapé

• 1
  Application programming interface, ou interface de programação de aplicações.

Talal Haj Bakry and Tommy Mysk (Mastodon, Hacker News, MacRumors, Mac Power Users):

WebKit-based browsers on iOS and macOS can be configured to route all web traffic through proxy servers, which is how Tor browsers on iOS and our own Psylo work. We found three WebKit features — DNS prefetching, WebAuthn Related Origin Requests, and WebTransport — that bypass the configured proxy and send traffic directly from the device, which exposes the user’s real network. The same leaks also affect 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 addressed all three leaks in Psylo 1.3.1[…] 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:

In an ideal world, we’d report the issues to Apple, they acknowledge the issue, and ship a fix in a timely manner. Unfortunately, our past experience with Apple tells us that reporting this issue would involve months of delays, inconsistent communication, and in some cases, denying the issue’s impact entirely.

We weren’t willing to wait months, or upwards of a year, sitting on bugs that undermine the core privacy guarantees of Psylo and iOS Tor browsers while saying or doing nothing.

[…]

Should we knowingly leave our users exposed while waiting for a system-level fix? We didn’t think that was acceptable or fair to our users. Or should we quietly ship our own mitigations without telling anyone? We didn’t think that was acceptable either. Security fixes deserve transparency, especially when they involve tradeoffs.

Psylo:

Soon after we published the blog, we sent a link to the blog and demo website to Apple in a security report to make them aware of it. Now the report is already in the status “We’re planning to address the issue you reported.” and a fix is planned for Fall 2026 🤯🤯🤯

Mysk:

It used to take months and months to reach this status. We got there in less than 24h

Running to the press always helps…

Previously:

• Hide My Email Vulnerability Exposes Real Address
• No Bounty for Mysk
• Psylo Web Browser 1.0
• iCloud Private Relay White Paper

Update (2026-08-11): Ben Lovejoy (MacRumors):

A class action lawsuit accusing Apple of false advertising, misrepresentation, and fraud has now been filed by Clarkson Law Firm – the same lawyers who previously obtained a $250M settlement over the delayed launch of Siri AI.

Apple’s iCloud Private Relay is designed to hide users’ IP addresses from websites and even from Apple itself while browsing in Safari. But according to security researchers Talal Haj Bakry and Tommy Mysk, the feature does not always work as intended because of issues in Apple’s WebKit browser engine.

The problem centers on passkeys, the password-free authentication method that is becoming more widely used. When a user authenticates with a passkey, the request is handled outside the browser itself. Private Relay only protects traffic within Safari (as an iCloud+ feature) and does not function like a full-device VPN. As a result, the authentication request can expose the user’s real IP address to the website or service.

Because the vulnerability sits in WebKit, the engine that powers every browser on iOS, the IP leak is not limited to Safari. Privacy-focused browsers such as OnionBrowser and the researchers’ own Psylo browser can also reveal a user’s IP when passkeys are used.

Re: Responsible Disclosure

We found ourselves in a bit of a dilemma with these DNS and IP leaks in WebKit and how to handle them responsibly.

We first became aware of a DNS leak in Psylo in late June 2026 after a user reported it. During our investigation, we found two… https://t.co/5kFu0jtUsJ

— Mysk (@mysk_co) August 5, 2026

The researchers have already notified OnionBrowser and the Tor Project of their findings and suggested fixes. Apple has told 404 Media that it is investigating the report. However, Bakry and Mysk noted that Apple’s response times for similar privacy issues can be lengthy; a previously reported problem with the Hide My Email feature that allowed real email addresses to leak behind aliases was not fully fixed for about a year after it was disclosed.

MacDailyNews Take: Until a fix arrives, users who rely on Private Relay for anonymity should be aware that logging in with passkeys on iOS may still reveal their IP address.

‎
Please help support MacDailyNews — and enjoy subscriber-only articles, comments, chat, and more — by subscribing to our Substack: macdailynews.substack.com. Thank you!

Support MacDailyNews at no extra cost to you by using this link to shop at Amazon.

The post Apple’s iCloud Private Relay can leak your real IP address through passkey logins, researchers warn appeared first on MacDailyNews.

A newly discovered WebKit privacy leak bypasses proxy protection and iCloud Private Relay, exposing your real IP addresses and DNS data.

(via Cult of Mac - Your source for the latest Apple news, rumors, analysis, reviews, how-tos and deals.)

John Gruber (Mastodon):

In most Mac apps, since the dawn of time, if there is nothing selected to be copied, the Edit → Copy (and Cut) commands are disabled. If you invoke the ⌘C shortcut while the Copy command is disabled, you hear an alert sound, letting you know that whatever you thought you were copying could not be copied because it wasn’t selected. That beep is useful context. This is proper behavior for all menu items — if they’re not available to do something, they should be disabled, and invoking a disabled menu item keyboard shortcut should beep. In any app that uses WebKit, since early in 2025, the Copy command is always enabled when a WebKit view has focus — but if nothing is selected, you get useless clipboard data that can’t actually be pasted anywhere. (And whatever was on your clipboard is now gone, or pushed back if you use a clipboard history utility.)

Jeff Johnson:

I decided to file a bug report on behalf of Gruber: Copy main menu item is enabled with no selection in the web page. I subsequently learned that the first appearance of the bug was January 2025 in the WebKit source code, February 2025 in Safari Technology Preview 213, and March 2025 in Safari 18.4, as a result of attempting to fix another bug, document.execCommand("copy") only triggers if there is a selection, reported in 2016, nine years prior!

[…]

Sadly, my bug report was closed with the resolution “won’t fix.” The refusal appears to be based on a misunderstanding[…]

Jeff Johnson:

LOL that was fast.

Sometimes Apple is hilarious.

Previously:

• Web Pages Can Overwrite Your Clipboard

Update (2026-07-30): Saron Yitbarek (via Jeff Johnson):

Fixed the Edit menu’s Copy item being incorrectly enabled when there was no selection in the web page.

Tim Hardwick:

Apple’s new version of Safari browser in macOS 27 and iOS 27 can be tasked to monitor a webpage and notify you of any changes, thanks to a new built-in feature.

[…]

In other upcoming feature additions, using the power of AI, Safari tabs that you have open can automatically be organized into topics.

Saron Yitbarek et al.:

Don’t miss our WWDC26 sessions on web technology, including What’s new in WebKit for Safari 27, to go deeper on our work in this release. Now, let’s dig into this beta, packed with 58 new features, 525 fixes and 4 deprecations that will hopefully make your work as a web developer a little easier.

Saron Yitbarek:

This year, the WebKit team is here with six sessions covering new CSS layouts, customizable form controls, 3D models, immersive spatial experiences, and browser extensions.

See also: Safari 27 Beta Release Notes.

Previously:

• WWDC 2026 Keynote
• iOS 26.2: App Marketplaces and Search Engine Choice in Japan
• How Safari Search Engine Extensions Work

Update (2026-06-17): Jeremy Keith:

But credit where credit is due. The upcoming version 27 of Safari is looking very good.

That’s not because it’s at the cutting edge of the latest web standards. Quite the opposite. Most of the changes listed for this release are bug fixes. That’s what I want to acknowledge and applaud.

Previously:

• Glow Leopard

Saron Yitbarek, writing on the WebKit blog:

In Safari Technology Preview 247, we’re introducing the Safari MCP server — a Model Context Protocol server for web developers that makes your web development and debugging workflow faster and more powerful. We know agents are increasingly integral to the coding process and the Safari MCP server gives your agent the ability to know how your code actually renders in the browser by connecting it to a Safari browser window.

Any MCP-compatible client can connect to the Safari MCP server. By connecting your agent to a Safari browser window, your agent can emulate what your users experience, giving it the information it needs to debug more autonomously, like access to the DOM, network requests, screenshots, and console output.

Importantly:

The Safari MCP server runs entirely on your local machine and makes no network calls of its own. It also does not have access to your personal information in Safari (e.g. AutoFill or other browser activity). When it captures page content, screenshots, or console logs, that data goes directly to the agent you’re running — not to Apple. What happens to that data from there depends on the agent and model you’re using. As with any agent you give access to your browser, only use ones you trust.

For the past few months, I’ve been using Google Chrome on my MacBook Pro and Mac Studio not because I like the browser (in fact, I really dislike Chrome’s text rendering and UI), but simply because it was the best option for agents. In Codex specifically, between Playwright, Chrome Dev Tools, and OpenAI’s own Chrome extension, I could kick off research tasks (such as vacation planning and booking a hotel) that involved a browser directly from my iPhone, letting Codex drive the research on my remote Mac.

Safari in Codex.

Now, thanks to Safari’s new MCP server, I no longer have to use Chrome on desktop and can return to a unified browser setup across all my devices. Even better: it actually looks like Apple shipped the most ergonomic browser MCP for agents to date. The MCP server has dedicated tools for page extraction (including getting webpages as Markdown, based on WebKit’s own conversion pipeline), evaluating JavaScript, DOM interactions (clicking, scrolling, resizing the viewport for mobile screens, etc.), taking screenshots, and more. I set this up immediately in Codex, and I also asked Codex about comparing Safari’s MCP to its own Chrome extension and the older Playwright. The verdict: although Chrome has a richer API with Chrome Dev Tools when it comes to network requests, Codex actually preferred Apple’s leaner, more direct approach for letting an agent drive and debug a browser.

I’m really happy to see folks at Apple embrace agentic tools: between the new MCP capabilities of Xcode and now this, it looks like Apple’s software (on the Mac, of course) is becoming more and more approachable by people who are working in new ways thanks to agents. Whether you’re a web developer or tinkerer, I highly recommend checking out what Apple has released in Safari Technology Preview. More of this, please.