thesalsa@google.com rizvis@google.com The result of checking the anti-fingerprinting blocklist for a URL and deciding whether to block it. Recorded each time the blocklist is checked. Only clients that have opted into the blocklist feature will emit this metric. zalmashni@google.com chrome-browser-privacy-team@google.com Tracks whether the tabs deletion is disabled in Clear Browsing Data due to the user having multiple windows. dullweber@chromium.org chrome-browser-privacy-team@google.com Whether third-party cookies are blocked in incognito mode or completely. Recorded at the Profile startup. In case that "Block all cookies" is selected in settings, this metric records BlockThirdParty. This histogram is only recorded {RegularProfileFiltered}. arabm@chromium.org dullweber@chromium.org chrome-browser-privacy-team@google.com Horizontal metric to show CBD usage across various surfaces. Recorded when the user deletes browsing data from one of these surfaces or when the browser automatically deletes cookies because the user enabled "ClearOnExit". fsenra@google.com alimariam@google.com chrome-browser-privacy-team@google.com 1456716 Cross-platform metric to show interactions with DBD Dialog. Recorded when the user interacts with the dialog either by opening it, changing its prefs from time range to different browsing data selection, or commiting deletion. fsenra@chromium.org alimariam@chromium.org chrome-browser-privacy-team@google.com 1456716 The microseconds that passed between the tabs closure animation being triggered by Delete Browsing Data and the animation ending, iOS only. This histogram only records metrics on machines with high-resolution clocks. fsenra@chromium.org alimariam@chromium.org chrome-browser-privacy-team@google.com 1456716 Whether a user's pref values for Delete Browsing Data selection in iOS have been migrated to the new defaults. Only users who have never changed their pref values, i.e. never changed their selection in DBD, are eligible to be migrated to the new defaults. For the new version of Delete Browsing Data in iOS, each user will go through the migration of pref values that represent the selection in Delete Browsing Data once. iOS only. liu@chromium.org src/content/browser/btm/OWNERS Whether a {DIPSRedirectType} redirect accessed cookies and whether its origin previously had user engagement. Recorded when redirecting between different sites, {DIPSCookieMode}. In M-109, the DIPS Service was updated to explicitly not collect metrics for non-user profiles, such as system profiles and ChromeOS Signin, LockScreen, and LockScreenApp profiles. liu@chromium.org src/content/browser/btm/OWNERS The number of sites that may have had their storage cleared by DIPS. If DIPS deletion is on, third-party cookies are blocked, and there are no url-specific exemptions by the user for the latter, then, this is the number of sites that have had storage cleared by DIPS. Otherwise, this number is the sites that would've had their storage cleared if the above conditions were met for all the sites. This is recorded every time the DIPS timer is fired, which is determined by the `timer_delay` parameter of the DIPS feature. This is only logged for site-data clearing that occurs as a result of DIPS. If a site contributes to this count then it has performed a potential tracking action (e.g. writing to storage, bouncing the user, or both) without the user interacting with that site before, or soon after, the action. etienneb@chromium.org jdh@chromium.org src/content/browser/btm/OWNERS The time taken to execute the {DIPSDatabaseOperation} DIPS database operation. Recorded for each call to the operation. liu@chromium.org src/content/browser/btm/OWNERS Number of entries present in the `bounces` table of the user's DIPS database (where there is 1 entry per eTLD+1). For each user profile, reported at profile open (which usually happens at startup). Also reported approximately once every 24 hours thereafter, while the profile remains open and active. If the database is new and therefore empty at startup, such as when a Guest or other OTR profile is opened, a count of 0 will be reported. liu@chromium.org src/content/browser/btm/OWNERS Errors reported by SQLite while initializing or using the DIPS database. liu@chromium.org src/content/browser/btm/OWNERS The time taken to gather DIPS database health metrics. For each user profile, these metrics are reported at profile open (which usually happens at startup). They are also reported approximately once every 24 hours thereafter, while the profile remains open and active. Note that Guest and other OTR profiles (e.g. Incognito) will always startup with empty databases, so that may explain why some databases collect health metrics so quickly. liu@chromium.org src/content/browser/btm/OWNERS Logs how many attempts it took to initialize the DIPS database. Logs a value of 0 if all attempts failed. liu@chromium.org src/content/browser/btm/OWNERS The size of the DIPS database file. For each user profile, reported at profile open (which usually happens at startup). Also reported approximately once every 24 hours thereafter, while the profile remains open and active. Note that Guest and other OTR profiles (e.g. Incognito) will always startup with empty databases, so that may explain why some database files are very small. liu@chromium.org src/content/browser/btm/OWNERS The amount of time it takes to complete the DIPS deletion process. This is recorded each time the deletion of DIPS-eligible sites begins. For the case where the deletion is posted to the UI thread, this is the creation time of the StateClearer; otherwise, it is before the call to DIPSStorage::RemoveRows. This metric will be the result of |time when DIPS deletion completed - time when DIPS deletion begins|. njeunje@chromium.org src/content/browser/btm/OWNERS This is recorded each time we initiate a possible deletion of state on DIPS-eligible (incidental) sites. This metric will represents the action taken based on multiple conditions gating the actual deletion. This is recorded with {DIPSCookieMode} profiles. liu@chromium.org src/content/browser/btm/OWNERS Tracks certain errors that DIPS may encounter when running on a client. This is currently recorded when expected invariants are violated, such as there being an open-ended time range in the database. See `DIPSErrorCode` for all possible codes this histogram can output. Since these error codes can be recorded several times by a client, using per-client aggregation when analyzing this metric is recommended. liu@chromium.org src/content/browser/btm/OWNERS The amount of time after a navigation to a site commits until a renderer initiated navigation (without user activation) is started to a different site. Not recorded if the redirecting site does not access state (e.g. cookies) or takes longer than 10 seconds to initiate the redirect (bounce). In M-109, the DIPS Service was updated to explicitly not collect metrics for non-user profiles, such as system profiles and ChromeOS Signin, LockScreen, and LockScreenApp profiles. liu@chromium.org src/content/browser/btm/OWNERS Counts the number of times all cookie accesses were correctly matched and the number of times they weren't. mkwst@chromium.org msramek@chromium.org chrome-browser-privacy-team@google.com Whether the Do Not Track setting is enabled. Recorded at the profile open, only for regular profiles (not Incognito, Guest, etc.). olesiamarukhno@google.com chrome-browser-privacy-team@google.com The pattern scope of the exceptions shown in page info to the user. The pattern scope is defined based on the use of wildcards in the pattern. Examples of scopes are origin scope (https://www.example.com:433), domain wildcard scope (https://[*.]example.com:433) or custom scope (https://*, *:433 etc) fsenra@google.com zalmashni@google.com chrome-browser-privacy-team@google.com Tracks interactions with the Quick Delete feature, including the entry points and the dialog. zalmashni@google.com chrome-browser-privacy-team@google.com Tracks whether the tabs deletion is disabled in the Quick delete dialog due to the user having multiple windows. olesiamarukhno@google.com chrome-browser-privacy-team@google.com The type of the content setting exception that was manually created in the site settings page. olesiamarukhno@google.com chrome-browser-privacy-team@google.com The pattern scope of the exception manually created in the site settings page. The pattern scope is defined based on the use of wildcards in the pattern. Examples of scopes are origin scope (https://www.example.com:433), domain wildcard scope (https://[*.]example.com:433) or custom scope (https://*, *:433 etc) mkwst@chromium.org msramek@chromium.org dullweber@chromium.org chrome-browser-privacy-team@google.com Whether the third party cookie blocking setting is enabled. Recorded at the Profile startup. Previously recorded as the "ThirdPartyCookieBlockingEnabled" and "ThirdPartyCookieBlockingDisabled" actions. This histogram is only recorded {RegularProfileFiltered}. zalmashni@google.com chrome-browser-privacy-team@google.com Recorded when background eligibility evaluation determines that a user's feature eligibility status has changed, capturing the transition direction (Ineligible to Eligible, or Eligible to Ineligible). zalmashni@google.com chrome-browser-privacy-team@google.com Records which underlying system determined profile eligibility at startup (Account Capabilities or Finch/Variations) and whether the profile is eligible or ineligible. Recorded when UniversalOptOutService is initialized. zalmashni@google.com chrome-browser-privacy-team@google.com Tracks whether a profile is eligible for Universal Opt-Out at profile startup. Recorded when UniversalOptOutService is initialized. msramek@chromium.org rainhard@chromium.org chrome-browser-privacy-team@google.com Recorded when we attempt to show a Privacy Guide NTP promotion as instructed by the server. True if the conditions to do so are met. shivanisha@chromium.org xiaochenzh@chromium.org Records the estimated dynamic memory usage by the parsed attestations map. shivanisha@chromium.org xiaochenzh@chromium.org Records the amount of time taken for the downloaded attestations file to be detected from application starts. The measurement ends when `ComponentReady` is invoked with valid inputs. On ChromeOS: Before M129, the login screen counted as an interruption, so most initialization times were being logged under "ComponentReadyFromApplicationStartWithInterruption". This was fixed in M129 to count as "ComponentReadyFromApplicationStart". shivanisha@chromium.org xiaochenzh@chromium.org Records the amount of time taken for the downloaded attestations file to be detected from application starts with interruption during startup. For example, if the user has multiple profiles, a profile picker will appear during the startup. This is a non-browser UI that interrupts the startup process. The measurement ends when `ComponentReady` is invoked with valid inputs. On ChromeOS: Before M129, the login screen counted as an interruption, so most initialization times were being logged under "ComponentReadyFromApplicationStartWithInterruption". This was fixed in M129 to count as "ComponentReadyFromApplicationStart". shivanisha@chromium.org xiaochenzh@chromium.org Records the amount of time taken for the downloaded attestations file to be detected from first browser window paint. The measurement ends when `ComponentReady` is invoked with valid inputs. shivanisha@chromium.org xiaochenzh@chromium.org Records the amount of time taken to parse the attestations file from disk. The parsing is done on a thread pool thread, not on the main UI thread. The measurement starts from the invocation of the protobuf parsing function and ends when the function returns. Note this metric is recorded only if the parsing succeeds. shivanisha@chromium.org xiaochenzh@chromium.org Records the status of Privacy Sandbox APIs attestation checks. Each time a Privacy Sandbox API attestation check takes place, the status is recorded. The status can be allowed, or denied with reasons. This is an aggregate metric across all Privacy Sandbox APIs that require attestations. shivanisha@chromium.org xiaochenzh@chromium.org This histogram is recorded each time a Privacy Sandbox API attestation is checked. It records whether the in-memory attestation map, which is used as the source of truth for the incoming attestation check, is obtained by parsing a pre-installed or downloaded attestation list file. shivanisha@chromium.org xiaochenzh@chromium.org Records the duration from Chrome startup to the first Privacy Sandbox API attestation check. This metric should be recorded at most once per Chrome session. Here the measurement is taken from the time Chrome application starts. shivanisha@chromium.org xiaochenzh@chromium.org Same as PrivacySandbox.Attestations.IsSiteAttested. This histogram entry is created because what the histogram buckets represent has changed. Its bucket `AttestationsFileNotYetReady` used to represent the aggregation of the following cases: 1. The component installer has already checked and found the attestations file did not exist on disk. 2. The component installer has not checked the attestations file yet. The file may or may not exist on disk. In this version, these two cases have been separated out. Case 1 is recorded in `AttestationsFileNotPresent`, which is remaned from `AttestationsFileNotYetReady`. Case 2 now goes into `AttestationsFileNotYetChecked`. shivanisha@chromium.org xiaochenzh@chromium.org This histogram is only recorded on Android. It is only recorded if feature `PrivacySandboxAttestationsLoadFromAPKAsset` is enabled. It records the loading status of Privacy Sandbox attestations component from Android APK assets. The loading will be aborted when an error is encountered. The recorded status can be either success or failure with reasons per loading attempt. shivanisha@chromium.org xiaochenzh@chromium.org Records the parsing status of Privacy Sandbox APIs attestation file. Each time a Privacy Sandbox Attestation file is parsed, the status is recorded. The status can be success, or failure with reasons. sauski@google.com behamilton@chromium.org Records whether the joining site (including host fallback) for a Protected Audience interest group was successfully displayed. True if it was, false if the interest group was not displayed because no site or host could be determined. Recorded on a per interest group data key basis when the user opens the Protected Audience settings page.