[2026-08-31] eagle: Untitled 1.md Untitled.md work/projects/cpm-extension-health-pixels-privacy-triage.md
This commit is contained in:
Alexey Martemyanov
@@ -0,0 +1,94 @@
|
||||
# Privacy Triage: Apple - CPM Embedded WebExtension Health Pixels
|
||||
|
||||
Status: **DRAFT**
|
||||
|
||||
Name:
|
||||
Alex M
|
||||
|
||||
Email address:
|
||||
amartemyanov@duckduckgo.com
|
||||
|
||||
Name the triage:
|
||||
Privacy Triage: Apple - CPM embedded WebExtension health pixels
|
||||
|
||||
Objective:
|
||||
O-E
|
||||
|
||||
List all pixels that need to be collected or modified:
|
||||
|
||||
PR: [Add PR link]
|
||||
|
||||
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?:
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
Will the proposed pixels be temporary?:
|
||||
Mixed:
|
||||
|
||||
- `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 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 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.
|
||||
|
||||
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.
|
||||
|
||||
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?:
|
||||
Yes.
|
||||
|
||||
---
|
||||
|
||||
This content is prepared for the **Privacy Triage - Frontend Pixels** form:
|
||||
https://form.asana.com/?k=q16Ao4fteEgxU3uzMp6Avw&d=137249556945
|
||||
Reference in New Issue
Block a user