https://www.w3.org/TR/security-privacy-questionnaire/
No.
No.
3.3 Does this specification introduce new state for an origin that persists across browsing sessions?
No.
As not all device types may support a "lock" state, detecting such a state provides some additional distinguishing information about the user's device (i.e. potentially one bit of entropy for fingerprinting), but as this correlates with the native platform this is generally inferrable from information exposed by the user agent header already.
3.5 Does this specification expose any other data to an origin that it doesn’t currently have access to?
Yes - the status of a "screen lock" or equivalent is not detectable by script today - other than e.g. Wake Lock to detect the absence.
Detection of "idle" vs. "active" can be done by script today by watching for UI events, but this is restricted to events within windows/frames controlled by the origin.
The "idle" state can be described as "time since last user interface event" and is global state which, with this API, can be observed cross-origin. In one hypothetical attack, with sub-second detection it would be possible to infer keystrokes and thus guess passwords being entered in other windows. For this reason, idle time detection must be appropriately coarse. In another attack scenario different origins could collaborate to corrolate idle state change events on the back-end, allowing identification of a user session across origins. For this reason, this capability must be limited to a small set of trustworthy origins by limiting it to top-level frames with notification permission.
No.
No.
Not directly. A device may use sensors to control lock state (e.g. proximity sensor to lock, fingerprint sensor to unlock) but the sensor data itself is not exposed.
3.9 Does this specification allow an origin access to aspects of a user’s local computing environment?
See the answer to 3.5 above. The user's idle state is an aspect of their local computing environment which extends beyond the boundaries of a single site.
No.
No.
No.
This capability is not allowed in third-party contexts.
This capability should be disabled in "incognito" modes to avoid exposing the same global state to two content inside and outside of "incognito" mode simultaneously.
No.
Not yet!
TODO: Make sure this is included when the spec is written.
No.