LGTM On Wed, Aug 5, 2026 at 1:59 PM 'Monica Chintala' via blink-dev < [email protected]> wrote:
> 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/278a8ad6-bc7d-48fb-9aa9-1bb0bad96c89n%40chromium.org?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%2Bw-_iOP47hCJt0QfW81d4hcrib2EG4MpohgUH5sbELfTug%40mail.gmail.com.
