git_admin/obsidian-vault
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[2026-08-31] eagle: work/projects/cpm-extension-health-pixels-privacy-triage.md

Browse Source
This commit is contained in:
Alexey Martemyanov
2026-08-31 18:01:01 +06:00
parent 84e0f90245
commit 5f03d3ee11
1 changed files with 35 additions and 74 deletions
Download Patch File Download Diff File Expand all files Collapse all files
work/projects/cpm-extension-health-pixels-privacy-triage.md
+35 -74
View File
@@ -1,94 +1,55 @@
# Privacy Triage: Apple - CPM Embedded WebExtension Health Pixels
# Privacy Triage: Apple - CPM Extension Health Pixels
Status: **DRAFT**
Name:
Alex M
**Name:** Alex M
**Email:** amartemyanov@duckduckgo.com
**Objective:** O-E
**PR:** [Add PR link]
**Project:** https://app.asana.com/1/137249556945/project/1163321984198618/task/1216761517055116?focus=true
Email address:
amartemyanov@duckduckgo.com
## Pixels
Name the triage:
Privacy Triage: Apple - CPM embedded WebExtension health pixels
| Pixel | When it fires |
|---|---|
| `debug_web_extension_cpm_page_initialization_missing` | A finished HTTP(S) page load does not receive the initial CPM status. |
| `debug_web_extension_cpm_page_initialization_recovered` | CPM works on the next page load or reload without reloading the extension. |
| `debug_web_extension_cpm_messaging_suspected_stuck` | CPM fails repeatedly, including after a page reload and in another tab. |
| `debug_web_extension_cpm_messaging_recovered_after_reload` | CPM starts working after the app reloads the extension. |
| `debug_web_extension_cpm_messaging_reload_failed` | CPM still does not work after the app reloads the extension. |
Objective:
O-E
macOS pixels use the same names with the `_macos` suffix. iOS uses the standard platform and form-factor suffixes.
List all pixels that need to be collected or modified:
The pixels send only the standard parameters: `appVersion`, plus `pixelSource` and `channel` on macOS.
PR: [Add PR link]
## Privacy Questions
The iOS names below receive the standard platform and form-factor suffixes. The corresponding macOS names end in `_macos`.
- Name: `debug_web_extension_cpm_page_initialization_missing` / `debug_web_extension_cpm_page_initialization_missing_macos`
- Triggering Condition: Fires after an eligible main-frame HTTP(S) navigation finishes, a grace period expires, the embedded CPM WebExtension context is loaded, and no initial CPM status was received for the current document. This records a page-level initialization miss only; it does not classify the extension as globally stuck.
- Frequency: Daily and standard.
- Parameters: Default parameters only (`appVersion`; macOS also includes the standard `pixelSource` and `channel` parameters).
- Name: `debug_web_extension_cpm_page_initialization_recovered` / `debug_web_extension_cpm_page_initialization_recovered_macos`
- Triggering Condition: Fires when CPM successfully initializes on a subsequent completed navigation or page reload after a page-level initialization miss, without reloading the embedded WebExtension. This distinguishes a transient page-load race from persistent extension messaging failure.
- Frequency: Once per detected health episode.
- Parameters: Default parameters only (`appVersion`; macOS also includes the standard `pixelSource` and `channel` parameters).
- Name: `debug_web_extension_cpm_messaging_suspected_stuck` / `debug_web_extension_cpm_messaging_suspected_stuck_macos`
- Triggering Condition: Fires once when the native cross-tab health monitor observes repeated CPM initialization misses across independent completed navigation attempts, including an ordinary page reload and another tab, with no successful CPM status received globally between the attempts. The embedded WebExtension context must remain loaded and must not report a background-content load error. This is the signal that initiates the self-healing extension reload.
- Frequency: Once per detected health episode, with daily and standard variants.
- Parameters: Default parameters only (`appVersion`; macOS also includes the standard `pixelSource` and `channel` parameters).
- Name: `debug_web_extension_cpm_messaging_recovered_after_reload` / `debug_web_extension_cpm_messaging_recovered_after_reload_macos`
- Triggering Condition: Fires when CPM successfully reports status after the app reloaded the embedded WebExtension in response to a suspected stuck-messaging episode.
- Frequency: Once per detected health episode.
- Parameters: Default parameters only (`appVersion`; macOS also includes the standard `pixelSource` and `channel` parameters).
- Name: `debug_web_extension_cpm_messaging_reload_failed` / `debug_web_extension_cpm_messaging_reload_failed_macos`
- Triggering Condition: Fires when the app reloaded the embedded WebExtension in response to a suspected stuck-messaging episode, but a subsequent eligible completed navigation still did not receive CPM initialization within the grace period.
- Frequency: Once per detected health episode.
- Parameters: Default parameters only (`appVersion`; macOS also includes the standard `pixelSource` and `channel` parameters).
No URL, hostname, search query, tab or window identifier, navigation or document identifier, extension identifier, CPM rule, error text, timestamp, latency, queue size, or user-provided value is included in any pixel. Navigation and cross-tab observations are correlated only in memory to decide which event to fire.
Optionally, provide a link to a task with background info:
https://app.asana.com/1/137249556945/project/1163321984198618/task/1216761517055116?focus=true
Pixel implementation task:
https://app.asana.com/1/137249556945/task/1217907325352247
Do the proposed pixels and their parameters use transparent naming?:
Yes. Each name describes the observed health transition and distinguishes a single-page initialization miss from a suspected global messaging failure and its reload outcome.
Do your proposed pixels share parameters (including default ones) with other pixels?:
**Do the pixels use transparent names?**
Yes.
Explain whether you believe there is a risk of these parameters linking together multiple pixels from the same user:
Shared parameters: `appVersion`; on macOS, the standard `pixelSource` and `channel` parameters; on iOS, the standard platform and form-factor suffixes.
**Do they share parameters with other pixels?**
Yes. They use only existing standard parameters.
No new correlation identifier is introduced. The events cannot be joined into a per-user sequence using any parameter added by this work. Episode state is maintained only in app memory and is not transmitted.
**Could the parameters link pixels to the same user?**
No. No identifier is added.
Do your proposed pixels include a search query or a website URL?:
No. They do not include a URL, hostname, page title, search query, or any derived representation of browsing content.
**Do the pixels include a URL or search query?**
No. They also do not include hostnames, page titles, tab IDs, document IDs, error text, or CPM rules.
Will the proposed pixels be temporary?:
Mixed:
**Are the pixels temporary?**
The two page-initialization pixels are temporary diagnostics. The three stuck-state and reload-result pixels are permanent health monitoring.
- `cpm_page_initialization_missing` and `cpm_page_initialization_recovered` are temporary diagnostic pixels. Remove them after the root cause and transient-failure rate have been established, no later than 2026-12-31.
- `cpm_messaging_suspected_stuck`, `cpm_messaging_recovered_after_reload`, and `cpm_messaging_reload_failed` are permanent watchdog health pixels.
**Why are the permanent pixels needed?**
To measure how often CPM messaging becomes stuck and whether reloading the extension fixes it.
Why do the pixels need to be permanent?:
The permanent pixels measure whether the self-healing watchdog is activating, whether extension reload restores CPM, and whether users remain affected after recovery. This is needed to detect regressions in WebKit or the embedded extension messaging layer and to verify that the mitigation continues to work across OS and app releases.
**Do any parameters or suffixes fall outside the standard criteria?**
No.
Do your pixels include any parameters or suffixes that do not meet the below criteria?:
No. Only existing default parameters and standard platform suffixes are used.
**Do the pixels fire on sensitive user events?**
No. They report only CPM extension health states.
Does your pixel fire on any of the below events?:
No. The pixels fire on aggregate CPM/WebExtension health-state transitions, not on user-entered data, specific browsing destinations, searches, purchases, authentication, or sensitive actions.
**Can multiple occurrences be tied to the same user or a small group?**
No. The pixels contain no correlation identifier or browsing data.
Would it be possible to tie multiple occurrences of your proposed pixels as belonging to the same user or small groups of users?:
No. There is no episode ID, tab ID, document ID, extension ID, URL-derived value, timestamp, or other correlation parameter. Daily suppression and in-memory once-per-episode guards reduce repeated firing without transmitting linkable state.
Did you answer "No" to all 3 self-service qualifiers above? In other words, do your pixels meet all the self-service criteria?:
**Does this meet the self-service criteria?**
Yes.
---
This content is prepared for the **Privacy Triage - Frontend Pixels** form:
https://form.asana.com/?k=q16Ao4fteEgxU3uzMp6Avw&d=137249556945