Hello, We have an app that was transferred from Team A to Team B. We are now considering transferring it back to Team A, and we would like to confirm what happens to the keychain items that the original Team A build wrote, before we commit to that plan. Current state The app is currently owned by Team B. No build has ever been released or distributed from Team B — no App Store release and no TestFlight distribution. Every user on the App Store is still running the build that Team A signed. The app stores a login token in the keychain under a plain keychain access group declared in the Xcode project: $(AppIdentifierPrefix)com.example.game.shared. It is not an App Group, and not an AGI keychain access group. Some of our users are guest accounts. A guest account has no recoverable credential — no email, no phone number, no third-party identifier — so the token in the keychain is the only thing tying them to their progress. The plan would be: transfer the app back to Team A, then have Team A create a new distribution certificate and a new provisioning profile, and ship a new build. Our understanding We read the documentation as follows. An access group is "a logical collection of apps tagged with a particular group name string", and each keychain item is "always part of exactly one group". The group name is the string declared in the entitlements with the App ID Prefix prepended — "Xcode automatically prefixes keychain groups with your team ID" — and that prefix is resolved at build time from the provisioning profile. Access is decided by comparing the group string in the binary's entitlements against the item's kSecAttrAccessGroup. If the group is not one the app belongs to, a write returns errSecMissingEntitlement and a read returns errSecItemNotFound. A provisioning profile's DeveloperCertificates property lists "the certificates of each developer who can sign code covered by the profile" (TN3125). So the certificate decides who may sign, not which access group the app belongs to. When the app is transferred back to Team A, its App ID returns to Team A, and therefore the App ID Prefix — and with it the group name — should be the same string as before. If all five hold, a new build signed by Team A with a newly issued certificate should still be able to read the items written by the original Team A build, and our guest users would not be affected at all. Our questions Q1 — Does the App ID Prefix revert? When an app is transferred back to its original team, is the App ID Prefix guaranteed to return to the value it had before? Or can a team end up with a different prefix than it had originally,This is the one step in our reasoning that we have not been able to find stated anywhere. Q2 — Does a newly issued certificate or profile have any bearing? Team A would create a new distribution certificate and a new provisioning profile rather than reuse the previous ones. Does that affect keychain access in any way? Our reading is that it does not, because the access check compares group strings and the signing certificate is not an input to that comparison. Could you confirm? Q3 — Are the original items still present and readable? Assuming no Team B–signed build ever reached any device, are the items written by the original Team A build still on the device and readable by a Team A–signed build after the round trip? "Overview of app transfer" says keychain sharing "continues to work only until the app is updated" — we read that as meaning the trigger is a build from the new team reaching the device, not the transfer itself. Q4 — Transferring back. Is transferring an app back to its original team supported? Are there restrictions we should know about — a cooldown, a cap on the number of transfers, or a requirement that the app meet the transfer criteria again? Specifically: if Team B has uploaded a build to App Store Connect but never released or distributed it, does that affect the app's eligibility to be transferred back? Q5 — Guest accounts. Because our guest users have no recoverable credential, "just ask the user to sign in again" is not available to them. Is there a recommended approach for this case that we should follow? Thanks!

