Hi Apple Team and Community,
We encountered a sudden and widespread failure related to the App Attest service on Friday, July 25, starting at around 9:22 AM UTC.
After an extended investigation, our network engineers noted that the size of the attestation objects received from the attestKey call grew in size notably starting at that time. As a result, our firewall began blocking the requests from our app made to our servers with the Base64-encoded attestation objects in the payload, as these requests began triggering our firewall's max request length rule.
Could Apple engineers please confirm whether there was any change rolled out by Apple at or around that time that would cause the attestation object size to increase?
Can anyone else confirm seeing this?
Any insights from Apple or others would be appreciated to ensure continued stability.
Thanks!
General
RSS for tagPrioritize user privacy and data security in your app. Discuss best practices for data handling, user consent, and security measures to protect user information.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
In one of my apps I would like to find out if users have their device set up to authenticate with their Apple Watch.
According to the documentation (https://developer.apple.com/documentation/localauthentication/lapolicy/deviceownerauthenticationwithcompanion) this would be done by evaluating the LAPolicy like this:
var error: NSError?
var canEvaluateCompanion = false
if #available(iOS 18.0, *) {
canEvaluateCompanion = context.canEvaluatePolicy(.deviceOwnerAuthenticationWithCompanion, error: &error)
}
But when I run this on my iPhone 16 Pro (iOS 18.5) with a paired Apple Watch SE 2nd Gen (watchOS 11.5) it always returns false and the error is -1000 "No companion device available". But authentication with my watch is definitely enabled, because I regularly unlock my phone with the watch.
Other evaluations of using biometrics just works as expected.
Anything that I am missing?
In some crashlog files, there are additional pieces of information related to codesigning.
I can understand what most of themcorresponds to (ID, TeamID, Flags, Validation Category). But there is one I have some doubt about: Trust Level.
As far as I can tell (or at least what Google and other search engines say), this is an unsigned 32 bit integer that defines the trust level with -1 being untrusted, 0, being basically an Apple executable and other potential bigger values corresponding to App Store binaries, Developer ID signature, etc.
Yet, I'm not able to find a corresponding detailed documentation about this on Apple's developer website.
I also had a look at the LightweightCodeRequirements "include" file and there does not seem to be such a field available.
[Q] Is there any official documentation listing the different values for this trust level value and providing a clear description of what it corresponds to?
Cannot find developer mode in iPhone 16. Please help me resolve this
Topic:
Privacy & Security
SubTopic:
General
Hello, I am currently researching to develop an application where I want to apply the MacOS updates without the password prompt shown to the users.
I did some research on this and understand that an MDM solution can apply these patches without user intervention.
Are there any other ways we can achieve this? Any leads are much appreciated.
I have been implementing an sdk for authenticating a user. I have noticed that on iOS 18.5, whether using SFSafariViewController, or the sdk (built on ASWebAuthenticationSession), password autofill does not work. I have confirmed it works on a different device running iOS 18.0.1. Are there any work arounds for this at this time? Specifically for ASWebAuthenticationSession?
Topic:
Privacy & Security
SubTopic:
General
Tags:
Authentication Services
Passkeys in iCloud Keychain
Recently, we received an user enquiry regarding the inability to perform bookings for the app.
After investigation, we found that the issue appears to be caused by the failure of the Apple DeviceCheck service.
Based on our checks, approximately 0.01% of requests fail each day (e.g., on 26 June: 6 failures out of 44,544 requests) when using Apple DeviceCheck.
Could you please assist in raising the following enquiries with Apple Support?
What is the typical failure rate of Apple DeviceCheck? Are there any reliability metrics or benchmarks for its performance?
How can the failures be prevented, or is there a recommended retry mechanism to handle such failures?
Does the iOS version affect the performance or reliability of Apple DeviceCheck? Are there known issues or limitations with specific iOS versions?
How long does the token remain valid, and when should a new one be retrieved?
Does using a jailbroken device affect the functionality of Apple DeviceCheck?
Hello, I want to access the Docker socket API from inside the macOS App Sandbox. The method queries the API using curl with --unix-socket. However, the Sandbox blocks the request, as shown by the log: curl(22299) deny(1) network-outbound /Users/user/.docker/run/docker.sock Outgoing network traffic is generally allowed, but access to the Docker Unix socket is denied.
Here’s the code I’m using:
private func executeDockerAPI() -> String {
let process = Process()
let pipe = Pipe()
process.executableURL = URL(fileURLWithPath: "/usr/bin/curl")
process.arguments = [
"--unix-socket", "/Users/user/.docker/run/docker.sock",
"http://127.0.0.1/containers/json"
]
process.standardOutput = pipe
process.standardError = pipe
do {
try process.run()
process.waitUntilExit()
let data = pipe.fileHandleForReading.readDataToEndOfFile()
if let output = String(data: data, encoding: .utf8) {
return output
} else {
return "Error while decoding"
}
} catch {
return "Error running command: \(error.localizedDescription)"
}
}
Is there any entitlement or sandbox configuration I’m missing to allow access to /Users/user/.docker/run/docker.sock from inside the sandbox?
Problem Description:
In our App, When we launch the web login part using ASWebAuthentication + Universal Links with callback scheme as "https", we are not receiving callback.
Note:
We are using "SwiftUIWebAuthentication" Swift Package Manager to display page in ASWebAuth.
But when we use custom url scheme instead of Universal link, app able to receive call back every time.
We use ".onOpenURL" to receive universal link callback scheme.
For context, my company develops a data loss prevention (DLP) product. Part of our functionality is the ability to detect sensitive data being pasted into a web browser or cloud-based app.
The AppKit release notes for April 2025 document an upcoming “macOS pasteboard privacy” feature, which will presumably ship in macOS 26. Using the user default setting “EnablePasteboardPrivacyDeveloperPreview” documented in the release notes, I tested our agent under macOS 15.5, and encountered a modal alert reading " is trying to access the pasteboard" almost immediately, when the program reads the General pasteboard to scan its contents.
Since our product is aimed at enterprise customers (and not individual Mac users), I believed Apple would implement a privacy control setting for this new feature. This would allow our customers to push a configuration profile via MDM, with the “Paste from Other Apps” setting for our application preset to “Allow”, so that they can install our product on their endpoints without manual intervention.
Unfortunately, as of macOS 26 beta 4 (25A5316i), there does not seem to be any such setting documented under Device Management — for example in PrivacyPreferencesPolicyControl.Services, which lists a number of similar settings. Without such a setting available, a valuable function of our product will be effectively crippled when macOS 26 is released.
Is there such a setting (that I've overlooked)? If not, allow me to urge Apple to find the resources to implement one, so that our customers can preset “Paste from Other Apps” to “Allow” for our application.
Topic:
Privacy & Security
SubTopic:
General
Tags:
Privacy
AppKit
Endpoint Security
Device Management
General:
Forums subtopic: Privacy & Security > General
Forums tag: App Sandbox
App Sandbox documentation
App Sandbox Design Guide documentation — This is no longer available from Apple. There’s still some info in there that isn’t covered by the current docs but, with the latest updates, it’s pretty minimal (r. 110052019). Still, if you’re curious, you can consult an old copy [1].
App Sandbox Temporary Exception Entitlements archived documentation — To better understand the role of temporary exception entitlements, see this post.
Embedding a command-line tool in a sandboxed app documentation
Discovering and diagnosing App Sandbox violations (replaces the Viewing Sandbox Violation Reports forums post)
Resolving App Sandbox Inheritance Problems forums post
The Case for Sandboxing a Directly Distributed App forums post
Implementing Script Attachment in a Sandboxed App forums post
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] For example, this one archived by the Wayback Machine.
Hi Team,
How can we fetch the macOS password requirement(for setting a new password) that are inforce during login for users? Is there a way to get this info in swift programming?
Hi everyone,
I’m working an Objective-C lib that performs Keychain operations, such as generating cryptographic keys and signing data. The lib will be used by my team in a Java program for macOS via JNI.
When working with the traditional file-based Keychain (i.e., without access control flags), everything works smoothly, no issues at all.
However, as soon as I try to generate a key using access control flags SecAccessControlCreateWithFlags, the Data Protection Keychain returns error -34018 (errSecMissingEntitlement) during SecKeyCreateRandomKey. This behavior is expected.
To address this, I attempted to codesign my native dynamic library (.dylib) with an entitlement plist specifying various combinations of:
keychain-access-groups
com.apple.security.keychain
etc.
with:
My Apple Development certificate
Developer ID Application certificate
Apple Distribution certificate
None of these combinations made a difference, the error persists.
I’d love to clarify:
Is it supported to access Data Protection Keychain / Secure Enclave Keys in this type of use case?
If so, what exact entitlements does macOS expect when calling SecKeyCreateRandomKey from a native library?
I’d really appreciate any guidance or clarification. Thanks in advance!
Best regards,
Neil
Hi all,
I’m building a macOS-native C++ trading bot, compiled via Xcode. It sends REST API requests to a crypto exchange (Bitvavo) that require HMAC-SHA256 signatures using a pre-sign string (timestamp + method + path + body) and an API secret.
Here’s the issue:
• The exact same pre-sign string and API secret produce valid responses when signed using Python (hmac.new(secret, msg, hashlib.sha256)),
• But when I generate the HMAC signature using C++ (HMAC(EVP_sha256, ...) via OpenSSL), the exchange returns an invalid signature error.
Environment:
• Xcode 15.3 / macOS 14.x
• OpenSSL installed via Homebrew
• HMAC test vectors match Python’s output for basic strings (so HMAC lib seems correct)
Yet when using the real API keys and dynamic timestamped messages, something differs enough to break verification — possibly due to UTF-8 encoding, memory alignment, or newline handling differences in the Xcode C++ runtime?
Has anyone experienced subtle differences between Python and C++ HMAC-SHA256 behavior when compiled in Xcode?
I’ve published a GitHub repo for reproducibility:
🔗 https://github.com/vanBaardewijk/bitvavo-cpp-signature-test
Thanks in advance for any suggestions or insights.
Sascha
We have been having very high response times in device check device validation service (https://developer.apple.com/documentation/devicecheck/accessing-and-modifying-per-device-data#Create-the-payload-for-a-device-validation-request) since 17 July at 19:10hs GMT. The service information page says the service was running in green status but that isn't the case and we currenly have stop consuming it.
Is it being looked at? Are you aware of this issue? Can you give us an estimate of when it should be working correctly?
I am developing a macOS application (targeting macOS 13 and later) that is non-sandboxed and needs to install and trust a root certificate by adding it to the System keychain programmatically.
I’m fine with prompting the user for admin privileges or password, if needed.
So far, I have attempted to execute the following command programmatically from both:
A user-level process
A root-level process
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /path/to/cert.pem
While the certificate does get installed, it does not appear as trusted in the Keychain Access app.
One more point:
The app is not distributed via MDM.
App will be distributed out side the app store.
Questions:
What is the correct way to programmatically install and trust a root certificate in the System keychain?
Does this require additional entitlements, signing, or profile configurations?
Is it possible outside of MDM management?
Any guidance or working samples would be greatly appreciated.
I am new to swift development, and it's possible that I'm missing something fundamental/obvious. If so, I apologize in advance. My team is developing an application for iPadOS using SwiftUI, and I'm trying to accomplish something similar to what the original inquirer is asking for in this thread: https://developer.apple.com/forums/thread/725152. The only difference is that I'm trying to use a PIV smart card to achieve authentication to a server rather than digitally sign a document.
Unfortunately, I'm getting stuck when attempting to run the list() function provided in the accepted answer to the post mentioned above. When attempting to call SecItemCopyMatching(), I'm getting a -34018 missing entitlement error. I've attempted to add the com.apple.token to my app's keychain-access-groups entitlements, but this does not resolve the issue. I have checked the entitlements in my built app, per the recommendation in the troubleshooting guide here: https://developer.apple.com/forums/thread/114456. The entitlement for com.apple.token is indeed present in the plist. Based on other documentation I've read, however, it seems that the explicit declaration of com.apple.token should not even be required in the entitlements.
Is there something obvious that I'm missing here that would prevent my app from accessing the token access group?
I'm developing an Authorization Plug-In and have stumbled upon a concerning behavior regarding credential caching that may have security implications.
Consider this scenario: I'm working on a Mac without admin privileges, and I need to temporarily disable the Firewall for some testing. An administrator physically comes to my machine, inputs their credentials to disable the Firewall, and then leaves.
What follows is that, for a short period after this action, the administrator's credentials remain cached in Authorization Services. During this window, I can perform some additional privileged operations without any re-authentication. For example, I can open Activity Monitor and send SIGKILL signals to arbitrary privileged processes (!!).
From what I could gather, this happens because system.preferences.network shares cached credentials with other authorization rights. Even more concerning, even when I explicitly modify the authorization database to prevent credential sharing for this specific right, the behavior persists!
I suspect the issue relates to the underlying shared authentication rules (such as authenticate-admin-30, which com.apple.activitymonitor.kill uses), but I've been unable to modify these rules to test this theory.
From my understanding, the most concerning aspect is that even if all system Authorization Rights were configured to not share credentials, third-party applications could still create proprietary rights that might end up sharing credentials anyway.
From my Auth Plug-In, I've tried unsetting the kAuthorizationEnvironmentShared context value (even though the documentation in AuthorizationTags.h tells me that the value is ignored), and looking for ways to override the timeout for shared credentials, both without success.
Finally, I'm looking to answer some questions that have been raised:
I understand that this credential sharing is a feature, but isn't the behavior I described actually a security vulnerability? I worry that other (potentially more dangerous) operations may be able to exploit this.
Is there a recommended way to prevent privileged credentials from being reused across arbitrary authorization rights if the original process does not destroy the auth reference?
Are there any options from within an Authorization Plug-In to ensure more strict authentication boundaries?
What exactly is the authorization "session" mentioned in /System/Library/Security/authorization.plist? Does this concept imply that System Settings.app and Activity Monitor.app share the same session in my previous example?
This post ended up being quite long, but unfortunately, documentation on the subject seems incredibly scarce. For reference, the little information I could find came from:
QA 1277
The Credentials Cache and the Authentication Dialog
Comments on /System/Library/Security/authorization.plist
WebAuthn Level 3 § 5.1.3 Step 22 Item 4 states the steps a user agent MUST follow when "conditional" mediation is used in conjunction with required user verification:
Let userVerification be the effective user verification requirement for credential creation, a Boolean value, as follows. If pkOptions.authenticatorSelection.userVerification
is set to required
If options.mediation is set to conditional and user verification cannot be collected during the ceremony, throw a ConstraintError DOMException.
Let userVerification be true.
On my iPhone 15 Pro Max running iOS 18.5, Safari + Passwords does not exhibit this behavior; instead an error is not reported and user verification is not performed (i.e., the UV bit is 0). Per the spec this results in a registration ceremony failure on the server which is made all the more "annoying" since the credential was created in Passwords forcing a user to then delete the credential. :
If the Relying Party requires user verification for this registration, verify that the UV bit of the flags in authData is set.
In contrast when I use Google Password Manager + Chrome on a Samsung Galaxy S24 running Android 15, user verification is enforced and the UV bit is 1.
Either the UV bit should be 1 after enforcing user verification or an error should be thrown since user verification cannot be performed.
WebAuthn Level 3 § 6.3.2 Step 2 states the authenticator must :
Check if at least one of the specified combinations of PublicKeyCredentialType and cryptographic parameters in credTypesAndPubKeyAlgs is supported. If not, return an error code equivalent to "NotSupportedError" and terminate the operation.
On my iPhone 15 Pro Max running iOS 18.5, Safari + Passwords does not exhibit this behavior; instead an error is not reported and an ES256 credential is created when an RP passes a non-empty sequence that does not contain {"type":"public-key","alg":-7} (e.g., [{"type":"public-key","alg":-8}]).
When I use Chromium 138.0.7204.92 on my laptop running Arch Linux in conjunction with the Passwords app (connected via the "hybrid" protocol), a credential is not created and instead an error is reported per the spec.