Privacy section doesn't explain measures enough

[jonathanKingston]

Because VirtualKeyboard APIs may reveal some aspects about layout of user's VK, user agents must ensure that no extra information is exposed to the script that it already has through existing APIs. To mitigate potential security and privacy risks, browsers are expected to follow best practices described below.

This doesn't explain or suggest solutions the user agent could protect the input sizing. My understanding of the risks here are that the users language and perhaps other preferences (like emoji defaults, text prediction, font size etc) can all become a fingerprintable vector and increase the risk of a user being tracked.

This is new information that a page can't accurately get already right?

User Agent MUST only allow hide() and show() methods to be called in a Secure Context.

All new APIs should be gated this way does this need calling out when the webidl states this?

I also think the CSS properties must have the same treatment despite this perhaps being a first for CSS.

User Agent MUST only allow overlaysContent to be set in a secure, top-level browsing context.

Is there not a risk that the top level context can discover if the input is focused and being typed in? This potentially increases the risk of clickjacking.

Should this not only be exposed to the context that has the users focus rather than the top level?

[snianu]

My understanding of the risks here are that the users language and perhaps other preferences (like emoji defaults, text prediction, font size etc) can all become a fingerprintable vector and increase the risk of a user being tracked.

VK geometry doesn't reveal the layout of the keyboard i.e. it doesn't say anything about the type of the keyboard used by the user like the Emoji panel, handwriting recognition panel etc. It's just a rectangle that is an intersection of the keyboard rectangle reported by the OS with the layout viewport. Currently, this information can be derived from visual viewport(that resizes when keyboard comes up) & the layout viewport, so no additional information is exposed via this API.

All new APIs should be gated this way does this need calling out when the webidl states this?

Yes, it is mentioned in the webidl, but calling out explicitly in the security section makes it a MUST have rather than MAY.

Is there not a risk that the top-level context can discover if the input is focused and being typed in?

With some heuristics yes, but a web author can already derive that info using the layout & visual viewports, DOM key events etc so no new information is being exposed via this API.

Should this not only be exposed to the context that has the users focus rather than the top level?

The reason why we want to expose it to iframe element is described here in the explainer. If the main frame has focus, then it needs the intersection of the VK rectangle with the main frame document so it knows what parts of the page are occluded by the VK.