king
/
v811_spc009
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'main'
${ noResults }
v811_spc009/compatibility/cdd/9_security-model/9_8_privacy.md

15 KiB
Raw Permalink Blame History Escape

9.8. Privacy

9.8.1. Usage History

Android stores the history of the user's choices and manages such history by UsageStatsManager.

Device implementations:

  • [C-0-1] MUST keep a reasonable retention period of such user history.
  • [SR] Are STRONGLY RECOMMENDED to keep the 14 days retention period as configured by default in the AOSP implementation.

Android stores the system events using the StatsLog identifiers, and manages such history via the StatsManager and the IncidentManager System API.

Device implementations:

  • [C-0-2] MUST only include the fields marked with DEST_AUTOMATIC in the incident report created by the System API class IncidentManager.
  • [C-0-3] MUST not use the system event identifiers to log any other event than what is described in the StatsLog SDK documents. If additional system events are logged, they MAY use a different atom identifier in the range between 100,000 and 200,000.

9.8.2. Recording

Device implementations:

  • [C-0-1] MUST NOT preload or distribute software components out-of-box that send the user's private information (e.g. keystrokes, text displayed on the screen, bugreport) off the device without the user's consent or clear ongoing notifications.
  • [C-0-2] MUST display and obtain explicit user consent that includes exactly the same message as AOSP whenever screen casting or screen recording is enabled via MediaProjection or proprietary APIs. MUST NOT provide users an affordance to disable future display of the user consent.
  • [C-0-3] MUST have an ongoing notification to the user while screen casting or screen recording is enabled. AOSP meets this requirement by showing an ongoing notification icon in the status bar.

If device implementations include functionality in the system that either captures the contents displayed on the screen and/or records the audio stream played on the device other than via the System API ContentCaptureService, or other proprietary means described in Section 9.8.6 Content Capture, they:

  • [C-1-1] MUST have an ongoing notification to the user whenever this functionality is enabled and actively capturing/recording.

If device implementations include a component enabled out-of-box, capable of recording ambient audio and/or record the audio played on the device to infer useful information about user’s context, they:

  • [C-2-1] MUST NOT store in persistent on-device storage or transmit off the device the recorded raw audio or any format that can be converted back into the original audio or a near facsimile, except with explicit user consent.

9.8.3. Connectivity

If device implementations have a USB port with USB peripheral mode support, they:

  • [C-1-1] MUST present a user interface asking for the user's consent before allowing access to the contents of the shared storage over the USB port.

9.8.4. Network Traffic

Device implementations:

  • [C-0-1] MUST preinstall the same root certificates for the system-trusted Certificate Authority (CA) store as provided in the upstream Android Open Source Project.
  • [C-0-2] MUST ship with an empty user root CA store.
  • [C-0-3] MUST display a warning to the user indicating the network traffic may be monitored, when a user root CA is added.

If device traffic is routed through a VPN, device implementations:

  • [C-1-1] MUST display a warning to the user indicating either:
    • That network traffic may be monitored.
    • That network traffic is being routed through the specific VPN application providing the VPN.

If device implementations have a mechanism, enabled out-of-box by default, that routes network data traffic through a proxy server or VPN gateway (for example, preloading a VPN service with android.permission.CONTROL_VPN granted), they:

If device implementations implement a user affordance to toggle on the "always-on VPN" function of a 3rd-party VPN app, they:

  • [C-3-1] MUST disable this user affordance for apps that do not support always-on VPN service in the AndroidManifest.xml file via setting the SERVICE_META_DATA_SUPPORTS_ALWAYS_ON attribute to false.

9.8.5. Device Identifiers

Device implementations:

  • [C-0-1] MUST prevent access to the device serial number and, where applicable, IMEI/MEID, SIM serial number, and International Mobile Subscriber Identity (IMSI) from an app, unless it meets one of the following requirements:
    • is a signed carrier app that is verified by device manufacturers.
    • has been granted the READ_PRIVILEGED_PHONE_STATE permission.
    • has carrier privileges as defined in UICC Carrier Privileges.
    • is a device owner or profile owner that has been granted the READ_PHONE_STATE permission.

9.8.6. Content Capture

Android, through the System API ContentCaptureService, or by other proprietary means, supports a mechanism for device implementations to capture the following interactions between the applications and the user.

  • Text and graphics rendered on-screen, including but not limited to, notifications and assist data via AssistStructure API.
  • Media data, such as audio or video, recorded or played by the device.
  • Input events (e.g. key, mouse, gesture, voice, video, and accessibility).
  • Any other events that an application provides to the system via the Content Capture API or a similarly capable, proprietary API.
  • Any text or other data sent via the TextClassifier API to the System TextClassifier i.e to the system service to understand the meaning of text, as well as generating predicted next actions based on the text.