Hello Apple Technical Support, We need a documented feasibility clarification before implementing a native macOS app running in the logged-in user's context. The app needs to generate and persist a software RSA 3072-bit private key in the Data Protection Keychain (DPK), for RS256 (RSASSA-PKCS1-v1_5 with SHA-256). The required properties are effective private-key non-exportability and signing-only use, enforced beyond our app's choice not to call export or other cryptographic operations. We also need a supported way to verify these properties without attempting any private-key export. We distinguish these requirements from access-group authorization, kSecAttrSynchronizable=false, ThisDeviceOnly accessibility, and hardware-bound keys. We recognize that access groups are a different boundary from exact CDHash/build exclusivity; we do not claim that exclusivity is satisfied. Group membership alone does not establish the requested key properties, including for another process legitimately entitled to the same group. Environment: recorded static header provenance is MacOSX27.0.sdk (Command Line Tools), not a successful build or runtime validation. Target macOS version and build: Apple M4, 16GB in memory, macOS Tahoe version 26.6.2. No DPK implementation or experiment is being submitted as evidence. Please clarify these four points: Is there an officially supported API/attribute combination to generate and persist this software RSA3072 key in DPK with enforceable non-exportability and signing-only use (no decrypt, unwrap or derive)? If yes, please identify the exact APIs, attribute placement and values, applicable macOS/SDK versions, and enforcement limits. Please distinguish actual key restrictions from requested attributes or app-side policy. How does that combination, if supported, relate to the generic macOS kSecKeyExtractable=false exception documented for SecKeyCopyExternalRepresentation [1], versus the Apple DTS explanation that raw bytes of standard DPK keys can be obtained through that API [2]? Does the exception apply to software RSA keys generated in DPK, or only to other key implementations? Please distinguish kSecKeyExtractable from kSecAttrIsExtractable where relevant. Which supported attributes, query APIs or other evidence establish effective non-exportability and signing-only restrictions without attempting export? Please specify whether SecKeyCopyAttributes or an item query guarantees the required fields for this key/store combination, and how absent or unsupported fields must be interpreted. We will not treat a missing field as false or infer enforcement from creation inputs. If this combination is not supported for software RSA in DPK, please confirm that limitation explicitly and distinguish it from hardware-bound keys. We are not asking to substitute Secure Enclave/EC or another algorithm, and do not assume hardware guarantees apply to software RSA. References: [1] SecKeyCopyExternalRepresentation https://developer.apple.com/documentation/security/seckeycopyexternalrepresentation(::) [2] Apple DTS reply (June 2023), Developer Forums thread 731001 https://developer.apple.com/forums/thread/731001 [3] TN3137: On Mac keychain APIs and implementations https://developer.apple.com/documentation/technotes/tn3137-on-mac-keychains [4] Protecting keys with the Secure Enclave https://developer.apple.com/documentation/security/protecting-keys-with-the-secure-enclave An applicable technical answer with references and limits, or an explicit statement that this combination is unsupported, would resolve the feasibility question. If support or a non-exporting verification method cannot be established, we will keep support NOT_ESTABLISHED and implementation blocked. A successful signature or access-group isolation alone would not close it. Thank you. fapontec

Background: We are loading a web login page inside ASWebAuthenticationSession. For login page, username and password have autofill password options enabled. On click of the username textfield when we tap the system "Passwords" suggestion in the QuickType bar above the keyboard causes the app to become completely unresponsive. No crash occurs and nothing is logged to the console. The only option to get back to the app is we must force-quit to recover. This issue is observed only on OS 26.6.1 and 26.7.1 other variant of the OS-26.x seems to be working fine. We have tested the gmail app having the ASWebAuthenticationSession for login scenario, the similar issue is observed in that too. Does anyone else also have faced similar issue ? Any help/pointers much appreciated.

