I'v been using a shortcut from the iOS/ipadOS share sheet in safari for several months now successfully and tried to use/port it to macOS: The "Run Javascript on Active Safari Tab" (RJOACST) action fails on MacOS if logic based on native shortcut actions is executed before / in front of it. The same shortcut does work on iOS and iPadOS. Here's the shortcut: https://www.icloud.com/shortcuts/613fe9b4464c401380159eb8160eb485 The Error on macOS reads: ''' DEV Safari Recipee 2 JS Reminders N... Unable to Run JavaScript on Web Page Make sure Allow JavaScript from Apple Events is enabled in the Develop menu in Safari. The Develop menu can be enabled in the Advanced section of Safari's Preferences. ''' BUT: simpler shortcuts with just the RJOASF Javascscript (e.g. the default script) DO work on the same machine. All settings are correct. When refactoring the initial logic from shortcuts action into Javascript code and calling the RJOACST silently lets the shortcut die. Any lead/hint appreciated. I did try to retrieve the shortcuts input shortly before the RJOACST is executed. PS: The file Recipes.json contains a list of sites to scrape recipe ingredients from - find the example here: ''' { "deli-berlin.com": { "selectorType": "xpath", "selectorExpression": "//div[contains(@class,'wprm-recipe-ingredient-group')]/ul/li", "extractionType": "text", "joinArrayString": "\n", "cleanupRules": [], "sampleUrl": "https://deli-berlin.com/rezept-vegane-lasagne/", "cachedHtml": "", "baselineIngredientsText": "", "activeVariationId": "row", "variations": [], "snapshotNote": "", "lastTestStatus": "untested", "lastTestedDate": "", "lastTestError": "", "htmlUpdatedAt": "", "baselineUpdatedAt": "", "ruleConfigUpdatedAt": "", "history": [] }, "www.allrecipes.com": { "selectorType": "xpath", "selectorExpression": "//ul[contains(@class,'mntl-structured-ingredients__list')]/li", "extractionType": "text", "joinArrayString": "\n", "cleanupRules": [ { "find": "\n{2,}", "replace": "\n", "active": true, "phase": "beforeJoin" } ], "sampleUrl": "https://www.allrecipes.com/recipe/221361/traditional-sauerbraten/", "cachedHtml": "", "baselineIngredientsText": "", "activeVariationId": "row", "variations": [], "snapshotNote": "", "lastTestStatus": "untested", "lastTestedDate": "", "lastTestError": "", "htmlUpdatedAt": "", "baselineUpdatedAt": "", "ruleConfigUpdatedAt": "", "history": [] } } '''

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

Device: iPhone 15, iOS 26.6, Safari. Also reproduced on Android Chrome, so this is not only WebKit, but the missing rotation flag part is. Setup: a web page asks for the front camera with getUserMedia, shows it in a video element, and records with MediaRecorder. Phone held upright. What happens: Requesting portrait dimensions (width 1080, height 1920) returns the sensor's wide preset, 1920 by 1080, unrotated. exact instead of ideal gives the same or an error. aspectRatio 9/16 gives the same. Requesting landscape numbers (width 1920, height 1080) lets Safari pick the preset and rotate the picture to match how the phone is held. Even then, the video track's getSettings() reports width 1920 and height 1080, while the frame Safari draws into the video element is portrait. The preview looks right. The track lies. MediaRecorder records the unrotated sensor buffer. On older iOS the file carried a displaymatrix rotation of minus 90 degrees and players honoured it. On 26.6 that flag is gone, so the file plays sideways. Thread 786803 has other people finding the same. Workaround that works in production: Ask for the camera in landscape numbers. Do not trust getSettings(). Draw one frame of the video element onto a 16 by 16 canvas scaled from the larger reported dimension and check which corner has paint. If the bottom left is painted and the top right is not, the picture is tall. If the drawn picture is portrait but the track says landscape, record a canvas stream of the drawn picture at its own size instead of the raw track. If they agree, record the raw track. Put the H.264 High profile first in your mime type candidates. isTypeSupported says yes to Baseline and High, and list order decides, so Baseline first gives soft video. Working code, MIT, with the dead ends left in as comments: https://github.com/lagudafuadtosin/web-teleprompter (src/lib/camera.ts) Full write-up: https://dev.to/lagudafuad/why-your-web-teleprompter-records-sideways-on-iphone-and-the-fix-549m Question for Apple: is the dropped displaymatrix on MediaRecorder output in 26.x intentional, and is there a supported way to read the capture rotation off the track?