If device implementations capture the data above, they:

  • [C-0-1] MUST encrypt all such data when stored in the device. This encryption MAY be carried out using Android File Based Encryption, or any of the ciphers listed as API version 26+ described in Cipher SDK.
  • [C-0-2] MUST NOT back up either raw or encrypted data using Android backup methods or any other back up methods.
  • [C-0-3] MUST only send all such data and the log of the device using a privacy-preserving mechanism. The privacy-preserving mechanism is defined as “those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users”, to prevent any per-user data being introspectable (e.g., implemented using a differential privacy technology such as RAPPOR).
  • [C-0-4] MUST NOT associate such data with any user identity (such as Account) on the device, except with explicit user consent each time the data is associated.
  • [C-0-5] MUST NOT share such data with other apps, except with explicit user consent every time it is shared.
  • [C-0-6] MUST provide user affordance to erase such data that the ContentCaptureService or the proprietary means collects if the data is stored in any form on the device.

If device implementations include a service that implements the System API ContentCaptureService, or any proprietary service that captures the data as described as above, they:

  • [C-1-1] MUST NOT allow users to replace the content capture service with a user-installable application or service and MUST only allow the preinstalled service to capture such data.

  • [C-1-2] MUST NOT allow any apps other than the preinstalled content capture service mechanism to be able to capture such data.

  • [C-1-3] MUST provide user affordance to disable the content capture service.

  • [C-1-4] MUST NOT omit user affordance to manage Android permissions that are held by the content capture service and follow Android permissions model as described in Section 9.1. Permission.

  • [C-SR] Are STRONGLY RECOMMENDED to keep the content capturing service components separate, for example, not binding the service or sharing process IDs, from other system components except for the following:

    • Telephony, Contacts, System UI, and Media

9.8.7. Clipboard Access

Device implementations:

  • [C-0-1] MUST NOT return a clipped data on the clipboard (e.g. via the ClipboardManager API) unless the app is the default IME or is the app that currently has focus.

9.8.8. Location

Device implementations:

  • [C-0-1] MUST NOT turn on/off device location setting and Wi-Fi/Bluetooth scanning settings without explicit user consent or user initiation.
  • [C-0-2] MUST provide the user affordance to access location related information including recent location requests, app level permissions and usage of Wi-Fi/Bluetooth scanning for determining location.
  • [C-0-3] MUST ensure that the application using Emergency Location Bypass API [LocationRequest.setLocationSettingsIgnored()] is a user initiated emergency session (e.g. dial 911 or text to 911). For Automotive however, a vehicle MAY initiate an emergency session without active user interaction in the case a crash/accident is detected (e.g. to satisfy eCall requirements).
  • [C-0-4] MUST preserve the Emergency Location Bypass API's ability to bypass device location settings without changing the settings.
  • [C-0-5] MUST schedule a notification that reminds the user after an app in the background has accessed their location using the [ACCESS_BACKGROUND_LOCATION] permission.

9.8.9. Installed apps

Android apps targeting API level 30 or above cannot see details about other installed apps by default (see Package visibility in the Android SDK documentation).

Device implementations:

  • [C-0-1] MUST NOT expose to any app targeting API level 30 or above details about any other installed app, unless the app is already able to see details about the other installed app through the managed APIs. This includes but is not limited to details exposed by any custom APIs added by the device implementer, or accessible via the filesystem.

9.8.10. Connectivity Bug Report

If device implementations generate bug reports using System API BUGREPORT_MODE_TELEPHONY with BugreportManager, they:

  • [C-1-1] MUST obtain user consent every time the System API BUGREPORT_MODE_TELEPHONY is called to generate a report and MUST NOT prompt the user to consent to all future requests from the application.
  • [C-1-2] MUST display and obtain explicit user consent when the reports are starting to be generated and MUST NOT return the generated report to the requesting app without explicit user consent.
  • [C-1-3] MUST generate requested reports containing at least the following information:
    • TelephonyDebugService dump
    • TelephonyRegistry dump
    • WifiService dump
    • ConnectivityService dump
    • A dump of the calling package's CarrierService instance (if bound)
    • Radio log buffer
  • [C-1-4] MUST NOT include the following in the generated reports:
    • Any kind of information unrelated to connectivity debugging.
    • Any kind of user-installed application traffic logs or detailed profiles of user-installed applications/packages (UIDs are okay, package names are not).
  • MAY include additional information that is not associated with any user identity. (e.g. vendor logs).

If device implementations include additional information (e.g vendor logs) in the bug report and that information has privacy/security/battery/storage/memory impact, they:

  • [C-SR] Are STRONGLY RECOMMENDED to have a developer setting defaulted to disabled. The AOSP meets this by providing the Enable verbose vendor logging option in developer settings to include additional device-specific vendor logs in the bug reports.

9.8.11. Data blobs sharing

Android, through BlobStoreManager allows apps to contribute data blobs to the System to be shared with a selected set of apps.

If device implementations support shared data blobs as described in the SDK documentation, they: