[w3ctag/design-reviews] Other Spec Review: JS Self-Profiling Markers (ProfilerSample.marker) (Issue #1251)

monica-ch created an issue (w3ctag/design-reviews#1251)

### Specification

https://github.com/WICG/js-self-profiling/blob/main/markers.md, https://github.com/WICG/js-self-profiling/pull/89

### Explainer

https://github.com/WICG/js-self-profiling/blob/main/markers.md

### Links

- Previous early design review, if any: https://github.com/w3ctag/design-reviews/issues/366
- An introduction to the feature, aimed at unfamiliar audiences: https://github.com/WICG/js-self-profiling/blob/main/markers.md#introduction
- A description of the problems that end-users were facing before this proposal: https://github.com/WICG/js-self-profiling/blob/main/markers.md#introduction
- Alternatives considered: https://github.com/WICG/js-self-profiling/issues/61
- Examples of how to use the proposal to solve the end-users' problems: https://github.com/WICG/js-self-profiling/blob/main/markers.md#key-scenarios
- What do the end-users experience with this proposal: https://github.com/WICG/js-self-profiling/blob/main/markers.md#introduction
- User research you did to validate the problem and/or design, if any: N/A — validated with partner developers (Excel Online, Datadog) via an upcoming Chromium Origin Trial rather than formal user research.
- Web Platform Tests: https://wpt.fyi/results/js-self-profiling/tentative/marker-vm-state.https.html

### The specification

- [x] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [x] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo: https://github.com/WICG/js-self-profiling
- Primary contacts:
  - Monica Chintala (@monica-ch), Microsoft, Origin Trial lead
  - Andrew Comminos (@acomminos), Meta, base JS Self-Profiling API editor
- Organization/project driving the specification: Microsoft (Microsoft Edge)
- This work is being funded by: Microsoft
- Primary standards group developing this feature: W3C Web Performance Community Group / WICG
- Group intended to standardize this work: W3C Web Performance Working Group
- Incubation and standards groups that have discussed the design:
  - WICG (Web Incubator CG) — proposal, IDL, and cross-origin exposure discussion: https://github.com/WICG/js-self-profiling/issues/61 and https://github.com/WICG/js-self-profiling/pull/89

### Feedback so far

- Multi-stakeholder feedback:
  - Chromium comments: Positive — driving the implementation and Origin Trial. ChromeStatus: https://chromestatus.com/feature/5201297767792640
  - Mozilla comments: No signal yet. The base JS Self-Profiling API is not implemented in Gecko; no standards position has been requested for the markers extension.
  - WebKit comments: No signal yet. The base JS Self-Profiling API is not implemented in WebKit; no standards position has been requested for the markers extension.
  - Developer/implementer feedback: Interest from RUM/self-profiling consumers — Excel Online (Microsoft) and Datadog — who plan to evaluate the feature via the Chromium Origin Trial.
- Major unresolved issues with or opposition to this specification: None known. The one open design point is the cross-origin-isolation gating of the sensitive markers (script/gc/paint), under active security discussion in https://github.com/WICG/js-self-profiling/issues/61. No opposition has been raised.
- Status/issue trackers for implementations:
  - Chromium: https://chromestatus.com/feature/5201297767792640 and crbug.com/40800459
  - Spec PR: https://github.com/WICG/js-self-profiling/pull/89

### You should also know that...

1. **This is an incremental extension of an already-reviewed, shipped API.**
   The base JS Self-Profiling API went through TAG review in #366 and ships in
   Chromium. This proposal adds exactly one optional field — `marker` on
   `ProfilerSample` — labeling the user-agent activity at each sample
   (`script` / `gc` / `style` / `layout` / `paint` / `other`). No new entry point,
   no new way to start profiling, no change to the existing `Document-Policy:
   js-profiling` gate.

2. **The only new consideration is timing, and it's addressed by design.**
   - The full marker set is exposed **only in cross-origin-isolated documents**
     (COOP+COEP) via `[CrossOriginIsolated]` on the IDL member — the same
     isolation boundary already used for cross-origin-sensitive timing. In such a
     process a document can already observe process-wide signals (Spectre threat
     model, `performance.measureMemory()`, `WeakRef`), so `gc`/`paint`/`script`
     add no new leverage.
   - In **non-isolated** documents only `style` and `layout` are exposed. That
     timing is **already same-origin observable today** via forced synchronous
     reflow (`Element.getBoundingClientRect()` forces layout; `getComputedStyle()`
     forces style/layout). The markers provide the same class of information,
     sampled rather than forced — strictly less capability than pages already
     have. This mirrors the exposure model of **Long Animation Frames (LoAF)**.
   - Markers attributable to a specific document are attached only when that
     document is same-origin with the profiler.

3. **Timing / ask.** We plan a Chromium Origin Trial to gather field data from
   partners (Excel Online, Datadog). Feedback before or early in the trial would
   be most valuable; we're happy to iterate on the marker vocabulary and gating as
   part of standardization.

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1251


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1251
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1251@github.com>