On partners: Excel Online has confirmed they'll use the Origin Trial, with their integration work penciled in for September. Datadog has asked to participate as soon as registration opens.
@Chris Harrelson, Thanks for flagging this. Accounting for the 2-week release cadence, I've set the OT to run 16 weeks (8 milestones at 2 weeks each). I've updated the start milestone to 153 and the end milestone to 161 in ChromeStatus accordingly. @Daniel Bratell - Agreed, we did exactly that here: the side-channel question was raised with Chrome security in Marker & security. · Issue #61 · WICG/js-self-profiling <https://github.com/WICG/js-self-profiling/issues/61>. The cross-origin-sensitive markers (gc, paint, script) are gated behind cross-origin isolation, where that visibility is already assumed under the Spectre model; style/layout are exposed without isolation only because their timing is already same-origin observable via forced reflow (getBoundingClientRect, getComputedStyle). Markers attach only when the responsible document is same-origin with the profiler, and cross-origin frames are stripped. On the new-timer question: it doesn't add a new clock, markers reuse the document's existing performance.now() time origin. What they add is attribution: each sample is labeled with what the engine was doing (script/gc/style/layout/paint), so you can slice a duration you can already measure into finer labels, not finer timing. The sampling rate is also bounded: the profiler produces at most one sample every 10 ms (16 ms on Windows), a requested sampleInterval is snapped up to a fixed base interval, so no page (or set of profilers) can sample more often, and samples fire on the engine's own cadence, not on page-controlled events, so they can't be aligned to a moment of the caller's choosing. So markers let you attribute time you can already observe, but don't provide a way to measure intervals any more finely than existing APIs already allow. Thanks, Monica. On Wednesday, August 5, 2026 at 9:48:37 AM UTC-7 Daniel Bratell wrote: > I don't consider it a showstopper for the experiment, but whenever we add > or change or improve timing functions or functionality we need to consider > if we have made timing attacks possible or simpler. Please highlight that > risk when you are in contact with privacy and security reviewers. > > /Daniel > On 2026-08-05 17:08, Chris Harrelson wrote: > > Please provide an end milestone for this trial. (Note: please take into > account that releases are switching to 2-week). > > On Tue, Aug 4, 2026 at 3:30 PM Chromestatus < > [email protected]> wrote: > >> *Contact emails* >> [email protected], [email protected] >> >> *Explainer* >> https://github.com/WICG/js-self-profiling/blob/main/markers.md >> >> *Specification* >> https://github.com/WICG/js-self-profiling/pull/89 >> >> *Design docs* >> >> https://github.com/WICG/js-self-profiling/blob/main/markers.md >> https://github.com/WICG/js-self-profiling/pull/89 >> >> *Summary* >> The JavaScript Self-Profiling API lets a web application sample its own >> call stacks to measure performance on real user devices. This feature adds >> an optional marker field to each captured sample that identifies the type >> of browser activity running when the sample was taken: script, gc, style, >> layout, paint, or other. A trace normally shows gaps between stacks that >> cannot be interpreted, markers let developers attribute that time to >> browser work happening outside their JavaScript, for example distinguishing >> script execution from style recalculation, layout, or a garbage collection >> pause, making slow traces easier to analyze and optimize. >> >> *Blink component* >> Blink>PerformanceAPIs >> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EPerformanceAPIs%22> >> >> *Web Feature ID* >> 4217 <https://webstatus.dev/features/4217> >> >> *TAG review* >> https://github.com/w3ctag/design-reviews/issues/1251 >> >> *TAG review status* >> Pending >> >> *Goals for experimentation* >> Validate that JS Self-Profiling markers provide actionable performance >> signal for large real-world web applications when collected from real >> users, and confirm the marker data flows correctly end-to-end through >> production RUM pipelines. Specifically, we want to learn: - Whether >> per-sample markers let developers attribute slow field traces to browser >> activity outside their JavaScript (rendering, style/layout, GC) and act on >> it. - Whether the sampled marker data is accurate and stable enough at >> production scale (real devices, real workloads) to drive optimization >> decisions. - Whether the API shape (ProfilerSample.marker) is ergonomic for >> existing self-profiling consumers to adopt with minimal code change. >> Interested partners include Excel Online, which will consume the trial to >> enrich its existing JS self-profiling telemetry, and Datadog, which >> collects JS self-profiling data as part of its RUM product. >> >> *Origin Trial documentation link* >> https://github.com/WICG/js-self-profiling/blob/main/markers.md >> >> *Risks* >> >> >> *Interoperability and Compatibility* >> *No information provided* >> >> *Gecko*: No signal >> >> *WebKit*: No signal >> >> *Web developers*: No signals >> >> *Other signals*: >> >> *Ergonomics* >> Low. Markers add a single optional marker field to the existing >> ProfilerSample, no new API surface or call pattern. The main ergonomic >> subtlety is graduated disclosure: style/layout are available everywhere, >> while script, gc, and paint appear only in cross-origin-isolated documents. >> The same profiling code therefore yields different marker sets depending on >> the document's isolation state, which could surprise developers who expect >> the full set. This degrades gracefully, a missing/absent marker is simply >> interpreted as idle/unknown, so it does not break existing traces, and >> analysis tooling can treat markers as best-effort annotations >> >> *Activation* >> Low to moderate. The feature is a small additive extension to the >> already-shipped JS Self-Profiling API, so adoption cost is minimal for >> developers already using it. The main activation barrier is that the >> restricted markers (script/gc/paint) require cross-origin isolation (COOP: >> same-origin + COEP: require-corp), which some large applications cannot >> easily deploy. This is mitigated by exposing the safe style/layout markers >> in non-isolated contexts, so developers get useful signal even without COI, >> and by the Origin Trial allowing partners to evaluate the feature on stable >> before committing to isolation. >> >> *Security* >> Moderate, and mitigated by design. Some browser work is shared across >> documents in a process, so exposing it could leak cross-origin timing: gc >> is not attributable to a single origin, and paint could act as a proxy for >> the render time of cross-origin opaque resources that fail a TAO check. To >> mitigate, script, gc, and paint markers are gated behind cross-origin >> isolation, in a COI process the document can already observe process-wide >> signals (Spectre threat model, performance.measureMemory, WeakRef), so >> these markers add no new leverage. style and layout are exposed without >> isolation because their timing is already observable through existing >> DOM/CSSOM APIs (getBoundingClientRect, getComputedStyle), consistent with >> Long Animation Frames. Markers attributable to a document are only attached >> when that document is same-origin with the profiler. Security discussion is >> tracked in https://github.com/WICG/js-self-profiling/issues/61 (Chrome >> security reviewed the COI-gated design in 2021, the non-isolated >> style/layout exposure is under active review). >> >> *WebView application risks* >> >> Does this intent deprecate or change behavior of existing APIs, such that >> it has potentially high risk for Android WebView-based applications? >> *No information provided* >> >> >> *Ongoing technical constraints* >> The restricted markers (script, gc, paint) remain permanently gated >> behind cross-origin isolation; only style and layout are exposed in >> non-isolated documents. Markers are best-effort, sampled annotations (≈10 >> ms interval), attached only when the responsible document is same-origin >> with the profiler — they are not a precise or guaranteed signal and must >> not be relied upon for correctness. >> >> *Debuggability* >> *No information provided* >> >> *Will this feature be supported on all six Blink platforms (Windows, Mac, >> Linux, ChromeOS, Android, and Android WebView)?* >> Yes >> >> *Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >> Yes >> >> https://wpt.fyi/results/js-self-profiling/tentative/marker-vm-state.https.html >> >> *DevTrial instructions* >> https://github.com/victorhuangwq/js-profiler-markers-demo >> >> *Flag name on about://flags* >> --enable-blink-features=ExperimentalJSProfilerMarkers >> >> *Finch feature name* >> JSSelfProfilingMarkers >> >> *Requires code in //chrome?* >> False >> >> *Tracking bug* >> https://issues.chromium.org/issues/40800459 >> >> *Estimated milestones* >> Origin trial desktop first 152 >> >> *Link to entry on the Chrome Platform Status* >> https://chromestatus.com/feature/5201297767792640?gate=5361868559482880 >> >> This intent message was generated by Chrome Platform Status >> <https://chromestatus.com>. >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a72681c.c91ea2f1.3ad85a.01ad.GAE%40google.com >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a72681c.c91ea2f1.3ad85a.01ad.GAE%40google.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8RKNxCE9Xtt%2B%3DzdyAfmA1OGqnFkv5gXpvTnggGeMTyNA%40mail.gmail.com > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8RKNxCE9Xtt%2B%3DzdyAfmA1OGqnFkv5gXpvTnggGeMTyNA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/278a8ad6-bc7d-48fb-9aa9-1bb0bad96c89n%40chromium.org.
