The following considerations are taken from the W3C Security and Privacy Self-Review Questionnaire.
The answers pertain to the Initiating Multi-Screen Experiences enhancement. That explainer contains pertinent Security Considerations and Privacy Considerations sections.
See security_and_privacy.md for answers pertaining to the underlying Window Management API.
2.1 What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?
This feature enhancement does not expose any additional information; see the base API's corresponding answer.
2.2 Do features in your specification expose the minimum amount of information necessary to enable their intended uses?
This feature enhancement does not expose any additional information; see the base API's corresponding answer.
2.3 How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?
No additional PII is collected; see the base API's corresponding answer.
This feature enhancement does not expose any additional sensitive information; see the base API's corresponding answer.
2.5 Do the features in your specification introduce new state for an origin that persists across browsing sessions?
This feature enhancement does not introduce any additional state that persists across browser sessions. The proposed capability to open a new companion window is limited by the transient activation duration, and fullscreen companion windows left open when a browsing session ends may be restored by the user agent at the start of the next browsing session, in the same manner as any other windows managed by the user agent. See the base API's corresponding answer
2.6 Do the features in your specification expose information about the underlying platform to origins?
No additional information is exposed; see the base API's corresponding answer.
No; the use of the platform's window manager APIs to open and place windows using this enhancement is essentially equivalent to the use of the same platform APIs without this enhancement.
No additional access is enabled; see the base API's corresponding answer.
No; see the base API's corresponding answer.
No additional access is allowed; see the base API's corresponding answer.
2.11 Do features in this specification allow an origin some measure of control over a user agent’s native UI?
No; see the base API's corresponding answer.
None; see the base API's corresponding answer.
2.13 How does this specification distinguish between behavior in first-party and third-party contexts?
The capability is currently limited to a same-frame context, whether that pertains to the first-party top-level context, or a third-party context of an embedded frame. The frame making the initial fullscreen request will only be granted the proposed capability when it has the required permission (and permission policy). See the base API's corresponding answer.
2.14 How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
The behavior should be the same as for regular mode, except that the user agent should not persist permission data and should request permission every session. See the base API's corresponding answer.
2.15 Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
Yes; see the base API's corresponding answer.
No; see the base API's corresponding answer.
This capability can only be triggered from a "fully active" document.
Perhaps "What usable-security considerations does this feature raise? (e.g. risks related to spoofing or phishing)". This topic is considered thoroughly in the proposal's Security Considerations section.