Skip to content

security-review.md

Latest commit

 

History

History
166 lines (94 loc) · 6.12 KB

security-review.md

File metadata and controls

166 lines (94 loc) · 6.12 KB

Security Questionnaire

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

Container Timing exposes performance timing information about developer-annotated DOM containers.

Specifically it exposes:

  • Timing information about when a container’s content is rendered or becomes visible.
  • The container’s identifier (provided by the developer via the containertiming attribute).
  • Standard PerformanceEntry metadata (e.g. timestamps relative to navigation start).

The purpose of this information is to allow developers to measure rendering performance of meaningful page sections, enabling attribution of user-perceived performance to specific UI containers.

The feature is intended for performance monitoring and diagnostics, similar to APIs such as Performance Timeline, LCP, and Element Timing.

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

Yes.

Container Timing exposes only:

  • Timing data already observable within the document lifecycle
  • A developer-provided container identifier
  • Standard PerformanceEntry metadata

The API does not expose additional layout details, DOM structure, or user-specific information beyond what is already accessible to scripts running in the page. The design intentionally mirrors existing Performance Timeline APIs to avoid introducing new high-entropy surfaces.

Do the features in your specification expose personal information, PII, or information derived from them?

No.

Container Timing exposes only rendering timing data associated with DOM elements. The API does not expose:

  • User identifiers
  • Network information
  • Input data
  • Personal or behavioral information

Any identifiers associated with containers are developer-defined strings supplied in markup.

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

The API does not expose sensitive information.

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

The API exposes timing information that may indirectly reflect page structure or rendering behavior, similar to other performance APIs.

However:

  • This information is already available to same-origin scripts through other performance APIs.
  • The feature does not expose cross-origin rendering information or new system-level signals.

Therefore the risk of exposing additional unintended information is minimal.

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

No

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

No additional platform information is exposed.

The API provides render timing information only, similar to other performance metrics already exposed through the Performance Timeline.

It does not reveal:

  • device hardware characteristics
  • OS information
  • GPU information

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

No

Do features in this specification enable access to device sensors?

No

Do features in this specification enable new script execution or loading mechanisms?

No

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

No

Do features in this specification allow control over a user agent’s native UI?

No

What temporary identifiers do the features create or expose?

The feature exposes developer-defined container identifiers via the containertiming attribute.

These identifiers:

  • Are provided by the page author
  • Are scoped to the document
  • Do not persist beyond the page lifecycle
  • Are not generated by the user agent

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

Container Timing operates within the document context that defines the annotated elements.

Third-party scripts running in the page would only have access to entries already observable by scripts in that context. The API does not introduce new cross-origin information exposure.

How do the features behave in Private Browsing / Incognito mode?

The feature behaves the same as other Performance Timeline APIs in private browsing contexts.

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

Yes. The specification includes a section discussing:

  • privacy impact of exposing rendering timing information
  • alignment with existing Performance Timeline privacy constraints.

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

No

The API does not alter:

  • same-origin policy
  • CSP
  • sandboxing
  • cross-origin isolation
  • network security policies

What happens if a document using the feature is kept alive in BFCache?

If a document is placed into the BFCache and later restored:

  • Performance entries behave consistently with existing Performance Timeline semantics.
  • No additional state or identifiers persist beyond the document lifecycle.

What happens when a document using the feature is disconnected?

Once the document is destroyed:

  • Performance entries are discarded
  • No persistent state remains

Does your spec define when and how new errors should be raised?

No. The feature follows existing error semantics of:

  • DOM attributes
  • PerformanceObserver

Invalid usage results in behavior consistent with existing platform APIs.

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

No.

The feature exposes only render timing information and does not interact with accessibility APIs.

What should this questionnaire have asked?

No additional security or privacy concerns have been identified beyond those already covered by the questionnaire.