JS Self-Profiling API (including the Markers extension)

[monica-ch]

WebKittens

@marcoscaceres @annevk

Title of the proposal

JS Self-Profiling API (including the Markers extension)

URL to the spec

https://wicg.github.io/js-self-profiling/

URL to the spec's repository

https://github.com/WICG/js-self-profiling

Issue Tracker URL

No response

Explainer URL

No response

TAG Design Review URL

w3ctag/design-reviews#1251

Mozilla standards-positions issue URL

mozilla/standards-positions#477

WebKit Bugzilla URL

No response

Radar URL

No response

Description

The JS Self-Profiling API lets a web app profile its own JavaScript execution using a sampling profiler. A document opts in via the Document-Policy: js-profiling header, then constructs a Profiler with a sampling interval and sample-buffer limit; calling stop() returns a ProfilerTrace (a deduplicated set of frames, stacks, and timestamped samples) that the app can upload for analysis of real-user performance. The base API is implemented in Blink and shipped in Chromium; it is not currently implemented in Gecko or WebKit. It has a Mozilla standards-position request (mozilla/standards-positions#477) and a TAG review (#366).

We are now extending the API with markers: an optional marker field on ProfilerSample indicating the user-agent activity running when each sample was taken. This is an incremental addition — no new entry point and no change to how profiling is started or gated. Exposure is gated on cross-origin isolation:

• In a cross-origin isolated document (COOP+COEP), the full marker set is exposed: script, gc, style, layout, paint.
• In a non-isolated document, only style and layout are exposed; script, gc, and paint are omitted.

This keeps the markers that could reveal cross-process / cross-origin timing (notably gc, and script/paint activity) behind cross-origin isolation, while still exposing the rendering markers that a document can already infer about itself. It is currently being validated via a Chromium Origin Trial (Chrome M153–M161). Spec change: WICG/js-self-profiling#89.

@marcoscaceres suggested filing a WebKit position (TAG thread). We'd welcome WebKit's position and any questions on both the base API and the markers extension. Happy to provide additional detail on the exposure/gating design.

[bkardell]

I happened to notice just now that @rniwa had negative comments on the original moz request mozilla/standards-positions#477 - are they still applicable?

[monica-ch]

Thanks @bkardell, checking @rniwa's four 2021 points (mozilla/standards-positions#477) against the current design. Short version: lazy mode narrows startup overhead and the marker's cross-origin exposure is deliberately constrained, but active CPU/memory cost, lost cross-origin diagnostic utility, and the JSC-specific side-channel all remain open.

1. CPU cost: The API is opt-in per-document, and a new lazy mode (Add js-profiling-mode=eager|lazy Document-Policy for deferred initialization WICG/js-self-profiling#87, merged) —  Document-Policy: js-profiling-mode=lazy  — lets a UA defer warm-up (in Blink, JIT-event enumeration) until the first  Profiler  is constructed. That's a non-normative hint that reduces load-time cost (and can shift it to INP), but it doesn't touch rniwa's core point: once profiling starts, sampling cost (backtrace gathering, any de-optimization) is engine-specific and may apply in full to JSC. Opt-in bounds who pays, not whether a consenting page's users are slowed — so this remains largely applicable.

2. Memory cost: Also unresolved for active sessions: trace buffer + backtrace storage are real costs (bounded only by the caller's sample-buffer limit); lazy mode doesn't help. Applicable, magnitude engine-specific.

3. Sampling other origins: The base API samples only the calling context's own execution and never exposes cross-origin stacks — satisfying the security half of the concern by exclusion, but confirming the utility half: it can't diagnose the cross-origin long tasks (e.g. ads) rniwa cited.

4. Engine/JIT side-channels (attacking the user's own device): Separate from 3, and the marker gating does not resolve it — COI governs the marker channel, not JSC's compile-time/JIT-optimization state (note Chromium also doesn't clamp sample timestamps today). rniwa said the  performance.now() -parity argument "isn't necessarily the case for JSC," and no current design change speaks to that. This is the principal open question we'd value WebKit's input on — ideally just whether the concern still stands and whether mitigation classes can be discussed without disclosing JSC internals.

Marker gating (rationale, not settled).  script / gc / paint  are exposed only under cross-origin isolation; non-isolated documents see just  style/layout  (rest dropped, not coarsened). Per WICG/js-self-profiling#87, the COI threat model already assumes a Spectre-capable attacker may read renderer-process memory (public or opted-in resources), so these markers were judged not to add materially more capability; martinthomson cited process isolation as the standard mitigation.  paint stays behind COI for the same reason LoAF omits it (noamr — paint-timing has since moved toward presentation times clamped to 4ms); attributable markers are also scoped same-origin with the Profiler. This model ships in Chromium behind the Origin Trial (M153–M161), but the normative text is still in open PR WICG/js-self-profiling#89 — so it's open to iteration.

Happy to go deeper on any of these