Five of my sites are flagged by Safari's Deceptive Website Warning. They are legitimate and none of them collect credentials, imitate another brand or contain social engineering content: store-api.ru — paid access to third-party AI APIs (clearly states it is not affiliated with OpenAI, Anthropic or Google) cenwise.ru — price comparison service kirillportfolio.ru — personal developer portfolio (no login, no forms, no data collection at all) 3021.ru — habit tracking app animegenai.ru — AI image generation service All five are clean in Google Safe Browsing, Google Transparency Report, Google Search Console and Yandex Webmaster. Safari is the only place showing a warning. The flag appears to be inherited from a previous hosting provider whose IP ranges had reputation problems, and it seems attached to the domain names rather than to the current infrastructure. This is directly testable: On 20 July 2026 all sites were migrated to a new host — a single server, single IP (152.53.119.191). On that exact same server and IP, the domains created AFTER the migration are NOT flagged: filelama.com (live since 28 July, fully indexed), novelisstory.ru (25 July) and store-api.com (4 August). Only the domains that already existed under the previous host are still flagged. Same server, same IP, same certificates, same kind of content. The only variable is whether the domain existed before 20 July. store-api.ru and store-api.com are the clearest case: both are literally the same application behind the same nginx on the same IP, differing only in the domain name. The .ru is flagged, the .com is not. I submitted requests through websitereview.apple.com on 20 July and again on 11 August 2026. Neither produced a response or an acknowledgement, which as I understand is expected behaviour for that form. My questions: Is websitereview.apple.com still the correct — and only — channel for a site owner to dispute a false positive? Is there any way to confirm that a submission was received, or a typical review timeframe I should expect? Would a Feedback Assistant report under Safari add anything here, or would it simply duplicate the request?

Observed versions: Reproduced on Tahoe / Safari 26 and iOS 26 Safari. Not reproduced on v18 Safari. Not reproduced in Chrome with the same reduced test setup. We are seeing a Safari-only rendering issue affecting an ad creative inside an iframe on both desktop Safari and iOS Safari. What we observe: The issue is reproducible in Safari on OS X and iOS v26. We do not reproduce it in Chrome with the same test setup. We can reproduce it in a minimal test case, outside our site app code. The issue appears tied to the rendered iframe document/layout, not our outer page layout. The problematic rendered structure inside the iframe looks like this: <div class="GoogleActiveViewElement" style="display:inline"> <ins class="dcmads" style="display:inline-block;width:320px;height:50px"> <script src="https://www.googletagservices.com/dcm/dcmads.js"></script> </ins> </div> Here is a simplified, local-reproducible version for testing: <div class="GoogleActiveViewInnerContainer" style="left:0px; top:0px; width:100%; height:100%; position:fixed; pointer-events:none; z-index:-9999;"></div> <div class="GoogleActiveViewElement" style="display:inline"> <ins class="dcmads" style="display:inline-block;width:320px;height:50px"> <script> document.write( '<a target="_blank" href="#"><img ' + 'src="data:image/svg+xml;utf8,' + encodeURIComponent( '<svg xmlns="http://www.w3.org/2000/svg" width="320" height="50">' + '<rect width="320" height="50" fill="#ffd8d8"/>' + '<text x="160" y="30" text-anchor="middle" font-family="Arial" font-size="14" fill="#222">' + 'img placeholder' + '</text>' + '</svg>' ) + '" ' + ' alt="Advertisement" border="0" width="320" height="50" style="display:block" /></a>' ); </script> </ins> </div> In Safari, this produces extra vertical spacing / cutoff above the ad. In the test code you will only notice an added top spacing, but when rendered in a live ad, the bottom gets cut off. A few details that may help: If we manually change the inner ins.dcmads from display:inline-block to display:inline, or adding overflow:hidden, the spacing issue goes away. If the loader script is moved outside the ins during manual experimentation, the issue also goes away. This makes it look like a Safari layout/rendering issue involving an inline wrapper around an inline-block ad container during script-driven rendering. Questions: Is this a known Safari/WebKit layout issue involving inline + inline-block content in iframe documents? Has there been any recent Safari/WebKit change that could affect this rendering path? Is there a preferred reduced repro format for reporting layout issues like this?

