Prioritize user privacy and data security in your app. Discuss best practices for data handling, user consent, and security measures to protect user information.

All subtopics
Posts under Privacy & Security topic

Post

Replies

Boosts

Views

Activity

Persistent Tokens for Keychain Unlock in Platform SSO
While working with Platform SSO on macOS, I’m trying to better understand how the system handles cases where a user’s local account password becomes unsynchronized with their Identity Provider (IdP) password—for example, when the device is offline during a password change. My assumption is that macOS may store some form of persistent token during the Platform SSO user registration process (such as a certificate or similar credential), and that this token could allow the system to unlock the user’s login keychain even if the local password no longer matches the IdP password. I’m hoping to get clarification on the following: Does macOS actually use a persistent token to unlock the login keychain when the local account password is out of sync with the IdP password? If so, how is that mechanism designed to work? If such a capability exists, is it something developers can leverage to enable a true passwordless authentication experience at the login window and lock screen (i.e., avoiding the need for a local password fallback)? I’m trying to confirm what macOS officially supports so I can understand whether passwordless login is achievable using the persistent-token approach. Thanks in advance for any clarification.
1
3
267
Dec ’25
Entitlement values for the Enhanced Security and the Additional Runtime Platform Restrictions
I recently turned on the enhanced security options for my macOS app in Xcode 26.0.1 by adding the Enhanced Security capability in the Signing and Capabilities tab. Then, Xcode adds the following key-value sets (with some other key-values) to my app's entitlements file. <key>com.apple.security.hardened-process.enhanced-security-version</key> <integer>1</integer> <key>com.apple.security.hardened-process.platform-restrictions</key> <integer>2</integer> These values appear following the documentation about the enhanced security feature (Enabling enhanced security for your app) and the app works without any issues. However, when I submitted a new version to the Mac App Store, my submission was rejected, and I received the following message from the App Review team via the App Store Connect. Guideline 2.4.5(i) - Performance Your app incorrectly implements sandboxing, or it contains one or more entitlements with invalid values. Please review the included entitlements and sandboxing documentation and resolve this issue before resubmitting a new binary. Entitlement "com.apple.security.hardened-process.enhanced-security-version" value must be boolean and true. Entitlement "com.apple.security.hardened-process.platform-restrictions" value must be boolean and true. When I changed those values directly in the entitlements file based on this message, the app appears to still work. However, these settings are against the description in the documentation I mentioned above and against the settings Xcode inserted after changing the GUI setting view. So, my question is, which settings are actually correct to enable the Enhanced Security and the Additional Runtime Platform Restrictions?
3
0
999
Oct ’25
Clarification requested on Secure Enclave key usage across apps with shared keychain access group
During internal testing, we observed the following behavior and would appreciate clarification on whether it is expected and supported in production environments. When generating an elliptic-curve cryptographic key pair using "kSecAttrTokenIDSecureEnclave", and explicitly specifying a "kSecAttrAccessGroup", we found that cryptographic operations (specifically encryption and decryption) could be successfully performed using this key pair from two distinct applications. Both applications had the Keychain Sharing capability enabled and were signed with the same provisioning profile identity. Given the documented security properties of Secure Enclave, backed keys, namely that private key material is protected by hardware and access is strictly constrained by design, we would like to confirm whether the ability for multiple applications (sharing the same keychain access group and signing identity) to perform cryptographic operations with the same Secure Enclave–backed key is expected behavior on iOS. Specifically, we are seeking confirmation on: Whether this behavior is intentional and supported in production. Whether the Secure Enclave enforces access control primarily at the application-identifier (App ID) level rather than the individual app bundle level in this scenario. Whether there are any documented limitations or guarantees regarding cross-application usage of Secure Enclave keys when keychain sharing is configured. Any guidance or references to official documentation clarifying this behavior would be greatly appreciated.
2
2
432
Jan ’26
Enhanced Security Capability < iOS 26
Hi, After enabling the new Enhanced Security capability in Xcode 26, I’m seeing install failures on devices running < iOS 26. Deployment target: iOS 15.0 Capability: Enhanced Security (added via Signing & Capabilities tab) Building to iOS 18 device error - Unable to Install ...Please ensure sure that your app is signed by a valid provisioning profile. It works fine on iOS 26 devices. I’d like to confirm Apple’s intent here: Is this capability formally supported only on iOS 26 and later, and therefore incompatible with earlier OS versions? Or should older systems ignore the entitlement, meaning this behavior might be a bug?
9
0
1.4k
5d
Unable to Remove “Sign in with Apple” of my app
Hello, I’m trying to remove the “Sign in with Apple” for my app via the iOS settings (also tried on a Mac, and on the web via account.apple.com). When I tap “Stop Using”, nothing happens, the dialog disappear but the app remains listed. Someone said on a forum that the issue is linked with the ServiceId that doesn't exist anymore. But how to recover it ? And anyway this behavior is unintended and creates a gap in the process. Has anyone experienced this before? Is there a known fix, or should I contact Apple Support directly for server-side revocation? Thank you!
2
2
800
3w
Invalid web redirect url
I am implementing Apple Sign-In for a multi-platform application, specifically for the web component using the REST API flow. I am encountering an invalid_request Invalid web redirect url error when attempting to use a newly registered redirect URL. Here are the details: Original Test URL: I initially registered a redirect URL, let's call it [Your Original Test Redirect URL, e.g., https://test.yourdomain.com/auth/callback], for testing purposes. This URL worked correctly. New Service URL: I then registered a second redirect URL, [Your New Service Redirect URL, e.g., https://www.yourdomain.com/auth/callback], intended for my production service. This URL was registered approximately 5 days ago (including the weekend). The Problem: The new service URL ([Your New Service Redirect URL]) is still not working and consistently returns the invalid_request Invalid web redirect url error. Puzzling Behavior: Furthermore, I have since deleted the original test URL ([Your Original Test Redirect URL]) from the Service ID configuration in the Apple Developer portal. However, the deleted test URL still appears to function correctly when I use it. This situation is highly confusing: The newly registered URL is not working after 5 days, while the URL I have deleted from the configuration is still operational. The Service ID in question is [Your Service ID, e.g., com.yourdomain.service]. Could you please investigate why the new redirect URL ([Your New Service Redirect URL]) is not becoming active and is returning the invalid_request error, and also explain why the deleted URL ([Your Original Test Redirect URL]) remains functional? Any guidance or assistance you can provide to resolve this issue with the new URL would be greatly appreciated. Thank you for your time and support. Sincerely,
1
2
190
Jun ’25
How can my password manager app redirect users to the “AutoFill Passwords & Passkeys” settings page?
Hi all, I’m building a password manager app for iOS. The app implements an ASCredentialProviderExtension and has the entitlement com.apple.developer.authentication-services.autofill-credential-provider. From a UX perspective, I’d like to help users enable my app under: Settings → General → AutoFill & Passwords What I’ve observed: Calling UIApplication.openSettingsURLString only opens my app’s own Settings page, not the AutoFill list. Some apps (e.g. Google Authenticator) appear to redirect users directly into the AutoFill Passwords & Passkeys screen when you tap “Enable AutoFill.” 1Password goes even further: when you tap “Enable” in 1Password App, it shows a system pop-up, prompts for Face ID, and then enables 1Password as the AutoFill provider without the user ever leaving the app. Questions: Is there a public API or entitlement that allows apps to deep-link users directly to the AutoFill Passwords & Passkeys screen? Is there a supported API to programmatically request that my app be enabled as an AutoFill provider (similar to what 1Password seems to achieve)? If not, what is the recommended approach for guiding users through this flow? Thanks in advance!
1
0
507
Aug ’25
DCAppAttestService errors: com.apple.devicecheck.error 3 and 4
Hello, we are using DeviceCheck – App Attest in a production iOS app. The integration has been live for some time and works correctly for most users, but a small subset of users encounter non-deterministic failures that we are unable to reproduce internally. Environment iOS 14+ Real devices only (no simulator) App Attest capability enabled Correct App ID, Team ID and App Attest entitlement Production environment Relevant code let service = DCAppAttestService.shared service.generateKey { keyId, error in // key generation } service.attestKey(keyId, clientDataHash: hash) { attestation, error in // ERROR: com.apple.devicecheck.error 3 / 4 } service.generateAssertion(keyId, clientDataHash: clientDataHash) { assertion, error in // ERROR: com.apple.devicecheck.error 3 / 4 } For some users we intermittently receive: com.apple.devicecheck.error error 3 com.apple.devicecheck.error error 4 Characteristics: appears random affects only some users/devices sometimes resolves after time or reinstall not reproducible on our test devices NSError contains no additional diagnostic info Some questions: What is the official meaning of App Attest errors 3 and 4? Are these errors related to key state, device conditions, throttling, or transient App Attest service issues? Is there any recommended way to debug or gain more insight when this happens in production? Any guidance would be greatly appreciated, as this impacts real users and is difficult to diagnose. Thank you.
2
2
314
1w
500 error on validate_device_token endpoint since around March 4
Since around March 4, 2025 off and on, we've been receiving 500 errors back from the validate_device_token endpoint on development and production. Today (March 6) we are constantly getting 500 error back. https://api.development.devicecheck.apple.com/v1/validate_device_token This was working previously before then. No change has happened on our end since then. This is a critical piece for our infrastructure. Thanks in advance. -Matt
2
2
1.2k
Mar ’25
Auth Plugin Timeout Issue During Screen Unlock
Hi! We are developing an authentication plugin for macOS that integrates with the system's authentication flow. The plugin is designed to prompt the user for approval via a push notification in our app before allowing access. The plugin is added as the first mechanism in the authenticate rule, followed by the default builtin:authenticate as a fallback. When the system requests authentication (e.g., during screen unlock), our plugin successfully displays the custom UI and sends a push notification to the user's device. However, I've encountered the following issue: If the user does not approve the push notification within ~30 seconds, the system resets the screen lock (expected behavior). If the user approves the push notification within approximately 30 seconds but doesn’t start entering their password before the timeout expires, the system still resets the screen lock before they can enter their password, effectively canceling the session. What I've Tried: Attempted to imitate mouse movement after the push button was clicked to keep the session active. Created a display sleep prevention assertion using IOKit to prevent the screen from turning off. Used the caffeinate command to keep the display and system awake. Tried setting the result as allow for the authorization request and passing an empty password to prevent the display from turning off. I also checked the system logs when this issue occurred and found the following messages: ___loginwindow: -[LWScreenLock (Private) askForPasswordSecAgent] | localUser = >timeout loginwindow: -[LWScreenLock handleUnlockResult:] _block_invoke | ERROR: Unexpected _lockRequestedBy of:7 sleeping screen loginwindow: SleepDisplay | enter powerd: Process (loginwindow) is requesting display idle___ These messages suggest that the loginwindow process encounters a timeout condition, followed by the display entering sleep mode. Despite my attempts to prevent this behavior, the screen lock still resets prematurely. Questions: Is there a documented (or undocumented) system timeout for the entire authentication flow during screen unlock that I cannot override? Are there any strategies for pausing or extending the authentication timeout to allow for complex authentication flows like push notifications? Any guidance or insights would be greatly appreciated. Thank you!
3
2
313
Jun ’25
Repeated account-deleted Server-to-Server notifications for the same Apple ID
Hello, We are experiencing an issue related to Sign in with Apple Server-to-Server (S2S) notifications, specifically involving repeated delivery of the account-deleted event, and would like to ask whether this behavior is expected or known. Background We have configured an S2S notification endpoint for Sign in with Apple in accordance with Apple’s requirements for account status change notifications. Our endpoint: Is reachable over HTTPS Consistently returns HTTP 200 OK Successfully receives other S2S events, including: email-enabled email-disabled consent-revoked Issue: Repeated 'account-deleted' events for the same Apple ID For most users, the account-deleted event is delivered only once, as expected. However, for a specific Apple ID used with Sign in with Apple, we are observing repeated deliveries of the same account-deleted event, arriving at regular intervals (approximately every 5 minutes). The payload contents are identical between deliveries and include the same user identifier (sub) and event timestamp. Notably: The Apple ID deletion itself completed successfully The payload does not change between deliveries Our endpoint continues to return HTTP 200 OK for every request Questions We would appreciate clarification on the following points: Is repeated delivery of the same account-deleted event expected behavior in any scenario? Is there a retry or redelivery mechanism for this event type, even when HTTP 200 is returned? Could repeated deliveries indicate that the deletion process is still considered “in progress” on Apple’s side? Are developers expected to treat account-deleted events as at-least-once delivery and handle them idempotently? Additional context While researching this issue, we found a forum thread describing a very similar case: https://developer.apple.com/forums/thread/735674 In that discussion, Apple staff advised submitting the issue via Feedback Assistant, which suggests that this behavior may already be understood internally. We have also submitted a Feedback Assistant report with detailed logs and timestamps. Any clarification on the expected behavior or recommended handling for this scenario would be greatly appreciated. Thank you for your time and support.
2
2
910
Jan ’26
App Attest Suddenly Failing in Production — Error 4 (serverUnavailable)
Hi Apple Team and Community, We've encountered a sudden and widespread failure with the App Attest service starting today across multiple production apps and regions. The previously working implementation is now consistently returning the following error on iOS: The operation couldn’t be completed. (com.apple.devicecheck.error error 4.) (serverUnavailable) Despite the green status on Apple’s System Status page, this appears to be a backend issue—possibly infrastructure or DNS-related. Notably: The issue affects multiple apps. It is reproducible across different geographies. No code changes were made recently to the attestation logic. We previously reported a similar concern in this thread: App Attest Attestation Failing, but this new occurrence seems unrelated to any client-side cause. Update: An Apple engineer in this thread(https://developer.apple.com/forums/thread/782987) confirmed that the issue was due to a temporary DNS problem and has now been resolved. Can anyone else confirm seeing this today? Any insights from Apple would be appreciated to ensure continued stability. Thanks!
6
2
515
Jun ’25
Full disk access for CLI app
It seems it is not possible to give a CLI app (non .app bundle) full disk access in macOS 26.1. This seems like a bug and if not that is a breaking change. Anybody seeing the same problem? Our application needs full disk access for a service running as a LaunchDaemon. The binary is located in a /Library subfolder.
2
1
791
Nov ’25
Invalid web redirect url
I am implementing Apple Sign-In for a multi-platform application, specifically for the web component using the REST API flow. I am encountering an invalid_request Invalid web redirect url error when attempting to use a newly registered redirect URL. Here are the details: Original Test URL: I initially registered a redirect URL, let's call it [Your Original Test Redirect URL, e.g., https://test.yourdomain.com/auth/callback], for testing purposes. This URL worked correctly. New Service URL: I then registered a second redirect URL, [Your New Service Redirect URL, e.g., https://www.yourdomain.com/auth/callback], intended for my production service. This URL was registered approximately 5 days ago (including the weekend). The Problem: The new service URL ([Your New Service Redirect URL]) is still not working and consistently returns the invalid_request Invalid web redirect url error. Puzzling Behavior: Furthermore, I have since deleted the original test URL ([Your Original Test Redirect URL]) from the Service ID configuration in the Apple Developer portal. However, the deleted test URL still appears to function correctly when I use it. This situation is highly confusing: The newly registered URL is not working after 5 days, while the URL I have deleted from the configuration is still operational. The Service ID in question is [Your Service ID, e.g., com.yourdomain.service]. Could you please investigate why the new redirect URL ([Your New Service Redirect URL]) is not becoming active and is returning the invalid_request error, and also explain why the deleted URL ([Your Original Test Redirect URL]) remains functional? Any guidance or assistance you can provide to resolve this issue with the new URL would be greatly appreciated. Thank you for your time and support. Sincerely, I have the exact same problem. The newly registered URL is not working after 5 days, while the URL I have deleted from the configuration is still operational. In addition to the above problem, I also get a response of 'invalid_client' when I newly register a service in configuration. Please check it out as it needs to be resolved quickly.
0
2
170
Jun ’25
Sign-Up Not Complete error in integration of sign in with Apple
I hope this problem could be solved, also in case any other one strugling the same issue could be helpful. We are developing an iOS App which use "sign in with Apple" feature. We found we can not login with this feature, the "sign in with Apple" dialog box always flash an error info "Sign-Up Not Complete". We have double checked configuration of Bundle ID, and xcode capabilities, info.plist, entitlements, etc. We have even changed the developer team, using other bundle ID and demo code to testify this, also got failure of "Sign-Up Not Complete" error. We did even just use Apple official demo code (https://developer.apple.com/documentation/AuthenticationServices/implementing-user-authentication-with-sign-in-with-apple), also got the same failure. Interestingly, we found that using some old Bundle IDs which created before (even we did not use it for App yet), we could get "sign in with Apple" success logged in. Therefore we now can not include "sign in with Apple" feature in our App today, and this is the key feature in our App. Please help. Since there is very little information we could collect, I just put the debug error here: Authorization failed: Error Domain=AKAuthenticationError Code=-7003 "(null)" UserInfo={AKClientBundleID=com.nethawk.flutter.battlebuddy} LaunchServices: store (null) or url (null) was nil: Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo={NSDebugDescription=process may not map database, _LSLine=72, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler} Attempt to map database failed: permission was denied. This attempt will not be retried. Failed to initialize client context with error Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo={NSDebugDescription=process may not map database, _LSLine=72, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler} Failed to get application extension record: Error Domain=NSOSStatusErrorDomain Code=-54 "(null)" ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1001 "(null)"
4
2
273
Jun ’25
Exporting and re-importing ECC keys with file-based keychain
I'm trying to export and re-import a P-256 private key that was originally generated via SecKeyCreateRandomKey(), but I keep running into roadblocks. The key is simply exported via SecItemExport() with format formatWrappedPKCS8, and I did set a password just to be sure. Do note that I must use the file-based keychain, as the data protection keychain requires a restricted entitlement and I'm not going to pay a yearly fee just to securely store some private keys for a personal project. The 7-day limit for unsigned/self-signed binaries isn't feasible either. Here's pretty much everything I could think of trying: Simply using SecItemImport() does import the key, but I cannot set kSecAttrLabel and more importantly: kSecAttrApplicationTag. There just isn't any way to pass these attributes upfront, so it's always imported as Imported Private Key with an empty comment. Keys don't support many attributes to begin with and I need something that's unique to my program but shared across all the relevant key entries, otherwise it's impossible to query for only my program's keys. kSecAttrLabel is already used for something else and is always unique, which really only leaves kSecAttrApplicationTag. I've already accepted that this can be changed via Keychain Access, as this attribute should end up as the entry's comment. At least, that's how it works with SecKeyCreateRandomKey() and SecItemCopyMatching(). I'm trying to get that same behaviour for imports. Running SecItemUpdate() afterwards to set these 2 attributes doesn't work either, as now the kSecAttrApplicationTag is suddenly used for the entry's label instead of the comment. Even setting kSecAttrComment (just to be certain) doesn't change the comment. I think kSecAttrApplicationTag might be a creation-time attribute only, and since SecItemImport() already created a SecKey I will never be able to set this. It likely falls back to updating the label because it needs to target something that is still mutable? Using SecItemImport() with a nil keychain (i.e. create a transient key), then persisting that with SecItemAdd() via kSecValueRef does allow me to set the 2 attributes, but now the ACL is lost. Or more precise: the ACL does seem to exist as any OS prompts do show the label I originally set for the ACL, but in Keychain Access it shows as Allow all applications to access this item. I'm looking to enable Confirm before allowing access and add my own program to the Always allow access by these applications list. Private keys outright being open to all programs is of course not acceptable, and I can indeed access them from other programs without any prompts. Changing the ACL via SecKeychainItemSetAccess() after SecItemAdd() doesn't seem to do anything. It apparently succeeds but nothing changes. I also reopened Keychain Access to make sure it's not a UI "caching" issue. Creating a transient key first, then getting the raw key via SecKeyCopyExternalRepresentation() and passing that to SecItemAdd() via kSecValueData results in The specified attribute does not exist. This error only disappears if I remove almost all of the attributes. I can pass only kSecValueData, kSecClass and kSecAttrApplicationTag, but then I get The specified item already exists in the keychain errors. I found a doc that explains what determines uniqueness, so here are the rest of the attributes I'm using for SecItemAdd(): kSecClass: not mentioned as part of the primary key but still required, otherwise you'll get One or more parameters passed to a function were not valid. kSecAttrLabel: needed for my use case and not part of the primary key either, but as I said this results in The specified attribute does not exist. kSecAttrApplicationLabel: The specified attribute does not exist. As I understand it this should be the SHA1 hash of the public key, passed as Data. Just omitting it would certainly be an option if the other attributes actually worked, but right now I'm passing it to try and construct a truly unique primary key. kSecAttrApplicationTag: The specified item already exists in the keychain. kSecAttrKeySizeInBits: The specified attribute does not exist. kSecAttrEffectiveKeySize: The specified attribute does not exist. kSecAttrKeyClass: The specified attribute does not exist. kSecAttrKeyType: The specified attribute does not exist. It looks like only kSecAttrApplicationTag is accepted, but still ignored for the primary key. Even entering something that is guaranteed to be unique still results in The specified item already exists in the keychain, so I think might actually be targeting literally any key. I decided to create a completely new keychain and import it there (which does succeed), but the key is completely broken. There's no Kind and Usage at the top of Keychain Access and the table view just below it shows symmetric key instead of private. The kSecAttrApplicationTag I'm passing is still being used as the label instead of the comment and there's no ACL. I can't even delete this key because Keychain Access complains that A missing value was detected. It seems like the key doesn't really contain anything unique for its primary key, so it will always match any existing key. Using SecKeyCreateWithData() and then using that key as the kSecValueRef for SecItemAdd() results in A required entitlement isn't present. I also have to add kSecUseDataProtectionKeychain: false to SecItemAdd() (even though that should already be the default) but then I get The specified item is no longer valid. It may have been deleted from the keychain. This occurs even if I decrypt the PKCS8 manually instead of via SecItemImport(), so it's at least not like it's detecting the transient key somehow. No combination of kSecAttrIsPermanent, kSecUseDataProtectionKeychain and kSecUseKeychain on either SecKeyCreateWithData() or SecItemAdd() changes anything. I also tried PKCS12 despite that it always expects an "identity" (key + cert), while I only have (and need) a private key. Exporting as formatPKCS12 and importing it with itemTypeAggregate (or itemTypeUnknown) does import the key, and now it's only missing the kSecAttrApplicationTag as the original label is automatically included in the PKCS12. The outItems parameter contains an empty list though, which sort of makes sense because I'm not importing a full "identity". I can at least target the key by kSecAttrLabel for SecItemUpdate(), but any attempt to update the comment once again changes the label so it's not really any better than before. SecPKCS12Import() doesn't even import anything at all, even though it does return errSecSuccess while also passing kSecImportExportKeychain explicitly. Is there literally no way?
4
0
1k
Jan ’26
QuickLookAR shares the actual USDZ model instead of the original website URL — critical copyright and data leak issue on iOS 26
QuickLookAR shares the actual USDZ model instead of the original website URL — critical copyright and data leak issue on iOS 26 Since iOS 26, QuickLookAR (or ARQuickLookPreviewItem) no longer preserves the original web URL when sharing a model. Instead of sending the link to the hosted file, the system directly shares the actual USDZ model file with the recipient. This is a critical regression and a severe breach of intellectual property protection, as it exposes proprietary 3D models that must never be distributed outside of the controlled web environment. In earlier iOS versions (tested up to iOS 18), QuickLookAR correctly handled sharing — the share sheet would send the website link where the model is hosted, not the file itself. Starting with iOS 26, this behavior has changed and completely breaks the intended secure flow for AR experiences. Our project relies on allowing users to view models in AR via QuickLook, without ever transferring the underlying 3D assets. Now, the share operation forces full file sharing, giving end users unrestricted access to the model file, which can be copied, rehosted, or reverse-engineered. This issue critically affects production environments and prevents us from deploying our AR-based solutions. Implement a standard QuickLookAR preview with a USDZ file hosted on your web server (e.g., via ARQuickLookPreviewItem). 2. Open the AR view on iOS 26. 3. Tap the Share icon from QuickLookAR. 4. Send via any messenger (Telegram, WhatsApp, etc.). 5. Observe that the actual .usdz model is sent instead of the original website URL. ⸻ Expected behavior: QuickLookAR should share only the original URL (as in iOS 17–18), not the file itself. This ensures that intellectual property and licensed 3D models remain protected and controlled by the content owner. ⸻ Actual behavior: QuickLookAR shares the entire USDZ file, leaking the model content outside of the intended environment. ⸻ Impact: • Violation of copyright and confidential data policies • Loss of control over proprietary 3D assets • Breaking change for all existing web-based AR integrations • Critical blocker for AR production deployment ⸻ Environment: • iOS 26.0 and 26.1 (tested on iPhone 14, iPhone 15) • Safari + QuickLookAR integration • Works correctly on iOS 17 / iOS 18 ⸻ Notes: This regression appears to have been introduced in the latest iOS 26 system handling of QuickLookAR sharing. Please escalate this issue to the ARKit / QuickLook engineering team as it directly affects compliance, IP protection, and usability of AR features across production applications. Additional Notes / Verification: Please test this behavior yourself using the CheckAR test model on my website: https://admixreality.com/ios26/ • If the login page appears, click “Check AR” and then “View in Your Space”. • On iOS 18 and earlier, sharing correctly sends the website URL. • On iOS 26, sharing sends the actual USDZ model file. This clearly demonstrates the regression and the security/IP issue.
8
0
892
6d
Endpoint Security Framework Bug: setuid Event Incorrectly Attributed to Parent Process During posix_spawn
Feedback ticket ID: FB21797397 Summary When using posix_spawn() with posix_spawnattr_set_uid_np() to spawn a child process with a different UID, the eslogger incorrectly reports a setuid event as an event originating from the parent process instead of the child process. Steps to Reproduce Create a binary that do the following: Configure posix_spawnattr_t that set the process UIDs to some other user ID (I'll use 501 in this example). Uses posix_spawn() to spawn a child process Run eslogger with the event types setuid, fork, exec Execute the binary as root process using sudo or from root owned shell Terminate the launched eslogger Observe the process field in the setuid event Expected behavior The eslogger will report events indicating a process launch and uid changes so the child process is set to 501. i.e.: fork setuid - Done by child process exec Actual behavior The process field in the setuid event is reported as the parent process (that called posix_spawn) - indicating UID change to the parent process. Attachments I'm attaching source code for a small project with a 2 binaries: I'll add the source code for the project at the end of the file + attach filtered eslogger JSONs One that runs the descirbed posix_spawn flow One that produces the exact same sequence of events by doing different operation and reaching a different process state: Parent calls fork() Parent process calls setuid(501) Child process calls exec() Why this is problematic Both binaries in my attachment do different operations, achieving different process state (1 is parent with UID=0 and child with UID=501 while the other is parent UID=501 and child UID=0), but report the same sequence of events. Code #include <cstdio> #include <spawn.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <sys/wait.h> #include <string.h> // environ contains the current environment variables extern char **environ; extern "C" { int posix_spawnattr_set_uid_np(posix_spawnattr_t *attr, uid_t uid); int posix_spawnattr_set_gid_np(posix_spawnattr_t *attr, gid_t gid); } int main() { pid_t pid; int status; posix_spawnattr_t attr; // 1. Define the executable path and arguments const char *path = "/bin/sleep"; char *const argv[] = {(char *)"sleep", (char *)"1", NULL}; // 2. Initialize spawn attributes if ((status = posix_spawnattr_init(&attr)) != 0) { fprintf(stderr, "posix_spawnattr_init: %s\n", strerror(status)); return EXIT_FAILURE; } // 3. Set the UID for the child process (e.g., UID 501) // Note: Parent must be root to change to a different user uid_t target_uid = 501; if ((status = posix_spawnattr_set_uid_np(&attr, target_uid)) != 0) { fprintf(stderr, "posix_spawnattr_set_uid_np: %s\n", strerror(status)); posix_spawnattr_destroy(&attr); return EXIT_FAILURE; } // 4. Spawn the process printf("Spawning /bin/sleep 1 as UID %d...\n", target_uid); status = posix_spawn(&pid, path, NULL, &attr, argv, environ); if (status == 0) { printf("Successfully spawned child with PID: %d\n", pid); // Wait for the child to finish (will take 63 seconds) if (waitpid(pid, &status, 0) != -1) { printf("Child process exited with status %d\n", WEXITSTATUS(status)); } else { perror("waitpid"); } } else { fprintf(stderr, "posix_spawn: %s\n", strerror(status)); } // 5. Clean up posix_spawnattr_destroy(&attr); return (status == 0) ? EXIT_SUCCESS : EXIT_FAILURE; } #include <cstdio> #include <cstdlib> #include <unistd.h> #include <sys/wait.h> #include <errno.h> #include <string.h> // This program demonstrates fork + setuid + exec behavior for ES framework bug report // 1. Parent forks // 2. Parent does setuid(501) // 3. Child waits with sleep syscall // 4. Child performs exec int main() { printf("Parent PID: %d, UID: %d, EUID: %d\n", getpid(), getuid(), geteuid()); pid_t pid = fork(); if (pid < 0) { // Fork failed perror("fork"); return EXIT_FAILURE; } if (pid == 0) { // Child process printf("Child PID: %d, UID: %d, EUID: %d\n", getpid(), getuid(), geteuid()); // Child waits for a bit with sleep syscall printf("Child sleeping for 2 seconds...\n"); sleep(2); // Child performs exec printf("Child executing child_exec...\n"); // Get the path to child_exec (same directory as this executable) char *const argv[] = {(char *)"/bin/sleep", (char *)"2", NULL}; // Try to exec child_exec from current directory first execv("/bin/sleep", argv); // If exec fails perror("execv"); return EXIT_FAILURE; } else { // Parent process printf("Parent forked child with PID: %d\n", pid); // Parent does setuid(501) printf("Parent calling setuid(501)...\n"); if (setuid(501) != 0) { perror("setuid"); // Continue anyway to observe behavior } printf("Parent after setuid - UID: %d, EUID: %d\n", getuid(), geteuid()); // Wait for child to finish int status; if (waitpid(pid, &status, 0) != -1) { if (WIFEXITED(status)) { printf("Child exited with status %d\n", WEXITSTATUS(status)); } else if (WIFSIGNALED(status)) { printf("Child killed by signal %d\n", WTERMSIG(status)); } } else { perror("waitpid"); } } return EXIT_SUCCESS; } posix_spawn.json fork_exec.json
2
0
547
2w
Issue: Plain Executables Do Not Appear Under “Screen & System Audio Recording” on macOS 26.1 (Tahoe)
Summary I am investigating a change in macOS 26.1 (Tahoe) where plain (non-bundled) executables that request screen recording access no longer appear under: System Settings → Privacy & Security → Screen & System Audio Recording This behavior differs from macOS Sequoia, where these executables did appear in the list and could be managed through the UI. Tahoe still prompts for permission and still allows the executable to capture the screen once permission is granted, but the executable never shows up in the UI list. This breaks user expectations and removes UI-based permission management. To confirm the behavior, I created a small reproduction project with both: a plain executable, and an identical executable packaged inside an .app bundle. Only the bundled version appears in System Settings. Observed Behaviour 1. Plain Executable (from my reproduction project) When running a plain executable that captures the screen: macOS displays the normal screen-recording permission prompt. Before granting permission: screenshots show only the desktop background. After granting permission: screenshots capture the full display. The executable does not appear under “Screen & System Audio Recording”. Even when permission is granted manually (e.g., dragging the executable into the pane), the executable still does not appear, which prevents the user from modifying or revoking the permission through the UI. If the executable is launched from inside another app (e.g., VS Code, Terminal), the parent app appears in the list instead, not the executable itself. 2. Bundled App Version (from the reproduction project) I packaged the same code into a simple .app bundle (ScreenCaptureApp.app). When running the app: The same permission prompt appears. Pre-permission screenshots show the desktop background. Post-permission screenshots capture the full display. The app does appear under “Screen & System Audio Recording”. This bundle uses the same underlying executable — the only difference is packaging. Hypothesis macOS 26.1 (Tahoe) appears to require app bundles for an item to be shown in the Screen Recording privacy UI. Plain executables: still request and receive permission, still function correctly after permission is granted, but do not appear in the System Settings list. This may be an intentional change, undocumented behavior, or a regression. Reproduction Project The reproduction project includes: screen_capture.go A simple Go program that captures screenshots in a loop. screen_capture_executable Plain executable built from the Go source. ScreenCaptureApp.app/ App bundle containing the same executable. build.sh Builds both the plain executable and the app bundle. Permission reset and TCC testing scripts. The project demonstrates the behavior consistently. Steps to Reproduce Plain Executable Build: ./build.sh Reset screen capture permissions: sudo tccutil reset ScreenCapture Run: ./screen_capture_executable Before granting: screenshots show desktop only. Grant permission when prompted. After granting: full screenshots. Executable does not appear in “Screen & System Audio Recording”. Bundled App Build (if not already built): ./build.sh Reset permissions (optional): sudo tccutil reset ScreenCapture Run: open ScreenCaptureApp.app Before granting: screenshots show desktop. After granting: full screenshots. App bundle appears in the System Settings list. Additional Check I also tested launching the plain executable as a child process of another executable, similar to how some software architectures work. Result: Permission prompt appears Permission can be granted Executable still does not appear in the UI, even though TCC tracks it internally → consistent with the plain-executable behaviour. This reinforces that only app bundles are listed. Questions for Apple Is the removal of plain executables from “Screen & System Audio Recording” an intentional change in macOS Tahoe? If so, does Apple now require all screen-recording capable binaries to be packaged as .app bundles for the UI to display them? Is there a supported method for making a plain executable (launched by a parent process) appear in the list? If this is not intentional, what is the recommended path for reporting this as a regression? Files Unfortunately, I have discovered the zip file that contains my reproduction project can't be directly uploaded here. Here is a Google Drive link instead: https://drive.google.com/file/d/1sXsr3Q0g6_UzlOIL54P5wbS7yBkpMJ7A/view?usp=sharing Thank you for taking the time to review this. Any insight into whether this change is intentional or a regression would be very helpful.
3
0
992
Dec ’25