Isn't this API a privacy issue?

[KOLANICH]

I guess the standard should prescribe the mitigations, even if they are obvious.

[bokand]

In what sense? The API doesn't provide any information about the device so I don't think it can be used for fingerprinting.

The only new capability is that the website could detect which part of the page a user zooms into but I'm not sure that's really significant. Am I misunderstanding?

[KOLANICH]

It is meant to provide info about screen keyboards height on mobile devices. It can be used to identify keyboard. Some keyboards have it adjustable, so it can give even more information.

[bokand]

I guess that would depend on the implementation but, at least as it currently works on Chrome, it doesn't. The keyboard actually resizes the page so that information was already available in window.innerHeight.

Chrome did have plans to make the keyboard resize only the visual viewport - that never happened. But even in that case, this wouldn't be providing any new information that the platform wasn't already providing.

Not opposed to adding a note to implementors about this in the spec though.

[KOLANICH]

But even in that case, this wouldn't be providing any new information that the platform wasn't already providing.

Could you elaborate what else API can be used to capture that info?

[bokand]

On Android Chrome today, if you open the keyboard on a page today, you'll get a resize event [addEventListener('resize', ...)]. At that point the window.innerHeight will shrink by the size of the keyboard. So you can use innerHeight to detect the height of the keyboard already.

[KOLANICH]

Thank you for the info, definitely need to test if this is the case for Firefox with privacy.resistFingerprinting=true.

[Thorin-Oakenpants]

window.innerHeight will shrink by the size of the keyboard. So you can use innerHeight to detect the height of the keyboard already

In Firefox there is a anti-fingerprinting mechanism called letterboxing, which restricts the viewport to stepped sizes: height would typically be in 100px steps. This would "bucketize" all keyboard heights into a very few sizes heights: i.e all keyboards eating 301 to 400 pixels in height would all calculate as 400px used

Edit: this is experimental and hidden behind a pref
Edit2: this is not yet implemented in mobile

[KOLANICH]

The important thing is how exactly is it going to be bucketed. There are 3 options, all are bad.

1. do real letterboxing. Inacceptable - screen space is too scarce on mobiles.
2. just round the visibleViewport sizes returned by JS to a higher value. Can be easily countermeasured - a malicious webmaster can put some essential website controls bottom to an upper bound of keyboard. Then if user's browser has lied about a keyboard, these controls will go under actual keyboard. Though it may be beneficial - these controls will likely waste screen space.
3. just round the visibleViewport sizes returned by JS to a lower value. Then the webmaster can create opaque elements, placed to the space claimed to be screened by a keyboard, effectively transforming the situation to 1.

So, IMHO the best action here is to abolish this spec and not to implement it at all.

[karlcow]

@Thorin-Oakenpants do you have a bug reference on bugzilla for this.

[karlcow]

I found this one https://bugzilla.mozilla.org/show_bug.cgi?id=1407366

[KOLANICH]

https://bugzilla.mozilla.org/show_bug.cgi?id=1575690