Hello, I'm trying to use a certificate provisioned through the com.apple.security.acme payload for TLS client authentication in Safari on macOS. Provisioning the certificate via ACME using the device-attest-01 challenge is working fine and the signed certificate includes the Extended Key Usage: TLS Web Client Authentication. Unfortunately on macOS in Safari I can't find a way to choose this identity when a server requests client authentication. Using the same method works flawlessly on iOS. If a server requests client authentication Safari prompts the option to use the certificate and the connection to the web server succeeds as intended. On macOS I have tried adding a com.apple.security.identitypreference payload to the profile, linking the certificate from the ACME payload to the domain name of a web server that requires client authentication, but that did not change the behavior in any way. The following payload is used to request the certificate on both my MacBook and iPhone: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>PayloadDisplayName</key> <string>ACME Certificate Request</string> <key>PayloadIdentifier</key> <string>com.example.net.acmeprofile</string> <key>PayloadType</key> <string>Configuration</string> <key>PayloadUUID</key> <string>UUID-1111-1111-1111-111111111111</string> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadContent</key> <array> <dict> <key>PayloadType</key> <string>com.apple.security.acme</string> <key>PayloadIdentifier</key> <string>com.example.net.acme</string> <key>PayloadUUID</key> <string>UUID-2222-2222-2222-222222222222</string> <key>PayloadVersion</key> <integer>1</integer> <key>DirectoryURL</key> <string>https://acme.example.net/acme/apple-acme/directory</string> <key>ClientIdentifier</key> <string>XXXXXXXXX</string> <key>KeyType</key> <string>ECSECPrimeRandom</string> <key>KeySize</key> <integer>256</integer> <key>UsageFlags</key> <integer>1</integer> <key>ExtendedKeyUsage</key> <array> <string>1.3.6.1.5.5.7.3.2</string> </array> <key>HardwareBound</key> <true/> <key>Attest</key> <true/> <key>AllowAllAppsAccess</key> <true/> <key>Subject</key> <array> <array> <array> <string>CN</string> <string>XXXXXXXXX</string> </array> </array> </array> </dict> </array> </dict> </plist> And this is the identity payload I have added to the profile on macOS: <key>PayloadType</key> <string>com.apple.security.identitypreference</string> <key>PayloadIdentifier</key> <string>com.example.net.identitypreference</string> <key>PayloadUUID</key> <string>UUID-3333-3333-3333-3333333333333333</string> <key>PayloadVersion</key> <integer>1</integer> <key>Name</key> <string>mtls-endpoint.example.net</string> <key>PayloadCertificateUUID</key> <string>UUID-2222-2222-2222-222222222222</string> Neither device is managed by an MDM service and they run macOS 26.6.1 and iOS 26.6 respectively. Is there any additional configuration required on macOS to make an ACME-provisioned certificate available for client authentication in Safari? Or is this simply the expected behavior, and client authentication requires a traditional certificate-key pair in the macOS Keychain? Any help would be greatly appreciated!

I am implementing push notifications for a web application running as a PWA on iPad using Web Push. When sending a push notification to the web application, I received a 410 response from the server. I would like to understand the cause and reason for receiving this 410 response. The library used for sending push notifications is a commonly used JavaScript Web Push library. Could you please explain under what circumstances Apple Web Push endpoints return a 410 response, and whether this indicates that the existing push subscription is no longer valid and should be re‑registered.

