style_layout_duration_security_privacy_questionnaire.md

Self-Review Questionnaire: Security and Privacy

styleDuration, layoutDuration, forcedStyleDuration, and forcedLayoutDuration attributes

Answers to the W3C Security and Privacy Self-Review Questionnaire for the newly added timing duration attributes in the Long Animation Frames API.

These attributes break down existing aggregate timing into finer-grained style and layout components:

• PerformanceLongAnimationFrameTiming.styleDuration / layoutDuration: Time spent in style recalculation and layout during the rendering phase of a long animation frame.
• PerformanceScriptTiming.forcedStyleDuration / forcedLayoutDuration: Time spent in synchronous (forced) style recalculation and layout triggered during script execution (e.g., by calling getComputedStyle() or getBoundingClientRect()).

These complement the existing forcedStyleAndLayoutDuration (which is their sum) and the existing styleAndLayoutStart timestamp.

2.1. What information does this feature expose, and for what purposes?

These attributes expose a breakdown of time already accounted for in the existing API into style vs. layout components. The purpose is to help developers diagnose why a long animation frame occurred — specifically, whether the bottleneck is style recalculation, layout, or both — so they can apply targeted optimizations.

• styleDuration and layoutDuration break down the rendering phase duration that was already bounded by the existing styleAndLayoutStart and the frame's end time.
• forcedStyleDuration and forcedLayoutDuration break down forcedStyleAndLayoutDuration, which is already exposed.

No fundamentally new categories of information are exposed. The data is a finer-grained decomposition of durations that are already observable from the existing Long Animation Frames API.

2.2. Do features in your specification expose the minimum amount of information necessary to implement the intended functionality?

Yes. The attributes expose only the duration of style and layout work. They inherit all the existing minimization measures of the Long Animation Frames API: the 50ms frame threshold, the 5ms script threshold, and 1ms granularity of attribute timings. The separate style and layout durations are the minimum information needed to distinguish between these two common performance bottlenecks.

2.3. Do the features in your specification expose personal information, personally-identifiable information (PII), or information derived from either?

No.

2.4. How do the features in your specification deal with sensitive information?

These attributes do not expose sensitive information.

2.5. Does data exposed by your specification carry related but distinct information that may not be obvious to users?

The style and layout durations could vary based on the contents of cross-origin styles or the operations performed by cross-origin scripts. This information is already somewhat observable for the page embedding them (e.g. by calling getComputedStyle() or getBoundingClientRect().

2.6. Do the features in your specification introduce state that persists across browsing sessions?

No.

2.7. Do the features in your specification expose information about the underlying platform to origins?

Style and layout durations may vary by hardware speed. However, this is no different from the existing duration, styleAndLayoutStart, and forcedStyleAndLayoutDuration attributes. The new attributes are a decomposition of already-exposed timing, not a new source of platform information.

2.8. Does this specification allow an origin to send data to the underlying platform?

No.

2.9. Do features in this specification enable access to device sensors?

No.

2.10. Do features in this specification enable new script execution/loading mechanisms?

No.

2.11. Do features in this specification allow an origin to access other devices?

No.

2.12. Do features in this specification allow an origin some measure of control over a user agent's native UI?

No.

2.13. What temporary identifiers do the features in this specification create or expose to the web?

None.

2.14. How does this specification distinguish between behavior in first-party and third-party contexts?

No distinction between first- and third- party.

2.15. How do the features in this specification work in the context of a browser's Private Browsing or Incognito mode?

No special handling for Incognito/Private modes.

2.16. Does this specification have both "Security Considerations" and "Privacy Considerations" sections?

Yes. The Long Animation Frames specification includes a combined "Security & privacy considerations" section. These new attributes do not introduce concerns beyond those already documented there.

2.17. Do features in your specification enable origins to downgrade default security protections?

No.

2.18. What happens when a document that uses your feature is kept alive in BFCache (instead of getting destroyed) after navigation, and potentially gets reused on future navigations back to the document?

No rendering or script execution occurs while in BFCache, so no new values would be generated. Existing entries in the performance timeline buffer persist as part of the document's state and are available upon restoration. No new concerns beyond the existing Long Animation Frames behavior.

2.19. What happens when a document that uses your feature gets disconnected?

The same behavior as the existing Long Animation Frames API — the spec checks for fully active and non-hidden documents before recording timing info, and in-progress frame timing is discarded if the document becomes inactive. These new attributes are simply additional fields on the same structs and do not change disconnection behavior.

2.20. Does your spec define when and how new kinds of errors should be raised?

No.

2.21. Does your feature allow sites to learn about the user's use of assistive technology?

No. Style and layout durations reflect page complexity and CSS/DOM structure, not assistive technology usage.

2.22. What should this questionnaire have asked?

Nothing comes to mind.