Closed jeff-dialpad closed 4 months ago
wangxiaoms
commented
5 months ago Hi can you provide the MAM logs https://learn.microsoft.com/en-us/mem/intune/developer/app-sdk-ios-appendix#how-can-i-troubleshoot-my-app
Also are you able to provide the source code for the siri extension and sample app? My email wangxiao@microsoft.com if needed.
jeff-dialpad
commented
5 months ago Thank you @wangxiaoms
Issue A: Intune not blocking Siri Intents
I have submitted diagnostic logs for the issue described above, with Reference ID F17370
Sometime during the minute starting at 2024-05-17T20:44:10.189Z a call is initiated via Siri. We expect the library to block this interaction because we have a single-identity application, and we can observe (in both in the app and Siri extension targets) that the enrolled user's policy specifies areSiriIntentsAllowed == false. However the INStartCallIntent was handled normally by the app and a VoIP call initiated.
To further demonstrate this issue I have prepared a sample app as requested. I will forward this to the email provided. The sample app doesn't actually make VOIP calls, but just updates the interface to indicate when the Siri intent was handled
First, below is a video of initiating a call from Siri when there is no MAM-enrolled user. The intent is handled as expected:
Key moments 0:00 - User tells Siri "Make an intune-sample call to Alice" (Audio not captured by recording) 0:04: App is opened we can see the make call intent was handled by app.
Below is a video showing a user invoking Siri to make a call when the enrolled user's policy specifies areSiriIntentsAllowed == false. We expect the library to handle blocking this interaction, but rather it is allowed to proceed. Again, we can inspect the policy both in the app and extension targets and observe that areSiriIntentsAllowed == false.
Key moments 0:01 - User tells Siri "Make an intune-sample call to Alice" (audio not captured by recording) 0:08 - We can see the INStartCallIntent was handled by app (Call record added to list). We rather expect the library to handle disallowing this Siri Intent.
I have also submitted logs for this run of the sample app, and the reference ID is 675138. The attempt to start the call which should be disallowed happens sometime in the minute following 2024-05-17T15:37:04.070Z.
Issue B: iOS 16 Siri AppIntents Guidance
This was raised at #428 but closed as a duplicate of #427, so restating here. This concerns not extension based Siri interactions but rather the newer iOS-16+ AppIntents:
For custom AppIntents, is it possible to block Siri from recognizing registered shortcut phrases?
We have some Siri functionality implemented with the iOS 16-style custom AppIntents. In the app participation features documentation here it is noted that:
In iOS 16 and above, a new App Intents system framework is available for creating Swift App Intents. Apps that implement an App Intent should first check the areSiriIntentsAllowed property on the IntuneMAMPolicy object for the user.
Is there is any documentation or advice available on how to accomplish this? The issue is that the shortcut phrases are declared statically in a @AppShortcutBuilder, which does not allow us to run any dynamic checks, so the shortcut phrases are always registered with the system. Similarly any parameters to for the intent are defined using IntentParameter @Parameter property wrappers, requiring us to statically hook up those parameters.
Our first chance to check areSiriIntentsAllowed appears to be in the perform() function of the AppIntent. We can manually block the action from executing at this stage if needed.
Therefore we can block the action and provide an error communication only after iOS has reacted to a user invoking a shortcut phrase and gathered any parameters from the user. In the iOS-controlled parameter gathering phase, there is no indication that we will be blocking their action.
To illustrate, the sample app also has an iOS16-style Siri AppIntent for setting status.
First, below, is a video for no enrolled user. In this case the AppIntent is serviced normally as expected:
Key Moments 0:01 - User invokes set status AppIntent with "Set my intune-sample status" (audio not captured by recording) 0:05 - Siri asks the user for the value of the Status parameter. 0:06 - User responds "Working from home" (audio not captured by recording) 0:10 - The AppIntent is handled, Siri confirms it, and the UI shows the new status, as expected since there is no enrolled user and Siri Intents are allowed.
In the next video an enrolled user having areSiriIntentsAllowed == false invokes the Set Status AppIntent. Because we don't expect the library to handle blocking this intent, we are instead programatically blocking the intent from performing its function, and providing some feedback to that effect. However as outlined above, my question is whether there is a known way to block the system from recognizing these Siri shortcuts entirely, because while iOS is gathering the "status" parameter, there is no indication that the action will be blocked.
Key Moments: 0:01 - User invokes set status AppIntent with "Set my intune-sample status" (audio not captured by recording) 0:05 - Siri asks the user for the value of the Status parameter. 0:06 - User responds "Working from home" (audio not captured by recording) 0:10 - Siri provides feedback (coded in the AppIntent) that action will not go forward, because the AppIntent has now had an opportunity to check the policy. We see that the "Status" has not been updated in the UI.
Thank you very much!
wangxiaoms
commented
5 months ago Hi @jeff-dialpad thanks for the detailed information, I'm checking this with the team.
wangxiaoms
commented
4 months ago Hi @jeff-dialpad The comment for the areSiriIntentsAllowed method is incorrect. We will fix the comment by removing the part that states single identities don't need to check this method. In the meantime, customer can unblock themselves by adding code to check areSiriIntentsAllowed and block the action if appropriate.
Describe the bug: SDK is not blocking Siri intents.
We have a single identity application. According to the header IntuneMAMPolicy.h:
// TRUE if the management policy allows applications to use Siri intents. // Multi-Identitity applications should check this policy and if FALSE should block Siri intents. // For single identity applications, policy enforcement will be entirely handled by the SDK. @property (readonly) BOOL areSiriIntentsAllowed;
We use INStartCallIntents in an extension. We are linking the Intune and MSAL frameworks in the extension, and have configured the extension's Info.plist with the configurator tool. When I query the policy for the enrolled user in both the app and in the extension I can see that areSiriIntentsAllowed == false.
Therefore I expect not to be able to make a VoIP call via Siri when enrolled. However I see no impact when this policy is applied, and am able to start the call with Siri.
To Reproduce
Invoke a Siri phrase to start a VoIP call. Observe that the Siri interaction is allowed.
Expected behavior: Since we have a single-identity application, and the policy indicates areSiriIntentsAllowed == false, the Intune SDK should block the action.
Smartphone (please complete the following information):
Intune App SDK for iOS (please complete the following information):
What version of the Intune SDK are you using? Are you using the latest version? Latest version, 19.3.1
What platform is your app based in (native, Xamarin based, Cordova, etc)? Native iOS
For errors during build, does the app build without Intune SDK integration? N/A
For errors post build, does the app launch without being Intune SDK integrated? N/A
Do you see a trend with it only being reproduced on a specific device? No