As of Xcode 15, Apple supports adding Privacy Manifests to SDKs. We develop an SDK that consists of several components (frameworks) for which we would like to add a Privacy Manifest. That works fine for our local builds, but we distribute our SDK via CocoaPods, which generates a single framework with the sources of all our components. This single framework currently does not have a Privacy Manifest. How would we be able to provide Privacy Manifests when using CocoaPods for distribution?

Hi, We're using SecKeyCreateRandomKey to generate a random key with access control kSecAttrAccessControl key set to `kSecAccessControlTouchIDAny' using below code SecAccessControlCreateWithFlags( kCFAllocatorDefault, kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly, kSecAccessControlTouchIDAny | kSecAccessControlPrivateKeyUsage, &error) Now, while accessing the key with below code, we're not seeing any biometric prompt on simulator where as the biometric prompt is shown in all physical devices and the key is returned only on successful authentication with FaceID (or) Touch ID. Can someone please help to understand why the behaviour is different in simulators NSDictionary *privateKeySearchQueryParam = @{ (id)kSecClass: (id)kSecClassKey, (id)kSecAttrKeyType: (id)kSecAttrKeyTypeEC, (id)kSecAttrLabel: keyName, (id)kSecReturnRef: @YES };

Hi guys, I need to use deterministic ECDSA (described in RFC 6979 article: https://www.rfc-editor.org/rfc/rfc6979) algorithm to calculate signature in iOS project. It is known that deterministic ECDSA is vulnerable to fault injection and side-channel attacks, so there is an updates for RFC 6979 described in following article (see section 4): https://www.ietf.org/archive/id/draft-mattsson-cfrg-det-sigs-with-noise-04.html#name-updates-to-rfc-6979-determi I tried to find any information related to deterministic ECDSA algorithm implementation and support in iOS ecosystem, but unfortunately found nothing Could you please provide me complete information whether the deterministic ECDSA with updates is implemented and provides by iOS API? Any guidance or information on this matter would be greatly appreciated. Looking forward for you soon. ))

The attestationObject contains the user's new public key to store and use for subsequent sign-ins. According to the description, in the passkey authorization success callback, the attestationObject contains the public key, can the client decode the attestationObject and obtain the public key? If possible, can you help provide the relevant API? public func authorizationController(controller: ASAuthorizationController, didCompleteWithAuthorization authorization: ASAuthorization) { switch authorization.credential { case let credentialRegistration as ASAuthorizationPlatformPublicKeyCredentialRegistration: // The attestationObject contains the user's new public key to store and use for subsequent sign-ins. credentialRegistration.attestationObject default: break } }

Request users' permissions to have their location displayed on a map; users must have the option to decline this request Require users to manually check-in each time they wish to have their location displayed on a map; there should be no option to enable automatic check-ins