Has anyone else observed intermittent first-navigation failures in Safari on iOS 26 when HTTP/3 0-RTT resumption is available? Environment: iPhone 16 Pro, iOS 26.5.2 (23F84), Mobile Safari Wi-Fi with native IPv6 Cloudflare-proxied HTTPS hostname Normal browsing, not Private Browsing Reproduced almost daily on the first visit; an immediate reload succeeds Safari shows its native “cannot open the page because the server cannot be reached” page. The origin is healthy and neither the origin nor Cloudflare HTTP/security analytics records a corresponding HTTP failure. We captured the iPhone network interface over USB and compared a failed navigation with the successful reload. Failed navigation: DNS A, AAAA and HTTPS/SVCB answers completed normally. The HTTPS record advertised h3 and h2 with IPv4 and IPv6 hints. MobileSafari/WebKit opened several QUIC connections across the available IPv4 and IPv6 endpoints. Nearly all sent QUIC Initial packets plus 0-RTT application data. The edge replied promptly with Initial, Handshake and protected packets on both address families. Several flows did not settle and the edge retransmitted repeatedly. Safari also established a TCP/TLS fallback and received data, but still declared the navigation failed. Successful reload: One IPv4 QUIC connection. Full handshake, without 0-RTT. Normal bidirectional protected traffic and the page loaded. Control tests: Another proxied hostname succeeded with a full HTTP/3 handshake and no 0-RTT. A direct, non-proxied hostname succeeded over IPv6/TLS. HTTP/3 requests from the same Safari version otherwise received normal 200/204/302/304 responses. This looks like a CFNetwork/Network.framework/libquic session-resumption or connection-racing recovery issue rather than a WebKit rendering or origin-server problem. The encrypted capture does not let us determine whether the early data was accepted or rejected by the edge. Feedback filed: FB23764937. Important reproduction note: 0-RTT has now been disabled on the affected production zone while HTTP/3 remains enabled. Therefore that hostname can no longer reproduce the original 0-RTT path. This is an intentional mitigation; it will not be re-enabled on production solely for testing. Questions: Has anyone seen the same first-load failure followed by a successful reload on iOS 26? Is there a recommended way to collect CFNetwork/libquic diagnostics for a failure that occurs before an HTTP response exists? Should Safari replay the navigation after 0-RTT rejection or use the already-successful TCP/TLS fallback in this situation? A raw packet capture is available to Apple through the private Feedback report on request, but is not posted publicly because it contains client network identifiers.Has anyone else observed intermittent first-navigation failures in Safari on iOS 26 when HTTP/3 0-RTT resumption is available? Environment: iPhone 16 Pro, iOS 26.5.2 (23F84), Mobile Safari Wi-Fi with native IPv6 Cloudflare-proxied HTTPS hostname Normal browsing, not Private Browsing Reproduced almost daily on the first visit; an immediate reload succeeds Safari shows its native “cannot open the page because the server cannot be reached” page. The origin is healthy and neither the origin nor Cloudflare HTTP/security analytics records a corresponding HTTP failure. We captured the iPhone network interface over USB and compared a failed navigation with the successful reload. Failed navigation: DNS A, AAAA and HTTPS/SVCB answers completed normally. The HTTPS record advertised h3 and h2 with IPv4 and IPv6 hints. MobileSafari/WebKit opened several QUIC connections across the available IPv4 and IPv6 endpoints. Nearly all sent QUIC Initial packets plus 0-RTT application data. The edge replied promptly with Initial, Handshake and protected packets on both address families. Several flows did not settle and the edge retransmitted repeatedly. Safari also established a TCP/TLS fallback and received data, but still declared the navigation failed. Successful reload: One IPv4 QUIC connection. Full handshake, without 0-RTT. Normal bidirectional protected traffic and the page loaded. Control tests: Another proxied hostname succeeded with a full HTTP/3 handshake and no 0-RTT. A direct, non-proxied hostname succeeded over IPv6/TLS. HTTP/3 requests from the same Safari version otherwise received normal 200/204/302/304 responses. This looks like a CFNetwork/Network.framework/libquic session-resumption or connection-racing recovery issue rather than a WebKit rendering or origin-server problem. The encrypted capture does not let us determine whether the early data was accepted or rejected by the edge. Feedback filed: FB23764937. Important reproduction note: 0-RTT has now been disabled on the affected production zone while HTTP/3 remains enabled. Therefore that hostname can no longer reproduce the original 0-RTT path. This is an intentional mitigation; it will not be re-enabled on production solely for testing. Questions: Has anyone seen the same first-load failure followed by a successful reload on iOS 26? Is there a recommended way to collect CFNetwork/libquic diagnostics for a failure that occurs before an HTTP response exists? Should Safari replay the navigation after 0-RTT rejection or use the already-successful TCP/TLS fallback in this situation? A raw packet capture is available to Apple through the private Feedback report on request, but is not posted publicly because it contains client network identifiers.

My domain vendezo.com is completely clean on Google Safe Browsing and VirusTotal, but Safari still shows a Deceptive Website Warning. Request through websitereview.apple.com was ignored. Please help