Open Bug 1742137 Opened 3 years ago Updated 7 months ago

Crashes that include CRASHING_DUE_TO_PRIVACY_VIOLATION in proto signature

Categories

(Core :: Widget: Cocoa, defect, P3)

Product:
Core
Component:
Widget: Cocoa
Platform:
Unspecified
macOS
Type:
defect

Tracking

()

People

(Reporter: smichaud, Unassigned)

Details

Crash Data

https://crash-stats.mozilla.org/search/?proto_signature=~__TCC_CRASHING_DUE_TO_PRIVACY_VIOLATION__&platform=Mac%20OS%20X&date=%3E%3D2021-05-19T18%3A05%3A00.000Z&date=%3C2021-11-19T18%3A05%3A00.000Z&_facets=signature&_facets=platform_version&_facets=proto_signature&_sort=-date&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-platform_version

Typical example:

    Crashing Thread (103)
    Frame  Module  Signature  Source  Trust
    0  libsystem_kernel.dylib  __abort_with_payload   context
    1  libsystem_kernel.dylib  abort_with_payload   frame_pointer
    2  TCC  __TCC_CRASHING_DUE_TO_PRIVACY_VIOLATION__   frame_pointer
    3  TCC  __TCCAccessRequest_block_invoke.128   frame_pointer
    4  TCC  __tccd_send_message_block_invoke   frame_pointer
    5  libxpc.dylib  _xpc_connection_reply_callout   frame_pointer
    6  libxpc.dylib  _xpc_connection_call_reply_async   frame_pointer
    7  libdispatch.dylib  _dispatch_client_callout3   frame_pointer
    8  libdispatch.dylib  _dispatch_mach_msg_async_reply_invoke   frame_pointer
    9  libdispatch.dylib  _dispatch_kevent_worker_thread   frame_pointer
    10  libsystem_pthread.dylib  _pthread_wqthread   frame_pointer
    11  libsystem_pthread.dylib  start_wqthread   frame_pointer

It's possible these can be worked around by adding a single key to the application's Info.plist file: https://stackoverflow.com/questions/39571603/app-crashes-with-crashing-due-to-privacy-violation-when-trying-to-access-con

The comments seem to refer to attempts at using a webcam for video capture, or to join video meetings such as Google Meet.

Severity: -- → S2
Priority: -- → P2