I have in the past used TN2326 as reference to generate keys for our server that aren't self signed, instead signed by our certificate authority. The method in TN2326 is not working with the latest openssl, and honestly I don't understand these error messages enough to debug. If I add '-legacy' to the openssl command below - I do not get the error. However, clients using TLS are unable to connect to the server. In iOS, it reports a trust issue with the certificate, also pasted below. You can see below that I am using http3 with quic, so TLS 1.3 is important. I am running a python (3.10) script for the server, openssl I appreciate any help on this. % openssl pkcs12 -in server_192_168_0_187.p12 -nokeys -out server.crt Enter Import Password: Error outputting keys and certificates 4076BD4CF87F0000:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:crypto/evp/evp_fetch.c:341:Global default library context, Algorithm (RC2-40-CBC : 0), Properties () From the iOS client using the '-legacy' option: task will start, url: https://X.X.X.X:4433 Connection 3: default TLS Trust evaluation failed(-9807) Connection 3: TLS Trust encountered error 3:-9807 Connection 3: encountered error(3:-9807) [connection] nw_connection_copy_connected_local_endpoint_block_invoke [C4] Client called nw_connection_copy_connected_local_endpoint on unconnected nw_connection [connection] nw_connection_copy_connected_remote_endpoint_block_invoke [C4] Client called nw_connection_copy_connected_remote_endpoint on unconnected nw_connection [connection] nw_connection_copy_protocol_metadata_internal_block_invoke [C4] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection Task <BA37397D-B6F1-46C0-8D1C-BC112FC82956>.<2> HTTP load failed, 0/0 bytes (error code: -1202 [3:-9807]) protocols: ["h3"] Task <BA37397D-B6F1-46C0-8D1C-BC112FC82956>.<2> finished with error [-1202] Error Domain=NSURLErrorDomain Code=-1202 "The certificate for this server is invalid. You might be connecting to a server that is pretending to be “X.X.X.X” which could put your confidential information at risk." UserInfo={NSLocalizedRecoverySuggestion=Would you like to connect to the server anyway?, _kCFStreamErrorDomainKey=3, NSErrorPeerCertificateChainKey=( "<cert(0x108827800) s: X.X.X.X i: Company CA>" ), NSErrorClientCertificateStateKey=0, NSErrorFailingURLKey=https://X.X.X.X:4433/, NSErrorFailingURLStringKey=https://X.X.X.X:4433/, NSUnderlyingError=0x283385560 {Error Domain=kCFErrorDomainCFNetwork Code=-1202 "(null)" UserInfo={_kCFStreamPropertySSLClientCertificateState=0, kCFStreamPropertySSLPeerTrust=<SecTrustRef: 0x280cec1e0>, _kCFNetworkCFStreamSSLErrorOriginalValue=-9807, _kCFStreamErrorDomainKey=3, _kCFStreamErrorCodeKey=-9807, kCFStreamPropertySSLPeerCertificates=( "<cert(0x108827800) s: X.X.X.X i: Company CA>" )}}, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask <BA37397D-B6F1-46C0-8D1C-BC112FC82956>.<2>" ), _kCFStreamErrorCodeKey=-9807, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <BA37397D-B6F1-46C0-8D1C-BC112FC82956>.<2>, NSURLErrorFailingURLPeerTrustErrorKey=<SecTrustRef: 0x280cec1e0>, NSLocalizedDescription=The certificate for this server is invalid. You might be connecting to a server that is pretending to be “X.X.X.X” which could put your confidential information at risk.} task transport error NSURLErrorDomain / -1202

I'm really excited by the idea of the privacy manifests, and really all the work Apple is doing to keep users protected. I work on the Mozilla VPN, and Mozilla shares Apple's commitment to privacy. We use Adjust to determine referrals for new subscriptions. But because of our commitment to privacy: After a user subscribes, we never activate the Adjust SDK on future app runs. We proxy the Adjust network call through our app, and strip out most of the fields it was going to send to the Adjust server. We keep a small handful of fields that are necessary for attribution (and even publish the list of those fields). Further, we don't send the Adjust network request (which has been stripped down) directly to Adjust's servers, we proxy it through our own server first. This both keeps user IP addresses private, and allows us to further strip out payload values on the server (or stop sending data onto Adjust entirely) if ever needed. Ultimately, this means Adjust's future privacy manifest likely won't be accurate for our app, as we're significantly modifying the Adjust SDK behavior and data collection. Questions: Will we be able to note in Xcode that the listed privacy manifest doesn't apply in our case? If there are future plans to compare privacy manifests with app nutritional labels in the App Store Review process, is it possible to consider this use case in your planning? Thanks!

How to uniquely identify the device to prevent fraudulent activity in any financial Apps? since UUID also gets changed on every installation, is there any option to track the device like how it is done with IMEI number ? Note: Our App is targeted for normal Appstore users.

Hi, I have experienced undocumented changes in the behavior of SFAuthorizationPluginView and Authorization Plug-ins while testing our Auth Plugin under macOS Sonoma Beta 3 (latest seed as of today). Prerequisites: macOS Sonoma Beta 3 Settings > Lock Screen > Login window shows: List of Users Note: it is visible the login screen changed in behavior, this can be noticed even without the installation of any authorization plugin. There is now a default selected user with the password field always visible. Up until Ventura, a user had to be picked manually first to then open up their login password textfield. After logout I noticed that the order of delegate methods have changed. Previously, until macOS Ventura the order of methods seemed to be: displayView() --> viewForType() --> view.viewDidLoad() --> willActivateWithUser() --> firstResponder --> didActivate() where view is my custom NSViewController.view embedded in the SFAuthorizationPluginView. viewDidLoad is called because my implementation of viewForType returns view - which in turn should call loadView() based on documentation for NSViewController.view: If this property’s value is not already set when you access it, the view controller invokes the loadView() method. Now it seems that the order has changed: displayView() --> didActivate() --> firstResponder This means that viewForType(), willActivateWithUser() are not called. And then my console application crash log shows that the application crashed at firstResponder, probably because view.viewDidLoad() is not called for my view due to viewForType() not being called either. Has anyone met a similar issue? This really seems like an undocumented change. macOS Ventura 13.3, plugin built with XCode 14.3.1 -> our app works macOS Sonoma 14.0 Beta3, plugin built with XCode 14.3.1 -> our app does not work macOS Sonoma 14.0 Beta3, plugin built with XCode 15.0 Beta4 -> our app does not work P.S.: I do see methods new in macOS Sonoma appeared for NSViewController, like loadViewIfNeeded - but sadly these new methods have zero documentation attached. P.S #2: I have checked with a minimal repro example, and the order has indeed changed. When the view does not have to be loaded via an NSViewController, i can see the full new order: displayView() --> didActivate() --> firstResponder --> viewForType() --> willActivateWithUser() --> didActivate() (called twice??) --> firstResponder --> firstResponder This above order of calls is without a single user interaction, just logging out (or using security authorize -u system.login.console from the terminal)

I've just been looking at this list of APIs for which we will be soon be required to declare a "required reason" in the app's privacy manifest: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api One of the listed functions is stat(). The rationale seems to be that a malicious app can use stat to get the timestamps of files outside the app container, thereby "fingerprinting" the device. The allowed reasons that we can declare are : To get timestamps that are displayed to the user. To get timestamps of files that are within the app's container. To get timestamps of files that the user has granted access to. I am concerned that this does not include many of the legitimate non-timestamp uses of stat(). For example, it can be used simply to test if a file exists, or to test whether a path refers to a file or a directory, or to check if two paths refer to the same file (e.g. via different symlinks), or to get the size of a file. Some of these things can be achieved in other ways; for example, I can check if a file exists by trying to open() it and checking for an error, and I can get the file size by opening it and calling lseek(SEEK_END). Maybe I can check if two paths are equivalent by using readlink() to form canonical paths for both and comparing them. But I bet there are other things that can't be done. I could probably fix all of my code to not call stat() for non-timestamp reasons in a few hours. It would be more difficult to fix the various open-source libraries that I use. What do you think we should all be doing?: "File a bug" asking for an additional reason for using stat(), i.e. to get non-timestamp information about files in the app's container. Deliberately mis-read allowed reason C617.1, "to access the timestamps of files inside the app container", as " to access the timestamps and other metadata of files inside the app container", and declare that in the privacy manifest. Change code to not call stat(). Any other suggestions? P.S. I guess that libc++ std::filesystem calls stat(). What is the status of using that? The std::filesystem functions that access file timestamps are not listed on the page linked above. If I call std::exists() to check if a file exists, and assuming that is implemented using stat(), will that trigger the new filter?

I understand that during the CTAP process with a Passkey, a key agreement takes place when scanning the QR code and sending Bluetooth advertisements. Is the Diffie-Hellman algorithm used for the key agreement during this process?

I have made my own public key infrastructure that my app uses and I want to support certificate revocation on it. From what I have gather through documentation and forum posts, there is not too much support for that. I have seen mentions of using OCSP stapling, which is probably the direction I want to take. However, I did not see anything showing how to use it. Is it even possible to do so with a custom OCSP authority? If so, how would it be enabled/configured? Thanks

I've set up a privacy manifest file in my SDK, which I'm developing in Xcode 15 beta 4, and built an xcframework. I verified that PrivacyInfo.xcprivacy exists in the xcframework. In state verifying the existence of PrivacyInfo.xcprivacy in xcframework, I incorporated the built xcframework into a test app for operation check, created an archive, and outputted a report from "Generate Privacy Report". Despite having a privacy manifest file set up in the test app, when I checked the report, I was able to confirm the contents of the test app's privacy manifest file but not the contents of the privacy manifest file I configured in the SDK. I understand that the SDK's privacy manifest file is merged with and outputted from the privacy manifest file of a project that incorporates the SDK. Am I mistaken?

For an ad SDK that shows web ads in WKWebView, if it does not know what tracking pixels will be in the web ads, is it still responsible for reporting Tracking Domains in the Privacy Manifest? If yes, how?

Hi, Is it possible to use top level domain registered passkey(example.com) to authenticate against the subdomains (my.example.com)?

Is it possible to get permission to make an app unremovable? perhaps not permanently, but so the user e.g. can only remove the app after a month from it being requested? It might sound a bit obscure, but it is in relation to helping people with gambling addiction.

I am working on an iOS application that deals with scanning SmartCards at entry points to see who is entering a facility. We are currently using proprietary smartcard readers from a company and their SDK to directly access the reader and issue APDU commands to get the smartcard information, such as certificate, expiration date, etc. The plan is to be able to have a person insert a smartcard, the system recognize it, validate the expiration date and cert chain, record who it is and then tell the user to pull the card and move on. This process needs to be fast. PIN entries are not required. We are trying to move away from the 3rd party SDK and proprietary card reader to be able to use any CCID compliant reader and CryptoTokenKit from Apple. Information on this seems to be very limited from what searching. I've started with some simple code (not complete): var card : TKSmartCard? = nil let card = slot?.makeSmartCard() if (card != nil && card?.isValid != nil) { card?.beginSession(reply: { something, error in let nistEndpoint : [UInt8] = [0x00, 0xA4, 0x04, 0x00, 0x0B, 0xA0, 0x00, 0x00, 0x03, 0x08, 0x00, 0x00, 0x10, 0x00, 0x01, 0x00, 0x00] let nistRequest = Data.init(bytes: nistEndpoint) card?.transmit(nistRequest, reply: { data, error in if error == nil { // Do stuff }else { // log the error } }) } When I run this on an iPad with a USB connected card reader, I am seeing the card reader, getting its name, seeing that a card is in the reader and the 'card?.isValid' is coming back. The card?.transmit is throwing an error however and returns TKError.Code.tokenNotFound (-7). Questions: I see that the CryptoTokenKit API requires the entitlement of com.apple.security.smartcard, but no where during the creation of a provisioning profile process in my dev account give me the option to add that specific entitlement. Is this something that has be specially assigned by Apple? Is what I'm trying to accomplish possible using CryptoTokenKit on an iOS device? Does anyone know of any tutorials or examples of this? Thank you in advance.

In the Required Reason API doc, the UserDefaults section defines NSPrivacyAccessedAPITypeReasons CA92.1: Declare this reason to access user defaults to read and write information that is only accessible to the app itself. This reason does not permit reading information that was written by other apps or the system, or writing information that can be accessed by other apps. If I store a user generated string in UserDefaults, later on fetch it within the same app, send it to my backend component, and lastly my backend component share the string with 3rd party developers, do I still fall into the CA92.1 category? In other words, do I need to submit an approval request for this kind of usage? My understanding is this usage still falls into CA92.1 because it does not access device signals for fingerprinting purposes, but I am not sure. Please advice. Thanks!

Hello, we need a fix for https://nvd.nist.gov/vuln/detail/CVE-2023-38408. How can we fix it? Is there a plan to release an OS update? Thanks

Our app creates ECDSA signatures by calling SecKeyCreateSignature() using a private key that is protected by the secure enclave. On iOS 17 beta our backend rejects some of those signatures as invalid while on previous iOS versions everything is fine. Did anything change in the security framework in iOS 17 that I missed in the release notes or the API diffs?