<!--
Copyright 2020 The Chromium Authors
Use of this source code is governed by a BSD-style license that can be
found in the LICENSE file.
-->
<!--
This file is used to generate a comprehensive list of Cryptohome histograms
along with a detailed description for each histogram.
For best practices on writing histogram descriptions, see
https://chromium.googlesource.com/chromium/src.git/+/HEAD/tools/metrics/histograms/README.md
Please follow the instructions in the OWNERS file in this directory to find a
reviewer. If no OWNERS file exists, please consider signing up at
go/reviewing-metrics (Googlers only), as all subdirectories are expected to
have an OWNERS file. As a last resort you can send the CL to
[email protected].
-->
<histogram-configuration>
<histograms>
<variants name="CryptohomeAuthBlockTypes">
<variant name="ChallengeCredential"/>
<variant name="CryptohomeRecovery"/>
<variant name="DoubleWrappedCompat"/>
<variant name="Fingerprint"/>
<variant name="LibScryptCompat"/>
<variant name="PinWeaver"/>
<variant name="Scrypt"/>
<variant name="TpmBoundToPcr"/>
<variant name="TpmEcc"/>
<variant name="TpmNotBoundToPcr"/>
</variants>
<variants name="CryptohomeAuthFactorTypes">
<variant name="" summary="Aggregated."/>
<variant name=".CryptohomeRecovery"/>
<variant name=".Fingerprint"/>
<variant name=".Kiosk"/>
<variant name=".LegacyFingerprint"/>
<variant name=".Password"/>
<variant name=".Pin"/>
<variant name=".SmardCard"/>
</variants>
<variants name="CryptohomeErrorOperations">
<variant name="AddAuthFactorError"/>
<variant name="AuthenticateAuthFactorError"/>
<variant name="Error"/>
<variant name="PrepareAuthFactorError"/>
<variant name="RecreateAuthFactorError"/>
<variant name="RemoveAuthFactorError"/>
<variant name="UssMigrationError"/>
</variants>
<histogram name="Cryptohome.AuthFactorBackingStoreConfig"
enum="CryptohomeAuthFactorBackingStoreConfig" expires_after="2025-01-05">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Records the current type of backing stores in use for storing Cryptohome
authentication factors. Recorded whenever a new auth session is started
which generally occurs whenever an operation requiring authentication
happens (e.g. verifying credentials, adding or updating credentials,
mounting the user home directory, et cetera).
</summary>
</histogram>
<histogram name="Cryptohome.BackupKeysetCleanupResult"
enum="CryptohomeBackupKeysetCleanupResult" expires_after="2024-12-08">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Records the result of the backup VaultKeyset cleanup for users with mixed
USS-VaultKeyset configurations. Backup VaultKeysets are keysets marked as
backup during the migration to USS and kept as a rollback protection. Since
M114 backup keysets are removed on AuthSession start if the USS migration of
the particular user is completed. Starting with M115 backup keyset for the
migrated credential is removed after the successful authentication with the
given credential with USS, even if the USS migration is not completed. This
metric tracks the result of the removal of backup keysets after successful
authetnication for users whose USS migration isn't completed yet.
</summary>
</histogram>
<histogram name="Cryptohome.DeletedUserProfiles" units="profiles"
expires_after="2024-09-20">
<owner>[email protected]</owner>
<owner>src/ui/file_manager/OWNERS</owner>
<summary>
In low disk space scenarios, Cryptohome erases whole user profiles. This is
a number of user profiles deleted during cleanup. Only reported when
non-zero.
</summary>
</histogram>
<histogram name="Cryptohome.DiskCleanupProgress"
enum="CryptohomeDiskCleanupProgress" expires_after="2025-02-02">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
In low disk space scenarios, Cryptohome erases caches while target amount of
free disk space is not reached. It starts from low priority categories. This
histogram reports which topmost priority was reached to fulfill a cleanup
request.
</summary>
</histogram>
<histogram name="Cryptohome.DiskCleanupResult"
enum="CryptohomeDiskCleanupResult" expires_after="2025-02-02">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>Records the result of triggering disk cleanup.</summary>
</histogram>
<histogram name="Cryptohome.DownloadsBindMountMigration.{Operation}"
enum="PopularOSErrno" expires_after="2025-03-01">
<owner>[email protected]</owner>
<owner>src/ui/file_manager/OWNERS</owner>
<summary>
Error or success of the {Operation} operation that happened when migrating
the 'Downloads' folder from ~/Downloads to ~/MyFiles/Downloads.
</summary>
<token key="Operation">
<variant name="BackUp"/>
<variant name="CleanUp"/>
<variant name="Exchange"/>
<variant name="FixXattr"/>
<variant name="Move"/>
<variant name="RemoveReappearedDownloads"/>
<variant name="Restore"/>
<variant name="SetXattrForNewCryptoHome"/>
<variant name="SetXattrToMigrated"/>
<variant name="SetXattrToMigrating"/>
<variant name="UnmaskItem"/>
</token>
</histogram>
<histogram name="Cryptohome.DownloadsBindMountMigrationStatus"
enum="CryptohomeDownloadsMigrationStatus" expires_after="2025-03-01">
<owner>[email protected]</owner>
<owner>src/ui/file_manager/OWNERS</owner>
<summary>
This metric records events that happen during the migration of the
'Downloads' folder from ~/Downloads to ~/MyFiles/Downloads.
</summary>
</histogram>
<histogram name="Cryptohome.Errors" enum="CryptohomeError"
expires_after="2025-01-05">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>Cryptohome errors.</summary>
</histogram>
<histogram name="Cryptohome.Fingerprint.AuthSignal"
enum="CryptohomeFingerprintScanResult" expires_after="2025-05-18">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Fingerprint scan result signals during fingerprint authentication. Reporting
happens during the auth session started when the user presses their finger
for system auth (login, unlock etc.). Each finger touch detected by the
fingerprint sensor results in 1 signal, and internal failures of the
fingerprint sensor also results in 1 special signal indicating the end of
session although fingerprint authentication isn't completed.
</summary>
</histogram>
<histogram name="Cryptohome.Fingerprint.EnrollSignal"
enum="CryptohomeFingerprintScanResult" expires_after="2025-05-18">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Fingerprint scan result signals during fingerprint enrollment. Reporting
happens during the enroll session started when the user adds a new
fingerprint from OS settings. Each finger touch detected by the fingerprint
sensor results in 1 signal, and internal failures of the fingerprint sensor
also results in 1 special signal indicating the end of session although
fingerprint enrollment isn't completed.
</summary>
</histogram>
<histogram name="Cryptohome.FreedCacheVaultDiskSpaceInMb" units="MB"
expires_after="2024-12-01">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
This is an amount of Dmcrypt cache vault space (MB) which was evicted by
cryptohome due to shortage of remaining disk space. Reported only if
something was deleted (greater than zero).
</summary>
</histogram>
<histogram name="Cryptohome.FreeDiskSpaceDuringLoginTotalFreedInMb" units="MiB"
expires_after="2025-02-02">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Background: In critically low disk space scenarios, cryptohome performs
cleanup before allowing login to proceed. If enough space is available, this
operation is skipped and nothing is reported. This cleanup is related to the
periodic cleanup cryptohome performes.
This histogram records how many Mebibytes of space was freed in total every
time login cleanup is executed.
</summary>
</histogram>
<histogram name="Cryptohome.FreeDiskSpaceTotalFreedInMb" units="MiB"
expires_after="2025-02-02">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Background: In low disk space scenarios, cryptohome performs cleanup
periodically. If enough space is available, this operation is skipped and
nothing is reported.
This histogram records how many Mebibytes of space was freed in total every
time cleanup is executed.
</summary>
</histogram>
<histogram name="Cryptohome.FreeDiskSpaceTotalTime2" units="ms"
expires_after="2024-12-01">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
In low disk space scenarios, Cryptohome performs a lot of disk space
operations to erase data. This is a number of milliseconds taken to perform
a cleanup. Reported only if longer than 5 ms. Increased maximum and number
of buckets compared to FreeDiskSpaceTotalTime.
</summary>
</histogram>
<histogram name="Cryptohome.GCache.FreedDiskSpaceInMb" units="MB"
expires_after="2025-02-02">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
This is an amount of Google Drive cache (MB) which was evicted by cryptohome
due to shortage of remaining disk space. Reported only if something was
deleted (greater than zero).
</summary>
</histogram>
<histogram name="Cryptohome.HomedirEncryptionType" enum="HomedirEncryptionType"
expires_after="2025-02-10">
<owner>[email protected]</owner>
<summary>
The encryption type used for a user's cryptohome directory. This is logged
each time the cryptohome is mounted.
</summary>
</histogram>
<histogram name="Cryptohome.LegacyCodePathUsage.{Location}"
enum="BooleanCodePathUsage" expires_after="2023-07-09">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
This will report usage of {Location} paths to see if it is actually being
used or not to enable us to decide if we want to continue supporting
{Location} or not.
</summary>
<token key="Location">
<variant name="AddKeyResetSeedGeneration"
summary="Reset seed generated during Add Key operation"/>
</token>
</histogram>
<histogram name="Cryptohome.LoginDiskCleanupAvailableSpace" units="MiB"
expires_after="2024-12-01">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Records the amount of free space available (in MiB) on a device before login
cleanup is executed. Only recorded when login disk cleanup can run.
</summary>
</histogram>
<histogram name="Cryptohome.LoginDiskCleanupProgress"
enum="CryptohomeLoginDiskCleanupProgress" expires_after="2024-12-01">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
When disk space is very low during login, cryptohome will remove other users
to ensure that the current user can successfully log in. This metric tracks
what was performed to free up space.
cryptohomed reports what step was reached to fulfill a cleanup request. The
steps are described in CryptohomeLoginDiskCleanupProgress and are executed
in order.
</summary>
</histogram>
<histogram name="Cryptohome.LoginDiskCleanupResult"
enum="CryptohomeDiskCleanupResult" expires_after="2024-12-01">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Records the result of triggering disk cleanup during login. Reports failure
when any error is encountered and skipped if enough disk space is already
available.
</summary>
</histogram>
<histogram name="Cryptohome.LoginDiskCleanupTotalTime" units="ms"
expires_after="2024-12-01">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
When disk space is very low during login, cryptohome will remove other users
to ensure that the current user can successfully log in. This metric records
how long cleanup took before the user logged in.
</summary>
</histogram>
<histogram name="Cryptohome.MaskedDownloadsItems" units="items"
expires_after="2025-02-23">
<owner>[email protected]</owner>
<owner>src/ui/file_manager/OWNERS</owner>
<summary>
If the Downloads bind mount fails, files may be saved to ~/MyFiles/Downloads
directly and upon next login an attempt will be made to move these back into
~/Downloads to perform a bind mount. This metric records the number of items
(as direct children of ~/MyFiles/Downloads) that get migrated on the next
successful cryptohome mount.
</summary>
</histogram>
<histogram name="Cryptohome.MigrationUI.ConsumedBatteryPercent" units="%"
expires_after="2024-10-01">
<owner>[email protected]</owner>
<summary>
The amount of consumed battery level during cryptohome encryption migration.
This is logged when the battery level decreases during migration, and the
data is used to check if the minimum battery level required to start
migration is appropriate.
</summary>
</histogram>
<histogram name="Cryptohome.MigrationUI.FirstScreen"
enum="MigrationUIFirstScreen" expires_after="2024-10-01">
<owner>[email protected]</owner>
<summary>
The first screen in the encryption migration UI, which is shown when a user
attempts to log in to the system and old encryption (eCryptfs) is detected.
</summary>
</histogram>
<histogram name="Cryptohome.MigrationUI.MigrationResult"
enum="MigrationUIMigrationResult" expires_after="2024-10-01">
<owner>[email protected]</owner>
<summary>
The result of encryption migration from eCryptfs to Ext4 dircrypto. The
recorded result is what the migration UI in Chrome side is notified from
cryptohomed.
</summary>
</histogram>
<histogram name="Cryptohome.MigrationUI.RemoveCryptohomeResult"
enum="MigrationUIRemoveCryptohomeResult" expires_after="2024-10-01">
<owner>[email protected]</owner>
<summary>
The result of the removal of user's cryptohome. When the migration UI is
notified that the migration failed, the UI tries to remove the user's
cryptohome to make sure that the user can create clean crytohome directory
in the next sign-in.
</summary>
</histogram>
<histogram name="Cryptohome.MigrationUI.UserChoice"
enum="MigrationUIUserChoice" expires_after="2024-10-01">
<owner>[email protected]</owner>
<summary>
User's choice when the system is ready to migrate encryption. The user can
start migration or skip it. It is used to know how many users have skipped
migration.
</summary>
</histogram>
<histogram name="Cryptohome.MigrationUI.VisibleScreen" enum="MigrationUIScreen"
expires_after="2024-10-01">
<owner>[email protected]</owner>
<summary>
How many times each screen in migration UI is shown to the user. A screen is
recorded as a visible screen when the screen is kept displayed at least for
a second.
</summary>
</histogram>
<histogram name="Cryptohome.OOPMountCleanupResult"
enum="CryptohomeOOPMountCleanupResult" expires_after="2023-04-01">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The result of a cryptohome out-of-process mount cleanup. Recorded once per
logout.
</summary>
</histogram>
<histogram name="Cryptohome.OOPMountOperationResult"
enum="CryptohomeOOPMountOperationResult" expires_after="2024-04-28">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The result of a cryptohome out-of-process mount operation. Recorded once per
login attempt.
</summary>
</histogram>
<histogram name="Cryptohome.RecoverableKeyStore.ProviderUpdateCertResult"
enum="BackendCertProviderUpdateCertResult" expires_after="2024-12-31">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Records the result of updating the certificate in the recoverable key store
backend cert provider. This is recorded whenever a certificate file is
successfully fetched.
</summary>
</histogram>
<histogram name="Cryptohome.RecoverableKeyStore.VerifyAndParseCertResult"
enum="VerifyAndParseBackendCertResult" expires_after="2024-12-31">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Records the result of verifying and parsing the a recoverable key store
backend certificate file instance. This is recorded when the cert provider
loads the persisted cert files from disk on each boot, and when a
certificate file is successfully fetched.
</summary>
</histogram>
<histogram name="Cryptohome.RestoreSELinuxContextResultForHome"
enum="BooleanSuccess" expires_after="2025-02-10">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The result of a cryptohome restore SELinux context operation of user home
directory /home/.shadow/salted-hash and its subdirectories. Recorded once
per login attempt.
</summary>
</histogram>
<histogram name="Cryptohome.RestoreSELinuxContextResultForShadow"
enum="BooleanSuccess" expires_after="2024-10-01">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The result of a cryptohome restore SELinux context operation of shadow
directory /home/.shadow and its subdirectories. Recorded on a user's first
login on a device or login after factory reset.
WARNING: This histogram was expired from 2022-02-25 to 2022-04-22.
</summary>
</histogram>
<histogram name="Cryptohome.TimeBetweenFreeDiskSpace" units="s"
expires_after="2024-12-01">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The amount of time (s) between disk cleanup runs. If there is sufficient
disk space, nothing is reported. The first cleanup run after boot is not
reported.
</summary>
</histogram>
<histogram name="Cryptohome.TimeToAuthSessionRemoveAuthFactorUSS" units="ms"
expires_after="2025-06-01">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
AuthSession is a DBus API for various operations dealing with credential
storage, processing, and authentication. This metrics record the time an
RemoveAuthFactor takes to complete for USS. The metric is emitted when the
respective RemoveAuthFactor operation is requested through the DBus API.
</summary>
</histogram>
<histogram name="Cryptohome.TimeToCreatePersistentUser" units="ms"
expires_after="2025-06-01">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
AuthSession is a DBus API for various operations dealing with credential
storage, processing, and authentication. This metric records the amount of
time (ms) to create a persistent user. This is recorded when the AuthSession
is requested to create a persistent user in cryptohomed, through the DBUS
API.
</summary>
</histogram>
<histogram name="Cryptohome.TimeToGenerateEccAuthValue" units="ms"
expires_after="2025-01-05">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The amount of time (ms) for the ECC auth value generating process. It should
perform within a certain window: faster than the RSA implementation, but not
too fast (less than 100ms) to brute force. This metrics would be recorded
when user trying to login to the Chrome OS with the TPM ECC auth block and
only available on TPM2.0 devices.
</summary>
</histogram>
<histogram name="Cryptohome.TimeToInitPkcs11" units="ms"
expires_after="2025-01-26">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The amount of time (ms) for Chrome OS cryptohome daemon to initialize the
PKCS#11. Initializations under 1 second represent checks on a previously
initialized PKCS#11, and should be discarded for analysis.
</summary>
</histogram>
<histogram name="Cryptohome.TimeToMountEx" units="ms"
expires_after="2025-01-05">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The amount of time for Chrome OS cryptohome to mount the encrypted home
directory.
</summary>
</histogram>
<histogram name="Cryptohome.TimeToMountGuestEx" units="ms"
expires_after="2023-06-11">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The amount of time for Chrome OS cryptohome to mount the encrypted guest
home directory.
</summary>
</histogram>
<histogram name="Cryptohome.TimeToPerformEphemeralMount" units="ms"
expires_after="2023-04-01">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The amount of time cryptohome spends actively performing mounts when
creating an ephemeral user data directory. Does not include any process or
async dispatch overhead.
</summary>
</histogram>
<histogram name="Cryptohome.TimeToPerformMount" units="ms"
expires_after="2025-01-05">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The amount of time cryptohome spends performing the mounts for the user's
encrypted home directory. Does not include any process or async dispatch
overhead.
</summary>
</histogram>
<histogram name="Cryptohome.TimeToRelabelSELinuxContexts" units="ms"
expires_after="2025-01-05">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The amount of time for ChromeOS cryptohome to relabel SELinux contexts for
all files in the user cryptohome.
</summary>
</histogram>
<histogram name="Cryptohome.TimeToSetupVault" units="ms"
expires_after="2025-01-05">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The amount of time for ChromeOS cryptohome to set up the encrypted user
vault for mount.
</summary>
</histogram>
<histogram name="Cryptohome.TimeToUSSLoadPersisted" units="ms"
expires_after="2025-06-01">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The amount of time cryptohome spends reading persistent storage to populate
an encrypted USS container flatbuffer, or the time
UserSecretStash::LoadPersisted() takes to complete. The metric is emitted
during user authentication in cryptohome, when an AuthFactor must be
authenticated and UserSecretStash must read the corresponding USS file.
</summary>
</histogram>
<histogram name="Cryptohome.TimeToUSSPersist" units="ms"
expires_after="2025-06-01">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The amount of time cryptohome spends writing the USS container flatbuffer to
persistent storage. This metric records the time UserSecretStash::Persist()
takes to complete. The metric is emitted when a user adds, removes or
updates a means of authentication or AuthFactor. Manipulating an AuthFactor
requires UserSecretStash to write to the corresponding USS file.
</summary>
</histogram>
<histogram name="Cryptohome.TpmResults" enum="CryptohomeTpmResults"
expires_after="2023-10-30">
<owner>[email protected]</owner>
<summary>
The errors resulting from interacting with the Trusted Platform Module (TPM)
device.
</summary>
</histogram>
<histogram name="Cryptohome.VaultKeysetMetric.{VaultKeysetMetric}"
units="count" expires_after="2025-01-05">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Any given ChromeOS user has some number of vault keysets to store file name
encryption keys, depending on registered authentication factors at the time.
This histogram records how many vault keysets with {VaultKeysetMetric} a
user has. Recorded once per a successful preparation (mount) of the user
home directory by the ChromeOS cryptohome daemon.
</summary>
<token key="VaultKeysetMetric">
<variant name="EmptyLabelCount"/>
<variant name="EmptyLabelPINCount"/>
<variant name="FingerprintCount"/>
<variant name="KioskCount"/>
<variant name="MissingKeyDataCount"/>
<variant name="PasswordCount"/>
<variant name="PINCount"/>
<variant name="SmartCardCount"/>
<variant name="SmartUnlockCount"/>
<variant name="UnclassifedKeysetCount"/>
<variant name="UntypedKeysetCount"/>
</token>
</histogram>
<histogram name="Cryptohome.VkToUssMigrationStatus"
enum="VkToUssMigrationStatus" expires_after="2025-01-05">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Records a status value on every attempt to migrate a vault keyset backed
authentication factor to the User Secret Stash. The status will either
indicate success or an error, with different errors suggesting the general
class of failure that occured.
Migration of a factor is attempted whenever said factor is successfully used
to authenticate a session; usually when you login or unlock.
</summary>
</histogram>
<histogram name="Cryptohome.WrappingKeyDerivation.Create"
enum="WrappingKeyDerivation" expires_after="2023-05-01">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Derivation types of the Cryptohome's wrapping key. Reporting happens when
the Cryptohome is being created or when the new keys are added to the
existing Cryptohome. Concretely during a user creation, password change,
registration of a new authentication method (e.g. PIN), migration from
scrypt to TPM/GSC (in case the security chip becomes available later).
</summary>
</histogram>
<histogram name="Cryptohome.WrappingKeyDerivation.Mount"
enum="WrappingKeyDerivation" expires_after="2024-01-14">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Derivation types of the Cryptohome's wrapping key. Reporting happens mostly
when the Cryptohome is being mounted. Concretely the reporting happens
during a user creation, registration/removal of an authentication methods
(e.g. PIN), user login, password change, migration from scrypt to TPM/GSC
(in case the security chip becomes available later).
</summary>
</histogram>
<histogram name="Cryptohome.{Action}AuthBlockType"
enum="CryptohomeAuthBlockType" expires_after="2025-01-05">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The type of auth block that we {Action} in cryptohome. Recorded when
cryptohome accesses the auth block.
</summary>
<token key="Action">
<variant name="Create" summary="created"/>
<variant name="Derive" summary="derived"/>
</token>
</histogram>
<histogram name="Cryptohome.{AuthBlockType}.PrepareForRemovalResult"
enum="CryptohomeCryptoError" expires_after="2024-09-15">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Records the result of PrepareForRemoval() call of an auth factor. Reported
when an auth factor is deleted.
</summary>
<token key="AuthBlockType" variants="CryptohomeAuthBlockTypes"/>
</histogram>
<histogram name="Cryptohome.{AuthBlockType}.RevokeCredentialResult"
enum="HwsecRetryActionEnum" expires_after="2025-04-24">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Records the result of credentials revocation Revoke() method, which removes
the credential label from PinWeaver. Reported when an auth factor which uses
credentials revocation is deleted.
</summary>
<token key="AuthBlockType" variants="CryptohomeAuthBlockTypes"/>
</histogram>
<histogram name="Cryptohome.{AuthSessionFunction}.{AuthBlockType}" units="ms"
expires_after="2025-01-05">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
AuthSession is a DBus API for various operations dealing with credential
storage, processing, and authentication. These metrics record the time an
{AuthSessionFunction} takes to complete. Each function is parameterized by
an {AuthBlockType}, or credential backend, which significantly influences
results. The metric is emitted when the respective {AuthSessionFunction} is
requested through the DBus API.
</summary>
<token key="AuthSessionFunction">
<variant name="TimeToAuthSessionAddAuthFactorUSS"/>
<variant name="TimeToAuthSessionAddAuthFactorVK"/>
<variant name="TimeToAuthSessionAuthenticateAuthFactorUSS"/>
<variant name="TimeToAuthSessionAuthenticateAuthFactorVK"/>
<variant name="TimeToAuthSessionUpdateAuthFactorUSS"/>
<variant name="TimeToAuthSessionUpdateAuthFactorVK"/>
</token>
<token key="AuthBlockType">
<variant name="ChallengeCredential"/>
<variant name="CryptohomeRecovery"/>
<variant name="DoubleWrappedCompat"/>
<variant name="Fingerprint"/>
<variant name="LibScryptCompat"/>
<variant name="PinWeaver"/>
<variant name="Scrypt"/>
<variant name="TpmBoundToPcr"/>
<variant name="TpmEcc"/>
<variant name="TpmNotBoundToPcr"/>
</token>
</histogram>
<histogram name="Cryptohome.{AuthSessionLifetime}.{Type}" units="ms"
expires_after="2025-02-10">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
The amount of time an AuthSession lives for after authentication and
overall. This is 5 minutes by default, but can be extended through the
ExtendAuthSession API call. This metric is emitted when the AuthSession is
destroyed, by either manually invalidating through the DBus API or through
an automatic timeout.
</summary>
<token key="AuthSessionLifetime">
<variant name="AuthSessionAuthenticatedLifetime"/>
<variant name="AuthSessionTotalLifetime"/>
</token>
<token key="Type">
<variant name="Ephemeral"/>
<variant name="Persistent"/>
</token>
</histogram>
<histogram name="Cryptohome.{ErrorOperation}{AuthFactorType}.AllLocations"
enum="CryptohomeErrorLocation" expires_after="2024-12-31">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Background context on this histogram: A CryptohomeError in this context
refers to an error that occurred in response to a dbus request to selected
cryptohomed APIs. The set of APIs with this CryptohomeError is generally
those related to authentication, and contains CryptohomeErrorInfo field in
the dbus Reply protobuf. Currently that includes methods that are called
during login. A CryptohomeError consists of a linear stack of
ErrorLocations, each one of them is an actual line in the cryptohomed
codebase which the error passed through, and could have certain attributes,
known as ErrorAction attached to them. The ErrorLocation in the bottom of
the stack could optionally have a TPM Error Code associated, if the source
of error is TPM related.
For this histogram, for every CryptohomeError that occurs, we individually
report each individual ErrorLocation's corresponding enum value when an
error ocurred.
This histogram is also separated into several error buckets. The most
standard error bucket is 'Error', which collects the errors populated in
dbus responses. Other buckets are errors we collect in some subrountines,
like migration. Migration errors are not surfaced to dbus responses, but
silently fail instead. We collect those errors in separate buckets.
This is useful to cryptohome developers in the sense that they'll be able to
know which lines that handle error in cryptohomed has been triggered due to
an error.
</summary>
<token key="ErrorOperation" variants="CryptohomeErrorOperations"/>
<token key="AuthFactorType" variants="CryptohomeAuthFactorTypes"/>
</histogram>
<histogram
name="Cryptohome.{ErrorOperation}{AuthFactorType}.DevUnexpectedState"
enum="CryptohomeErrorLocation" expires_after="2024-12-31">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Background context on this histogram: A CryptohomeError in this context
refers to an error that occurred in response to a dbus request to selected
cryptohomed APIs. The set of APIs with this CryptohomeError is generally
those related to authentication, and contains CryptohomeErrorInfo field in
the dbus Reply protobuf. Currently that includes methods that are called
during login. A CryptohomeError consists of a linear stack of
ErrorLocations, each one of them is an actual line in the cryptohomed
codebase which the error passed through, and could have certain attributes,
known as ErrorAction attached to them. The ErrorLocation in the bottom of
the stack could optionally have a TPM Error Code associated, if the source
of error is TPM related.
For this histogram, for every CryptohomeError, we individually report all
ErrorLocation that has the kDevCheckUnexpectedState ErrorAction associated
with it. The kDevCheckUnexpectedState ErrorAction is used by developers when
the developer believes that this error should never occur, so from a
notification standpoint, it functions similar to a DCHECK(), except it never
crashes cryptohome and handles the error in a graceful manner.
This histogram is also separated into several error buckets. The most
standard error bucket is 'Error', which collects the errors populated in
dbus responses. Other buckets are errors we collect in some subrountines,
like migration. Migration errors are not surfaced to dbus responses, but
silently fail instead. We collect those errors in separate buckets.
This is useful to cryptohome developers because they'll be alerted when any
of the situations that the developers doesn't expect to occur occurs.
</summary>
<token key="ErrorOperation" variants="CryptohomeErrorOperations"/>
<token key="AuthFactorType" variants="CryptohomeAuthFactorTypes"/>
</histogram>
<histogram name="Cryptohome.{ErrorOperation}{AuthFactorType}.HashedStack"
enum="CryptohomeErrorHashed" expires_after="2024-12-31">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Background context on this histogram: A CryptohomeError in this context
refers to an error that occurred in response to a dbus request to selected
cryptohomed APIs. The set of APIs with this CryptohomeError is generally
those related to authentication, and contains CryptohomeErrorInfo field in
the dbus Reply protobuf. Currently that includes methods that are called
during login. A CryptohomeError consists of a linear stack of
ErrorLocations, each one of them is an actual line in the cryptohomed
codebase which the error passed through, and could have certain attributes,
known as ErrorAction attached to them. The ErrorLocation in the bottom of
the stack could optionally have a TPM Error Code associated, if the source
of error is TPM related.
For this histogram, we take the entire CryptohomeError's linear stack of
ErrorLocation, and hash the entire stack, then we report the hash. The
original stack of ErrorLocation is logged.
This histogram is also separated into several error buckets. The most
standard error bucket is 'Error', which collects the errors populated in
dbus responses. Other buckets are errors we collect in some subrountines,
like migration. Migration errors are not surfaced to dbus responses, but
silently fail instead. We collect those errors in separate buckets.
This is useful to cryptohome developers because we're able to classify the
CryptohomeError by the content of the stack, and identify new ways the error
can occur if they do occur.
</summary>
<token key="ErrorOperation" variants="CryptohomeErrorOperations"/>
<token key="AuthFactorType" variants="CryptohomeAuthFactorTypes"/>
</histogram>
<histogram name="Cryptohome.{ErrorOperation}{AuthFactorType}.LeafErrorWithTPM"
enum="CryptohomeErrorLocationWithTPMError" expires_after="2024-12-31">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Background context on this histogram: A CryptohomeError in this context
refers to an error that occurred in response to a dbus request to selected
cryptohomed APIs. The set of APIs with this CryptohomeError is generally
those related to authentication, and contains CryptohomeErrorInfo field in
the dbus Reply protobuf. Currently that includes methods that are called
during login. A CryptohomeError consists of a linear stack of
ErrorLocations, each one of them is an actual line in the cryptohomed
codebase which the error passed through, and could have certain attributes,
known as ErrorAction attached to them. The ErrorLocation in the bottom of
the stack could optionally have a TPM Error Code associated, if the source
of error is TPM related.
For this histogram, for every CryptohomeError that occurred, we report the
last ErrorLocation that does not have a TPM Error Code associated, and
optionally the last ErrorLoctaion that have a TPM Error Code associated if
one exist. The upper and lower 16-bit value of the reported value contains
the last ErrorLocation that does not have a TPM Error Code associated and
the TPM Error Code, correspondingly. If the CryptohomeError doesn't have a
TPM Error Code associated, we report only the last ErrorLocation in the
upper 16-bit value of the reported value, with zero for the other 16-bit. In
addition, we might also report success values in this histogram. Success
values map to zero.
This histogram is also separated into several error buckets. The most
standard error bucket is 'Error', which collects the errors populated in
dbus responses. Other buckets are errors we collect in some subrountines,
like migration. Migration errors are not surfaced to dbus responses, but
silently fail instead. We collect those errors in separate buckets.
This is useful to cryptohome developers because frequently, the last and
second last ErrorLocation in the stack would be able to uniquely identify
the error, and this histogram doesn't involve hashing, so it would be more
convenient for the developers.
</summary>
<token key="ErrorOperation" variants="CryptohomeErrorOperations"/>
<token key="AuthFactorType" variants="CryptohomeAuthFactorTypes"/>
</histogram>
<histogram name="CryptohomeClient" units="ms" expires_after="2024-07-24">
<owner>[email protected]</owner>
<owner>[email protected]</owner>
<summary>
Records the time duration of every dbus outgoing calls issued from the
client of Crypthome in Chrome side.
</summary>
</histogram>
</histograms>
</histogram-configuration>
Codebase Browser
chromium