(In reply to Stephen A Pohl [:spohl] from comment #1)

The comments seem to refer to attempts at using a webcam for video capture, or to join video meetings such as Google Meet.

Interesting. I wish there were a way to find out (from the crash reports) exactly what kind of "privacy violation" is happening. I haven't (yet) found one.

We seem to properly set the required keys in the Info.plist file, but I vaguely recall that there are some situations that can be problematic when access to the webcam was previously denied. Haik, I believe you had more info on this. Have you seen or heard of these types of privacy violations before? And should this bug stay in the widget:cocoa component, or is this maybe better addressed under audio/video?

Flags: needinfo?(haftandilian)

For what it's worth (from the crash reports), the accesses that trigger these privacy errors seem to be mediated by tccd, which is part of the TCC private framework. It'll take a lot of digging to figure out how that works, though. It's completely undocumented (not even a man page).

Besides NSContactsUsageDescription, tccd contains the following strings (on macOS 10.15.7 build 19H1519):

NSCalendarsUsageDescription
NSRemindersUsageDescription
NSPhotoLibraryUsageDescription
NSPhotoLibraryAddUsageDescription
NSCameraUsageDescription
NSMicrophoneUsageDescription
NSHomeKitUsageDescription
NSAppleMusicUsageDescription
NSSiriUsageDescription
NSMotionUsageDescription
NSSpeechRecognitionUsageDescription
NSBluetoothPeripheralUsageDescription
NSBluetoothWhileInUseUsageDescription
NSBluetoothAlwaysUsageDescription
NSVoIPUsageDescription
NSFaceIDUsageDescription

Summary: [macOS 11] Crashes that include __TCC_CRASHING_DUE_TO_PRIVACY_VIOLATION__ in proto signature → Crashes that include CRASHING_DUE_TO_PRIVACY_VIOLATION in proto signature

(Following up comment #6)

Here are some additional "usage description" properties from macOS 12's tccd:

NSUserTrackingUsageDescription
NSGKFriendListUsageDescription
NSFallDetectionUsageDescription
NSSensorKitBedSensingWritingUsageDescription
NSNearbyInteractionUsageDescription
NSFocusStatusUsageDescription
NSUserAvailabilityNameUsageDescription
NSSystemAdministrationUsageDescription
NSAppleEventsUsageDescription
NSFileProviderPresenceUsageDescription
NSFileProviderDomainUsageDescription
NSRemovableVolumesUsageDescription
NSNetworkVolumesUsageDescription
NSDesktopFolderUsageDescription
NSDownloadsFolderUsageDescription
NSDocumentsFolderUsageDescription

I haven't (yet) looked at macOS 11's tccd, so I don't know exactly when these first appeared.

I suspect they also happen on macOS 12, but I haven't yet found them.

From looking at the TCC private framework on macOS 12, you can tell that it (like on macOS 11) has a __TCC_CRASHING_DUE_TO_PRIVACY_VIOLATION__ method. I suspect the reason we haven't (yet) seen these crashes on macOS 12 is that they're so infrequent.

I wish there were a way to find out (from the crash reports) exactly what kind of "privacy violation" is happening. I haven't (yet) found one.

Too bad the TCC private framework doesn't have a _crash_info section :-(

Crash Signature: [@ __abort_with_payload | abort_with_payload_wrapper_internal | abort_with_payload | __TCC_CRASHING_DUE_TO_PRIVACY_VIOLATION__ ] [@ __abort_with_payload | abort_with_payload | __CRASHING_DUE_TO_PRIVACY_VIOLATION__ ] [@ __abort_with_payload | abort_with_…

(In reply to Steven Michaud [:smichaud] (Retired) from comment #10)

I suspect they also happen on macOS 12, but I haven't yet found them.

From looking at the TCC private framework on macOS 12, you can tell that it (like on macOS 11) has a __TCC_CRASHING_DUE_TO_PRIVACY_VIOLATION__ method. I suspect the reason we haven't (yet) seen these crashes on macOS 12 is that they're so infrequent.

Here's one: bp-5a05189a-e745-4510-b174-eb1900211122

(In reply to Stephen A Pohl [:spohl] from comment #4)

We seem to properly set the required keys in the Info.plist file, but I vaguely recall that there are some situations that can be problematic when access to the webcam was previously denied. Haik, I believe you had more info on this. Have you seen or heard of these types of privacy violations before? And should this bug stay in the widget:cocoa component, or is this maybe better addressed under audio/video?

I don't remember seeing these types of crashes before. Since they appear to be correlated with camera use, I wonder if they could be being triggered by users manually removing those permissions in preferences while Firefox is running. I have not been able to hit a crash so far by toggling the permission in System Preferences while still using Firefox with the camera enabled on a webrtc site.

For debugging tccd, the log command may be helpful. For example log show --predicate 'subsystem == "com.apple.TCC"' --info --last 1h.

Bug 1719042 is an example where the user removes the screen recording permission, but it's not a crash. We had a small brush with tccd on bug 1576733, but that does not appear to be related to this problem.

I think it makes sense to transfer to audio/video while we continue to debug it. The audio/video team might be able to rule out if we are ever trying to access the camera/mic before we have permission.

Flags: needinfo?(haftandilian)

The only relevant comment that I have been able to find is:

"Happens after granting microphone permission to the website installed as a web app using PWAsForFirefox project."

Severity: S2 → S4
Priority: P2 → P3

The bug is linked to a topcrash signature, which matches the following criterion:

  • Top 5 desktop browser crashes on Mac on beta

:spohl, could you consider increasing the severity of this top-crash bug?

For more information, please visit auto_nag documentation.

Flags: needinfo?(spohl.mozilla.bugs)
Keywords: topcrash
Crash Signature: abort_with_payload | __TCC_CRASHING_DUE_TO_PRIVACY_VIOLATION__ ] [@ __abort_with_payload | abort_with_payload_wrapper_internal | abort_with_payload | __CRASHING_DUE_TO_PRIVACY_VIOLATION__ ] → abort_with_payload | __TCC_CRASHING_DUE_TO_PRIVACY_VIOLATION__ ] [@ __abort_with_payload | abort_with_payload_wrapper_internal | abort_with_payload | __CRASHING_DUE_TO_PRIVACY_VIOLATION__ ] [@ __abort_with_payload | abort_with_payload_wrapper_internal …
Severity: S4 → S3
Flags: needinfo?(spohl.mozilla.bugs)

Based on the topcrash criteria, the crash signatures linked to this bug are not in the topcrash signatures anymore.

For more information, please visit auto_nag documentation.

Keywords: topcrash

For what it's worth, these crashes don't seem to be happening on macOS 14. Maybe this was an Apple bug, and they fixed it.

You need to log in before you can comment on or make changes to this bug.