Contact emails nrosent...@chromium.org, mmo...@chromium.org
Explainer https://github.com/w3c/paint-timing/blob/main/presentation-timestamps.md#security--privacy-self-review Specification https://w3c.github.io/paint-timing/#mark-paint-timing Design docs https://docs.google.com/document/d/1VxgMf1wlWzB4ViAW4ohkOe3AT0wQZKk7hC3IVq-cuw0/edit?tab=t.0#heading=h.fmic3y1ir4 Summary All element-timing and LCP performance entries would have a non-zero renderTime, even if they are cross-origin without Timing-Allow-Origin. All presentation timestamps (renderTime, paint timing start time, event timing end time) will be coarsened to a 4ms multiple to mitigate the risk of reading cross-origin image information. Blink component Blink>PerformanceAPIs TAG review None TAG review status Not applicable Risks Interoperability and Compatibility This would un-zero metrics in RUM dashboards, which is generally positive. The coarsening might move LCP/FCP metrics by ~2ms in average, which RUM providers should be notified on. Gecko: Positive (https://github.com/mozilla/standards-positions/issues/191) Firefox are implementing LCP, however the current way render timing works (and the reason it needs to be coarsened) is implementation specific and not part of the spec. WebKit: N/A Safari currently does not expose precise render times, and does not intend to. Web developers: No signals Other signals: This was discussed in the WebPerfWG. See minutes: https://docs.google.com/document/d/1tw9QTHWvXg-loG6qaeeosOXTCeH41wst6MehQsc3WwM/edit?tab=t.0#heading=h.xlke2hcqy65x Security This exposes information that was not directly exposed before - render time of an image - however it was obtainable in other ways, by rendering a same-origin and cross-origin image in the same frame. By coarsening render times further, we improve on this situation despite the explicit exposure of that timestamp. 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? None Debuggability None Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)? No Is this feature fully tested by web-platform-tests? Yes https://wpt.fyi/results/largest-contentful-paint?label=experimental&label=master&aligned and https://wpt.fyi/results/element-timing?label=experimental&label=master&aligned had to be modified for this. Flag name on about://flags ExposeCoarsenedRenderTime Finch feature name ExposeCoarsenedRenderTime Requires code in //chrome? False Tracking bug https://issues.chromium.org/issues/373263977 Estimated milestones Shipping on desktop 133 Shipping on Android 133 Shipping on WebView 133 Anticipated spec changes Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (eg links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (eg, changing to naming or structure of the API in a non-backward-compatible way). Removing TAO restriction in paint-timing. Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5128261284397056?gate=5150397008969728 Links to previous Intent discussions Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/670d4c25.2b0a0220.137ef7.096d.GAE%40google.com This intent message was generated by Chrome Platform Status. -- 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 blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67349825.2b0a0220.3644d.0402.GAE%40google.com.