We’re suddenly seeing valid Apple Wallet .pkpass files blocked inside Instagram and Messenger, with a “connection is not secure” warning. The exact same file works perfectly in Safari and outside Meta apps. We’ve reproduced it with a known-valid .pkpass hosted independently, so this doesn’t appear to be related to the pass file or hosting infrastructure. Has anyone else seen this since the latest Instagram / Messenger updates? Instagram/Messenger in-app browser → blocked Safari → works Interested to hear from anyone working with Apple Wallet / .pkpass / WKWebView.

So using the developer website in Safari....produces this. How? How is this even possible? I know.... they used Chrome to test and develop with... ;) I am on the latest Safari. Sad.

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!

Hi, I'm currently experiencing issues with HLS streams created by FFmpeg running on Safari. When I pass the stream to the mediastreamvalidator tool and then run hlsreport on the output, I get a critical error reported: Media Entry discontinuity value does not match previous playlist for MEDIA-SEQUENCE 1 If I let the stream finish (it's a live stream from an IoT device) and then perform the stream validation again I no longer receive the critical error. My assumption is that this critical error is contributing to the HLS stall on iOS. I have also noticed that if I let the stream continue and then re-load the video control in Safari the stream starts Is there a resource with explanations or remediation paths relevant to the possible output of the hlsreport? My m3u8 output looks like this (I have redacted the server host) #EXTM3U #EXT-X-VERSION:6 #EXT-X-TARGETDURATION:2 #EXT-X-MEDIA-SEQUENCE:1 #EXT-X-PLAYLIST-TYPE:EVENT #EXT-X-INDEPENDENT-SEGMENTS #EXT-X-DISCONTINUITY #EXTINF:2.000000, https://redacted.com/segment-00001.ts #EXTINF:2.000011, https://redacted.com/segment-00002.ts #EXTINF:2.000011, https://redacted.com/segment-00003.ts #EXTINF:2.000011, https://redacted.com/segment-00004.ts #EXTINF:2.000011, #EXT-X-ENDLIST Thanks for any advice or guidance possible - if I can provide isolated code snippets I will do. Andy

Two unrelated, legitimate websites I own are both shown as "Deceptive Website — Apple has identified this website as fraudulent" in Safari (iOS + macOS), and even inside my installed PWA on iOS. This is a false positive and I can't find a working way to get Apple to remove it. Why I'm confident it's a false positive: Google Safe Browsing site status: clean Google Search Console (verified owner) > Security Issues: none Yandex Webmaster > Security: no violations VirusTotal: 0/92 detections Chrome, Firefox, Yandex Browser: NO warning on any platform Only Safari shows it, wording is "Apple has identified..." — i.e. Apple's own list, not the Google Safe Browsing feed The sites are genuinely benign: no brand impersonation, no third-party credential harvesting, no malware, no drive-by downloads. The interesting part — it's TWO unrelated sites: Site A: a small web app (SaaS with a login form) Site B: my personal developer portfolio — static, no login at all They share almost nothing: different codebase, different design, different hosting (Site A is behind Cloudflare with a Google Trust Services edge cert; Site B is a plain nginx box with a Let's Encrypt cert), different TLS issuers, different stacks. The ONLY common denominator is me as the owner/registrant (same person, same contact email, same registrar account). This makes me think the domains were clustered by registrant/owner rather than by anything on the sites themselves. The two-sites fact also rules out the usual scapegoats: it isn't Cloudflare (Site B isn't even on Cloudflare and is flagged too), nor the cert issuer, host, or stack, since those differ. What I've already done: Clicked "Report an error" on the Safari warning page Submitted the Google Safe Browsing incorrect-warning report Filed a tracked report in Feedback Assistant (FB number, status Open) Hardened both sites anyway: CSP + security headers, SPF/DKIM/DMARC, and real trust pages (About with owner identity + contact, Privacy Policy, Terms, linked from homepage and login page) It's been about a week with no response. My questions: When Google Safe Browsing is clean but Safari still flags, what feeds Apple's OWN fraudulent-site list? Is registrant/owner clustering a real mechanism here? Which removal channel actually works in practice? Realistic timeline for a false-positive removal? If one domain is cleared, does that clear the owner-level association for the other, or do I appeal each separately? Is there anything that re-triggers it? (Considering a domain migration as a last resort and want to avoid a new domain getting re-flagged.) Any first-hand experience is appreciated — the process is completely opaque.

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?

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.