Intent to Ship: Expose coarsened cross-origin renderTime in elment timing/LCP (regardless of TAO)

[Chromestatus]

Contact emails

nrose...@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 (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., 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.

[Yoav Weiss (@Shopify)]

On Wednesday, November 13, 2024 at 1:14:43 PM UTC+1 Chromestatus wrote:

Contact emails nrose...@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

I agree that given the lack of API shape changes, no TAG review is required.

 

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.

Have y'all done some outreach?

 

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

I'm guessing this should be "yes"?

[Noam Rosenthal]

On Wed, Nov 20, 2024 at 3:35 PM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

On Wednesday, November 13, 2024 at 1:14:43 PM UTC+1 Chromestatus wrote:

Contact emails nrose...@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

I agree that given the lack of API shape changes, no TAG review is required.

 

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.

Have y'all done some outreach?

Yes, we've discussed this with RUM providers in 1:1, in social media posts, Slack, and also on the WebPerfWG.

Will reach out again close to shipping time. 

 

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)? No

I'm guessing this should be "yes"?

 

Oops, yes. updated the chromestatus entry.

 

[Alex Russell]

LGTM1 with questions:

• why was the 4ms threshold chosen?
• can you please send the TAG an FYI?
• presumably this works with all images, CORS'd or not?

Thanks

[Noam Rosenthal]

On Wed, Nov 20, 2024 at 4:29 PM Alex Russell <sligh...@chromium.org> wrote:

LGTM1 with questions:

• why was the 4ms threshold chosen?

It's half of the current highest frame-rate in the field (8ms), which seemed like the appropriate *minimum* value for coarsening.

• can you please send the TAG an FYI?

Already done that as part of a different TAG review for a feature that comes on top of this one:

https://github.com/w3ctag/design-reviews/issues/1013

Seemed reasonable to have this as one discussion for TAG, even though from a shipping point of view it's a separate flag etc.

• presumably this works with all images, CORS'd or not?

Correct. The protection is now based on cross-origin isolation and not on a per-resource basis, and would take place if there are no images at all.

[Domenic Denicola]

On Wed, Nov 13, 2024 at 9:14 PM Chromestatus <ad...@cr-status.appspotmail.com> wrote:

Contact emails

nrose...@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.

I think it would be worth asking for a standards-position specifically for the exposing-cross-origin change, as it has security implications and getting each implementation's perspective would be valuable.

Alternatively, if you have recorded Working Group minutes or a spec PR where a Firefox representative was present for consensus on this change, that'd work for me too.

 

--
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+...@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.

[Noam Rosenthal]

I think it would be worth asking for a standards-position specifically for the exposing-cross-origin change, as it has security implications and getting each implementation's perspective would be valuable.

Alternatively, if you have recorded Working Group minutes or a spec PR where a Firefox representative was present for consensus on this change, that'd work for me too.

Sure! We talked about presentation times in detail, including this coarsening in particular and the reasoning for it, in the last WebPerfWG call. Minutes available in this link. We've also discussed the TAO thing in particular here. 

[Domenic Denicola]

Thanks. Unfortunately I can't quite find the kind of clearly-supportive Gecko statements I'm looking for. Your first link (regarding the new timestamps) includes 

• Michal: Can Mozilla folks confirm the statements RE the timestamps?

• .. end time of event timing for “duration” and LCP, is it marking the handover or the presentation time?

• Bas: I believe it’s correct, but not 100% sure

• Michal: Would you be comfortable exposing both timings?

• Bas: I’m inclined to say yes. Maybe there are security and privacy concerns?

and the second (regarding no longer requiring TAO) includes

• Yoav: Sean you’ll kick off convo on Mozilla side?

• Sean: Yes

• … I’ll comment in the issue

Neither of those were the kind of "Resolved: everybody is OK with this precise design" I was hoping for.

Given that, maybe it'd be best to just file a Mozilla standards-positions request?

 

[Noam Rosenthal]

There was quite a bit more than those quotes, but that's fair.

  

Given that, maybe it'd be best to just file a Mozilla standards-positions request?

Done, https://github.com/mozilla/standards-positions/issues/1128

updated https://chromestatus.com/feature/5128261284397056 

[Yoav Weiss (@Shopify)]

LGTM2

[Rick Byers]

LGTM3

--

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+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b67b2ee4-7951-4a5f-9899-bc2bc4576b18n%40chromium.org.