usnistgov/macos_security
1
0
Fork 0
mirror of https://github.com/usnistgov/macos_security.git synced 2026-02-03 14:03:24 +00:00
Code Issues 21 Actions Packages Projects Releases Wiki Activity

system_settings_siri_listen_disable not working as intended #56

New Issue
Closed
opened 2026-01-19 18:29:04 +00:00 by michael · 2 comments
michael commented 2026-01-19 18:29:04 +00:00
Owner
Copy Link

Originally created by @dshepp32 on GitHub.

Originally assigned to: @robertgendler on GitHub.

When setting system_settings_siri_listen_disable via configuration profile with the following: com.apple.Siri: VoiceTriggerUserEnabled: false, one can still enable "Hey Siri", unless com.apple.applicationaccess has allowAssistant set to False.

Tested on macOS 15.4.1. If I only set com.apple.Siri: VoiceTriggerUserEnabled: false, I am still able to enable Siri and configure Listen For. However, Listen for still shows off. But you can say "Hey Siri" and she will answer. If I also set com.apple.applicationaccess: allowAssistant: False, I cannot enable Siri nor Listen For. That doesn't help in an org that might want Siri to be on but not be listening.

Caveat to this: If I enable Listen For and then disable allowAssistant, the Mac will randomly hit you with a nag screen that says You do not have permission to use Siri. This pops up when the Mac thinks it hears Hey Siri or at random other times. Have to re-enable allowAssistant to turn off Siri and then disable it again to get proper behavior.

Originally created by @dshepp32 on GitHub. Originally assigned to: @robertgendler on GitHub. When setting system_settings_siri_listen_disable via configuration profile with the following: com.apple.Siri: VoiceTriggerUserEnabled: false, one can still enable "Hey Siri", unless com.apple.applicationaccess has allowAssistant set to False. Tested on macOS 15.4.1. If I only set com.apple.Siri: VoiceTriggerUserEnabled: false, I am still able to enable Siri and configure Listen For. However, Listen for still shows off. But you can say "Hey Siri" and she will answer. If I also set com.apple.applicationaccess: allowAssistant: False, I cannot enable Siri nor Listen For. That doesn't help in an org that might want Siri to be on but not be listening. Caveat to this: If I enable Listen For and then disable allowAssistant, the Mac will randomly hit you with a nag screen that says You do not have permission to use Siri. This pops up when the Mac thinks it hears Hey Siri or at random other times. Have to re-enable allowAssistant to turn off Siri and then disable it again to get proper behavior.
michael commented 2026-01-19 18:29:05 +00:00
Author
Owner
Copy Link

@robertgendler commented on GitHub:

Removed from CIS. Does not seem manageable. Closing out.

@robertgendler commented on GitHub: Removed from CIS. Does not seem manageable. Closing out.
michael commented 2026-01-19 18:29:05 +00:00
Author
Owner
Copy Link

@robertgendler commented on GitHub:

So digging into this.

  1. Since VoicetriggerUserEnabled is not an officially supported key from Apple, the results could be unexpected. Maybe make a request to Apple for a way to manage that feature officially?
  2. Even without the profile and doing a defaults write to the User's preference plist. It appears to not actually disable Hey Siri.
  3. This looks to be a CIS only control. They may have to decide to remove the control or move it to an Audit since it can't actually be controlled.

More hunting is required at the moment. But I wouldn't expect many more results. It's hard to tell what's actually using the plist to say relaunch a process.

@robertgendler commented on GitHub: So digging into this. 1. Since VoicetriggerUserEnabled is not an officially supported key from Apple, the results could be unexpected. Maybe make a request to Apple for a way to manage that feature officially? 2. Even without the profile and doing a defaults write to the User's preference plist. It appears to not actually disable Hey Siri. 3. This looks to be a CIS only control. They may have to decide to remove the control or move it to an Audit since it can't actually be controlled. More hunting is required at the moment. But I wouldn't expect many more results. It's hard to tell what's actually using the plist to say relaunch a process.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
michael
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: usnistgov/macos_security#56
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?