While working with Local Authentication framework, specifically LAContext class I found myself with few contradictions to documentation, and although I believe that those differences are rather positive than negative, either documentation is lacking behind or those APIs are not working as intended - which I believe is combination of both. 1. Local Authentication 1.1 Biometry type, and associated with it hash With introduction of LADomainState one can extract underlying biometry type along it's (current) state hash this way: @available(iOS 18, macOS 15, *) func postIOS18() { let context = LAContext() let biometryType = context.domainState.biometry.biometryType // (1) let biometryStateHash = context.domainState.biometry.stateHash // (2) } prior to receiving above APIs, we would retrieve such information something along those lines: func preIOS18() { let context = LAContext() let policy: LAPolicy // ... var error: NSError? _ = context.canEvaluatePolicy(policy, error: error) // (3) // ... (Handle error - if present) let biometryType = context.biometryType // (4) let biometryStateHash = context.evaluatedPolicyDomainState // (5) } However, moving let biometryType = context.biometryType (4) before call to canEvaluatePolicy (3) still yields correct biometry type. This is in contradiction to article from Local Authentication documentation page Optionally, Adjust Your User Interface to Accommodate Face ID. Furthermore, biometryType documentation does not mentions such requirement. Another difference is that call to canEvaluatePolicy (3) might return an error, eg. LAError(.biometryLockout) (if implemented correctly) preventing as from returning biometryStateHash (5) with nil value. This is not the case for new API, where the same call (2) will yield nil as a result - LADomainStateBiometry documentation does not mention it. In summary, here are some questions: Which API should be used to retrieve biometry type?, and why the "older way" has not been deprecated? Is is safe to assume that calls to biometryType and stateHash from LADomainStateBiometry will produce meaningful results without prior call to canEvaluatePolicy? Should I assume that call to biometryType found on LAContext instance will always return biometryType without prior call to canEvaluatePolicy?, or perhaps those are only side effects of changes made to accommodate LADomainState, and prior to them (pre-iOS 18) we must call canEvaluatePolicy to get meaningful value. Are the stateHash properties found on LADomainState, LADomainStateBiometry and LADomainStateCompanion will return nil upon encountering any error under the hood? (which would be equivalent of below code, prior to iOS 18) func biometryStateHash() -> Data? { let context = LAContext() if #available(iOS 18, macOS 15, *) { _ = context.canEvaluatePolicy(policy, error: nil) return context.evaluatedPolicyDomainState } else { return context.domainState.biometry.stateHash } } 1.2 Deprecation of evaluatedDomainState There is a forum post LAContext.evaluatedPolicyDomainState change between major OS versions mentioning missing documentation (fixed), however there's still information missing of how they correlate to each other. From my findings, the deprecated evaluatedDomainState property value matches those of LADomainState stateHash (when no companion device is present), and LADomainStateBiometry stateHash (all the time). Are those assumptions correct? 1.3 LAContext (authenticated) session lifespan Theres is little information about it state when authenticated by the user. Documentation on LAContext does not mention this behavior, while there are hints that once authenticated, and context is reused, any farther calls will not prompt user with UI. The problem is that this behavior is little, to no documented. Here are few examples I have found: Logging a User into Your App with Face ID or Touch ID (code sample) contains comment // Get a fresh context for each login. If you use the same context on multiple attempts //  (by commenting out the next line), then a previously successful authentication //  causes the next policy evaluation to succeed without testing biometry again. //  That's usually not what you want. Recent forum post, where such approach is mentioned by Quinn 'The Eskimo!' "At the API level, one option you have is to create an LAContext and pass it in to each SecItemCopyMatching call via kSecUseAuthenticationContext." WWDC22 Streamline local authorization flows session "By binding the LAContext to our private key reference, we ensure that executing the signature operation will not trigger another authentication, while allowing the operation to continue without unnecessary prompts. These binding also means that no additional user interactions will be required for future signatures until the LAContext is invalidated." Furthermore this is complicated by the touchIDAuthenticationAllowableReuseDuration property from LAContext instance which states that "The default value is 0, meaning that no previous biometric unlock can be reused." which is in direct contradiction to what I have experienced while working with LAContext and sources mentioned above. While digging on this, whether this behavior is intended or not, I came across a post (I would love to share it, but the domain is not permitted) that shared the same findings (and concerns) regarding LAContext behavior as me. The author also provided a FB9984036 feedback number - although no further update was made on that topic. So my questions are: Is it safe to reuse LAContext (authenticated) instance? How long such instance is considered authenticated?, is it a time duration or perhaps it stays in authenticated state until explicitly invalidated using invalidate method. (its invalidated for sure when app is terminated, but this was to be expected :)) How does,touchIDAuthenticationAllowableReuseDuration work, and how does it correlate to "reusability" of the authenticated LAContext instance? In what scenarios, touchIDAuthenticationAllowableReuseDuration should be used and what is its expected behavior? (I have tried it both on iOS and macOS; from my perspective API this does not "work")

