Answers to Security and Privacy Questionnaire
No.
No.
3.3 Does this specification introduce new state for an origin that persists across browsing sessions?
No.
No.
3.5 Does this specification expose any other data to an origin that it doesn’t currently have access to?
No by default.
The proposed spec allows a frame to transfer its own activation state to a
target frame of a different origin through the new dictionary entry in
WindowPostMessageOptions. This is not a concern because of the following
reasons:
- By default no transfer takes places. The sender has to explicitly ask for a transfer when it needs.
- The sender frame is in full control here; a receiver frame of a rogue origin can't get the state without sender's action.
- If the sender wants, it can already expose to a target frame the fact that
user is interacting (or has interacted) with it (say, through a traditional
postMessage()).
No.
No.
No.
3.9 Does this specification allow an origin access to aspects of a user’s local computing environment?
No.
No.
No.
No.
No.
This would work in the "incognito" mode in the same way as in the "regular" mode.
No.
There is no privacy concerns here: the only user info that gets exposed to the
receiver frame is whether the user has interacted with a page. This info can be
exposed already through a traditional postMessage(), see Q3.5 above.
We don't see any security risk in the proposed spec. We have already considered possible security issues in the general idea of activation transfer (see here), and tweaked the design accordingly.
No.