We maintain an SFAuthorizationPluginView-based authorization plugin (mechanisms registered in system.login.console) on macOS 26 (Darwin 25.x) and are seeing a cosmetic but user-visible issue at the login window that we believe originates in the host, not our code. We'd like to confirm whether it's expected behavior or a bug worth filing via Feedback. Setup Two local users, A and B. Our plugin adds a custom mechanism to the login chain, so after credential submission the host may present additional UI (our mechanism's view). Each authorization round runs in a fresh SecurityAgentHelper process (verified via PID in logs), so no state of ours survives between rounds. Reproduction Log out of user A at the login window. Select user B and type their password. Submit. Our mechanism (invoked after submission, e.g. an enrollment prompt for a not-yet-enrolled user) presents its UI. Observed For roughly 1.1–1.4 s between our mechanism's window appearing and covering the host's, the login window shows user A's name/avatar tile — the previously selected user — before our panel covers it. Instrumentation confirms: Our process logs willActivate(withUser:) delivering user A (the previous round's user) while the authorization context (GetContextValue on kAuthorizationEnvironmentUsername) correctly contains user B. The stale tile renders inside what appears to be the host's own window (class LUI2Window, created ~300 ms before our surface activates). Our code makes no writes to the engine context at that point (we log every SetContextValue; zero writes occurred during the flip window). The flip only happens when our mechanism round starts after credential submission. If the mechanism round starts before user selection (the normal login path), each user click produces a fresh willActivate with the correct name and no flip is visible. Question Why does the login window display the previous round's user (user A) after I've selected and submitted credentials for user B? The willActivate(withUser:) callback our mechanism receives still carries user A at that moment, while the authorization context already contains user B — the two disagree. Is the host intentionally re-showing the last logged-in user's tile when a mechanism presents UI after credential submission, and can a mechanism do anything to prevent it?

Hello, I’m working on a security agent plugin for Mac. The plugin provides a mechanism with custom UI via SFAuthorizationPluginView and a privileged mechanism with the business logic. The plugin needs to support unlocking the device, so I changed the authorize right to invoke my agent: <?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>class</key> <string>evaluate-mechanisms</string> <key>created</key> <real>731355374.33196402</real> <key>mechanisms</key> <array> <string>FooBar:loginUI</string> <string>builtin:reset-password,privileged</string> <string>FooBar:authenticate,privileged</string> <string>builtin:authenticate,privileged</string> </array> <key>modified</key> <real>795624943.31730103</real> <key>shared</key> <true/> <key>tries</key> <integer>10000</integer> <key>version</key> <integer>1</integer> </dict> </plist> I also changed the system.login.screensaver right to use authorize-session-owner: <?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>class</key> <string>rule</string> <key>comment</key> <string>The owner or any administrator can unlock the screensaver, set rule to "authenticate-session-owner-or-admin" to enable SecurityAgent.</string> <key>created</key> <real>731355374.33196402</real> <key>modified</key> <real>795624943.32567298</real> <key>rule</key> <array> <string>authenticate-session-owner</string> </array> <key>version</key> <integer>1</integer> </dict> </plist> I also set screenUnlockMode to 2, as was suggested in this thread: macOS Sonoma Lock Screen with SFAutorizationPluginView is not hiding the macOS desktop. In the Display Authorization plugin at screensaver unlock thread, Quinn said that authorization plugins are not able to use Touch ID. However, on a MacBook with at touch bar, when I lock the screen, close the lid, and then open it, the touch bar invites me to unlock with Touch ID. If I choose to do so, the screen unlocks and I can interact with the computer, but the plugin UI stays on screen and never goes away, and after about 30 seconds the screen locks back. I can reliably reproduce it on a MacBook Pro with M1 chip running Tahoe 26.1. Is this a known macOS bug? What can I do about it? Ideally, I would like to be able to integrate Touch ID into my plugin, but since that seems to be impossible, the next best thing would be to reliably turn it off completely. Thanks in advance.

I am validating a local backup and recovery workflow using artificial files only. I would like guidance on supported quarantine handling, not a way to bypass Gatekeeper. The recorded tests used: Native ditto with --rsrc --extattr --acl --qtn. Native pax-tar creation and restore with --mac-metadata and --fflags. Important limitation: the quarantine markers were seeded manually in the test fixtures. These were not files quarantined through a real browser download, so I have not established that the fixtures represent normal download provenance. Unmarked controls matched their source. In marked copy/restore cases, payload hashes and other checked metadata matched, but com.apple.quarantine differed. One earlier copy recorded a flag-prefix change from 0081 to 0281; other marker fields also changed. Original marker bytes can be retained exactly as archive data, but that does not explain the security effect of the native-restored value. I have not stripped or normalized restored markers, changed Gatekeeper settings, or tested execution of the restored files. An earlier project record lists macOS 26.5.1. The current OS build and exact native-tool versions have not been refreshed for this question. Could you clarify: Is manual marker seeding a supported way to test copy/restore behavior, or should this be evaluated using an OS-managed quarantine event instead? Can these native operations intentionally change quarantine state, and which documented interfaces or guidance establish the meaning and security impact? Is preserving the original bytes as archive evidence while leaving native-restored metadata untouched the supported approach? What checks or supported options should a recovery workflow use without rewriting the marker or weakening Gatekeeper? I am not claiming this is a macOS vulnerability or that the changed value is harmless. No business files, private logs or attachments are included.

This is a pre-implementation question about supported direct Keychain service access, based on documentation and SDK-declaration review. No device/Simulator result, runtime failure, compiled sample or verified signing configuration is being reported. Assumed configurations An embedded, app-specific, non-UI ExtensionFoundation extension, restricted to its containing app's extension point. No unrestricted or third-party extension scope is assumed. A: the extension point requires EnhancedSecurity(true). B: the point definition omits EnhancedSecurity. This is not a claim that B is unsandboxed or equivalent to every configuration explicitly declaring EnhancedSecurity(false). Generic-password items, with valid signed membership in the destination Keychain access group assumed for the question only. If that assumption cannot hold for A or B, please identify the unsupported prerequisite. No real identifiers or profiles are supplied. Version scope The API question concerns iOS 26.0 and later only where the relevant symbols/configurations are supported. In the installed iPhoneOS 27.0 SDK declarations inspected, AppExtensionPoint, EnhancedSecurity and UserInterface have iOS 26.0 availability; some binding conveniences have iOS 26.2 availability. Those are declaration observations, not evidence of Keychain authorization or behavior on any OS release. No runtime comparison or final deployment target is selected. Please specify any finer minimum OS/SDK requirement or version-dependent difference; do not infer older-iOS support from the framework name alone. Question For A and B separately, is each of SecItemCopyMatching, SecItemAdd, SecItemUpdate and SecItemDelete supported directly from the extension process for those items, without forwarding the operation to the containing app? Please distinguish the four operations and, for any supported or conditional case, identify: The public sandbox/service rule and required entitlements, separately from access-group membership. Applicable OS/SDK versions and any device-versus-Simulator or development-versus-distribution limits. Lock state, item accessibility, user-interaction or other prerequisites that change the answer. If a case is unsupported or unspecified, stating that and citing the applicable public documentation would resolve that part of the question. API availability or absence of the EnhancedSecurity requirement alone is not being treated as permission to access the service. This asks for the direct API/service boundary only. Relevant public references https://developer.apple.com/documentation/extensionfoundation/adding-support-for-app-extensions-to-your-app https://developer.apple.com/documentation/extensionfoundation/appextensionpoint/enhancedsecurity https://developer.apple.com/documentation/security/sharing-access-to-keychain-items-among-a-collection-of-apps

We develop an authorization plugin that replaces password entry at the login window and at screen unlock with a phone-based sign-in. The user scans a QR code with their phone, or the Mac reaches the phone over Bluetooth. Either way the plugin ends up with the user's password, which it hands to the authorization engine as if it had been typed. All networking runs in a LaunchDaemon that the plugin calls over XPC. Setup system.login.console: loginwindow:login → OurPlugin:login system.login.screensaver: rule use-login-window-ui → authenticate-session-owner-or-admin, with screenUnlockMode set to 2 authenticate: builtin:authenticate → OurPlugin:authenticate The UI is an SFAuthorizationPluginView subclass. On success we set username and password in the context (plus home at login) and call SetResult with kAuthorizationResultAllow. What we see on macOS 27 Since moving to macOS 27 on a MacBook Pro (M3 Pro), we hit these more often: Touch ID unlocks the Mac but leaves our view on screen. Open the lid and unlock with Touch ID. The desktop becomes usable, but our plugin view stays on top, and shortly after the screen locks again. Same symptom as thread 819454, where it was filed as FB22289735. Saved passwords disappear from apps after an unlock through our plugin. They come back only after the user logs out and in again. This looks like FB13128730 (thread 796487). The lock screen stays on the desktop after sign-in. The clock, the user picture and our view, with its filled-in password field, stay on screen while the menu bar and Dock are drawn on top of them. Similar to FB12074874. We also saw this once: the password field in our view would not take keyboard input at the lock screen. Every key press just played the system alert sound, and nothing was typed. Questions Is there any workaround for these on macOS 27? Or a supported way to stop macOS offering Touch ID while our plugin handles unlock? Is an SFAuthorizationPluginView plugin still a supported way to replace the login and unlock UI? If not, what should we move to? Is Platform SSO with the new web-based authentication in macOS 27 (login window, Lock Screen and FileVault unlock) the path you would recommend? If so, is there a supported option for offline sign-in, which we do over Bluetooth today?

I'm testing PRF evaluation with a YubiKey Bio through AuthenticationServices on iOS. Registration succeeds, but during later authentication with the enrolled fingerprint, I don't receive a PRF result. Using the key’s FIDO2 PIN works. Environment iPhone 12 iOS 27.0.1 YubiKey Bio connected through USB Firmware: 5.7.0 Steps to reproduce Configure a FIDO2 PIN and enroll a fingerprint on the YubiKey Bio. Connect the key to the iPhone. Register a credential using ASAuthorizationSecurityKeyPublicKeyCredentialProvider with PRF support requested. Request authentication for the registered credential with PRF input and userVerificationPreference = .required. Authenticate using the enrolled fingerprint. Check the returned PRF result. Compare this with authentication using the FIDO2 PIN. Expected result Successful authentication with PRF evaluation returns a 32-byte PRF output. Actual result No PRF result is returned when using fingerprint verification. The PIN flow works. Related report I found WebKit bug #314934, which reports missing PRF results with a YubiKey C Bio in Safari. The reporter observed successful authentication but a null PRF output. Could AuthenticationServices be affected by a similar issue? Is there a known limitation or workaround for PRF evaluation with YubiKey Bio fingerprint verification?

I’m looking for technical clarification on how the standalone Apple Passwords app protects credentials on iOS 26 and iOS 27, specifically when a device is locked after its first unlock since boot (AFU). Apple’s Platform Security documentation identifies Safari website passwords as using the When Unlocked Keychain protection class: https://support.apple.com/guide/security/secb0694df1a/web However, it is unclear whether this documentation also describes the implementation of the newer standalone Passwords app. Keychain accessibility classes Does the Passwords app continue to store website and application passwords using kSecAttrAccessibleWhenUnlocked or an equivalent, more restrictive class? Do passkeys, TOTP verification-code secrets, and any intermediate keys necessary to decrypt stored credentials receive the same protection? Locked-AFU protection When an iPhone has been unlocked once since boot and subsequently locked again, are the cryptographic keys required to retrieve saved website passwords inaccessible until the user unlocks the device again? Specifically, does the When Unlocked class enforce this restriction cryptographically, or could a process with elevated operating-system privileges retrieve the protected material while the device remains locked? Full-filesystem and Keychain extraction Assuming an authorized forensic examiner obtains a full-filesystem extraction or privileged operating-system execution on a device that remains locked in AFU, but does not know the device passcode: Does filesystem access alone expose usable plaintext credentials stored in Apple Passwords? Are additional cryptographic keys or authentication steps required? What security guarantees remain for When Unlocked Keychain items under these conditions? I’m not requesting information about undisclosed vulnerabilities or specific forensic-tool exploits. I’m interested in the documented behavior and security boundaries of Apple’s Keychain architecture. Independent verification Are there any published technical assessments, research papers, forensic experiments, or Apple security documents that verify the actual accessibility classes used by the Passwords app on iOS 26/27? For context, a 2026 independent security assessment of Proton Pass identified its use of kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly for sensitive Keychain material as a defense-in-depth weakness and recommended kSecAttrAccessibleWhenUnlockedThisDeviceOnly. I’m trying to understand whether Apple’s native Passwords app provides a stronger cryptographic boundary against locked-AFU extraction, rather than merely a different user-interface authentication requirement. Any clarification from an Apple engineer or references to authoritative technical documentation would be greatly appreciated.

For macOS 26.7.1 (25G241), Xcode 27.0 (27A266a), and macOS SDK 27.0, we request the supported, exact Info.plist schema for NSDataAccessSecurityPolicy: its value type, literal key names and nesting, item types, and identity-selector grammar. Can the policy allow only the owning process signed with a specific Team ID and signing identifier, without allowing all applications signed by that Team? Are cdhash or designated-requirement selectors supported, and how do process and installer/package identities differ? Please clarify the relationship to user consent and Full Disk Access exceptions, and confirm whether this configuration is supported for the macOS build listed above. Please provide primary documentation or an authoritative schema, rather than a schema inferred from NSUpdateSecurityPolicy.

I’m designing a dedicated local PostgreSQL service account on macOS 26.3.1. No account has been created. Design requirements: no usable human password credential, no ordinary interactive login, shell /usr/bin/false, home /var/empty, no SSH credential, and no admin/wheel membership or Secure Token/FileVault volume-owner role. Any eventual service execution would be separately controlled. These are desired properties, not claims about established macOS behavior. I’m seeking a supported provisioning and verification procedure. Direct disabled creation: What supported Apple API/tool and attribute representation can create a local service account directly in a DisabledUser state? Can this be established during initial creation, without an externally available enabled password-authenticating intermediate state? Credential absence: Can creation occur without ever assigning or storing a usable human password credential or equivalent authentication secret? Please distinguish no password, an empty password, an unknown/generated password, disabled password authentication, and a disabled account. An empty password is unacceptable for this design. DisabledUser scope: What authentication paths does it prevent on macOS 26.3.1—password authentication, GUI/console login, SSH password authentication, and other Open Directory-backed authentication? How does this differ from system-controlled process execution under the UID, including launchd execution using UserName/GroupName? Nonauthenticating verification: What supported read-only attributes, policies, or APIs establish that the account is disabled and lacks a usable password credential, without attempting authentication or exposing hashes/secrets? Does inspecting the disabled marker establish only account state, or also credential absence? Secondary clarification: Is pwpolicy disableuser still recommended for local accounts? Is DisabledTags;SecureToken relevant only to token issuance, and can a controlled daemon run under a disabled UID without enabling human authentication? Source basis APPLE_DOCUMENTED: AuthenticationAuthority documentation identifies DisabledUser as indicating a disabled account. APPLE_DOCUMENTED: ODNode documentation provides record creation with attributes; the reviewed material does not establish the requested creation-time guarantee. LOCAL_MANUAL_DOCUMENTED: The installed pwpolicy(8) describes disableuser; its complete current authentication-path scope remains unresolved. APPLE_DOCUMENTED: Secure/bootstrap-token guidance discusses token issuance separately from account authentication. APPLE_DOCUMENTED, ARCHIVED: Daemon guidance describes selecting service identities through launch configuration. Not yet established: a safe credential-free creation sequence, the state of every intermediate step, the complete disabling scope, and sufficient nonauthenticating verification. A create-then-disable sequence would not meet the requirements unless every intermediate authentication state is characterized.

Our app signs users up through ASWebAuthenticationSession (not ephemeral). The sign-up page is a normal HTML form that posts to our server. When sign-up succeeds, the server redirects to our custom-scheme redirect_uri, which closes the session, as expected. When the user types a password and submits, iOS shows the "Save Password?" modal inside the session. From there, iOS 26 and iOS 27 behave differently: iOS 26.5: iOS waits. The form isn't sent until the user answers the modal. Then the request goes out, the redirect closes the session, and the password has been saved. iOS 27.0 and 27.2 beta 2: iOS doesn't wait. The form is sent right away, the redirect closes the session in under a second, and the modal disappears with it. The user never gets to tap Save. Things we checked: Same server, same page, same device, same app build. Only the iOS version changes the result. prefersEphemeralWebBrowserSession is off. Safari itself never waited on neither versions. The waiting only happened inside ASWebAuthenticationSession. Saving passwords still works on the device otherwise, and every test used a new account and password. Questions: Is the iOS 27 behaviour intended? If so, is there any supported way to let the user answer the sheet before the redirect closes the session? If it's a bug, is it tracked somewhere? The only fix we've found is to show an extra page after sign-up and only redirect from there, which adds a step for every user. We'd rather not ship that if the iOS 26 behaviour is coming back.

Why are we doing this nonsense? We want to be able to run builds in a sandbox such that they can only see the paths they are intended to depend on, to improve reproducibility. With builds with a very large number of dependencies, there's a very large number of paths added to the sandbox, and it breaks things inside libsandbox. Either it hits some sandbox length limit (sandbox-exec: pattern serialization length 66460 exceeds maximum (65535), Nix issue #4119, worked around: Nix PR 12570), or it hits an assert (this report; also Nix issue #2311). The other options for sandboxing on macOS are not viable; we acknowledge sandbox-exec and sandbox_init_with_parameters are deprecated; App Sandbox is inapplicable because we aren't an app. Our use case is closer to a browser, and all the browsers use libsandbox internally. We could possibly use SystemExtension or a particularly diabolical use of Virtualization.framework, but the former API requires notarization which is close to a no-go for our use case as open source software: it is nearly impossible to develop the software on one's own computer, and it would require us to ship a binary blob (and have the build processes to produce one in infrastructure completely dissimilar to what we use today); it also requires a bunch of engineering time. Today, we can pretend that code signing/notarization doesn't exist and that we are writing an old-school Unix daemon, because we are one. The latter is absolutely diabolical and hard to implement. See this saga about the bug we are facing: Nix issue #4119, Nix issue #2311, etc. What is going wrong I can't attach the file fail.sb as it is too large (you can view the failing test case at Lix's gerrit, CL 2870) and run this: $ sandbox-exec -D _GLOBAL_TMP_DIR=/tmp -f fail.sb /bin/sh Assertion failed: (diff &lt;= INSTR_JUMP_NE_MAX_LENGTH), function push_jne_instr, file serialize.c, line 240. zsh: abort sandbox-exec -D _GLOBAL_TMP_DIR=/tmp -f fail.sb /bin/sh Or a stacktrace: stacktrace.txt Credits Full credits to Jade Lovelace (Lix) for writing the above text and filing a bug. This is submitted under FB16964888

Hello! I develop a voicemail app service and I use MMI codes to let users enable/disable call forwarding to their voicemail number. For example, the app opens the Phone app with a code such as: **21*<phone number># This is expected behavior and is required for the service to work. However on iOS 27, those links are now blocked with a “Malicious link blocked” warning, saying that the link may forward incoming calls/messages. Is there any supported way for apps with a legitimate use case like this to request an exemption, or otherwise avoid this warning?

For an existing iOS generic-password Keychain item, what documented public API or query contract can establish that its returned SecAccessControl has no additional authentication, application-password, or operation-specific constraints? The item must remain WhenUnlockedThisDeviceOnly, in an exact access group and identity, and non-synchronizing. An unknown or unverified item must be refused without modifying, deleting, or replacing it. An attribute-only creation with no explicit access-control object can return a SecAccessControl when data and attributes are read. We observed this on an iOS 26.5 Simulator. The returned object compared different from a freshly created zero-flags object. We are not treating either that comparison or a successful no-UI read as proof of its complete constraints. The public interface we reviewed exposes creation and type identification; constraint inspection and serialization appear in private headers. Evaluating one operation also does not describe the item's complete policy. Is there a supported discriminator we have missed? If not, is there a documented creation-provenance and persistent-item-identity contract that establishes this property across relaunch, and what limitations apply to existing or recreated items? Please clarify the supported contract rather than private implementation details. We need to preserve refusal of unverified existing items while using the public Keychain APIs correctly.

In the process of updating several Apple devices to OS 27.0.1, I accidentally updated my main workstation from Sequoia to Golden Gate. I had intended to do this, but not this soon. Now I find that the Keychain Access App no longer takes my login password to unlock items. Unfortunately, the Passwords App does not allow me to see a number of things that are stored in the Keychain Access App: e.g. Secure Notes. But in this case the problem is an application password for an IRC client. I have no way of recovering my IRC account unless I can supply the password to Keychain Access.

Binary code is associated with the NSUserTrackingUsageDescription deleted at present, but in the revised App privacy will contain NSUserTrackingUsageDescription, I feel very confused, don't know should shouldn't solve.

I opened Apple Connect and was setting up a new app and when I go into App Groups, I see this! AltStore?? Cydia?? I didn't put those there, and Im the only one on my team. AltStore group com rileytestut AltStore group.com.rileytestut.AltStore.44K72272WR CY- group com cydia Extender group.CY-931DA672-818E-11E8-AED3-DB7934DE71C9.com.cydia.Extender CY- group lolwtf group.CY-36A1A27E-C8FB-11E6-AC51-975482641AE2.lolwtf