@bokand what do you think about the latest change?

lgtm!

Feel free to merge. I'm not sure if additional reviews are required.

Hmm, I'm not an editor so not sure if that's ok - perhaps @smfr or @emilio could take a look?

Yes, I think we should wait their feedback :)

@smfr @emilio any comments?

I have a few thoughts, mainly about potential for user fingerprinting based on how they generally use a foldable/multi-screen device.

First, on a device that's foldable but with no hinge gap (i.e. continuous foldable screen), does the number of segments change when the screen goes between some folded state and unfolded flat? At what fold angle does this occur? If so, this might be used to identify users based on their habits of using the device fully unfolded or partially folded. This may also be used to estimate whether the user is paying full attention to the screen (fully unfolded) or is using it in a more glanceable fashion (partially folded), which may provide a signal to malicious content about when it can put things on the screen. Combined with device orientation data, this could be used to obscure activity on the less visible screen segment.

Second, there are potentially two additional means by which screen segment data could leak per-user fingerprintable data. If an OS allows the user to position a window freely in a way that spans screens, the segments API is way to leak the window position (the segment geometry would change based on window position). This is akin to desktop browsers exposing window.screenX/screenY which can be very user-specific. In addition, even with non-draggable windows but modifiable browser UI including toolbars, the segments would leak information about the UI/toolbar geometry.

The number of segments changes when the screen goes between the folded state and unfolded flat indeed. That's the essence of the API in the first place which is the same goal than the CSS MQs added in MQ Level 5. Here we're just basically providing the same functionality to JavaScript developers where CSS isn't a good fit (e.g. Canvas based content).

I think we need to take a step back here. User is expected to pay full attention when the device is in a folded state. The entire idea of the form factor is to provide bigger screen estate for content when the device is half folded and the keyboard detached. Even on smaller foldable form factors like smartphones typically content author will display a split ux. Have a look here to see various pictures of devices in action. There is also plenty of pictures online showcasing the Samsung foldables with their split UX ideas.

Regarding the potential fingerprinting, on Chromium browser segments are only returned when the browser window is in fullscreen or maximized, this is an implementation choice which we can decide to standardize or not. We did not hear from content authors the need to get segments when the window isn't maximized and floating around. As a clarification the browser window is not resized when changing state (e.g. folded to unfolded) but could be if the keyboard is docked for example.

I want to emphasize that the segments are defined in client coordinates (so adjusted to zoom factor and so forth) therefore relative to the viewport. I'm not sure how much information they would "leak" provided that say top segment + bottom segment will be equivalent to the inner height/width of the viewport.

Could you use these APIs to fingerprint that it's a folded device? Yes sure but again today you can do that by checking the window dimensions because they have not so common sizes (including for example Android where the dimensions are off for a tablet and a typical phone). Can you use these APIs to fingerprint a specific foldable model? Likely no because many of them share the same panel dimensions/sizes (phone or not) but again even if one had an exotic panel, they add nothing more than what I could already derive from the viewport size.

Thanks for your comments. I'll be happy to clarify more if you need so.

Adding new features (or substantially changing existing ones) requires CSSWG approval, not just editor approval... it doesn't seem like #9237 has that?

I believe it doesn't have approval (at least I didn't request but I'm not sure what MSFT did in the past). The CSS equivalent (MQs) is already in https://drafts.csswg.org/css-env-1/#viewport-segments and MQ Level 5 (https://www.w3.org/TR/mediaqueries-5/#mf-horizontal-viewport-segments). It's essentially the exact same feature, just at a JS level. Anyway, how do I request such approval?

Privacy section in the explainer indicates that segments will return null when called from within an iframe and explains how this prevents using the API as a fingerprinting vector from cross origin iframes.

A concern I have is accessing the segments through CSS media queries. Having CSS API in iframes might enable this type of fingerprinting. Is disabling CSS media queries for the segments feasible?

Privacy section in the explainer indicates that segments will return null when called from within an iframe and explains how this prevents using the API as a fingerprinting vector from cross origin iframes.

A concern I have is accessing the segments through CSS media queries. Having CSS API in iframes might enable this type of fingerprinting. Is disabling CSS media queries for the segments feasible?

Do we have precedence in doing that? I couldn't find anything in CSS specifications where certain CSS features are restricted to iframes, especially in the MQ/CSS env context but the domain is vast so I could have been missing something.

But again, the real question is whether the fingerprinting is really that big of an issue if segments are just subdivisions of the total viewport size. Foldables already have exotic viewport size when unfolded so they can be identified already but as more devices are in the market, targeting a specific device is becoming harder as they share panel dimensions so segments definition as well.

You could use this to detect how the device is being used (folded vs not) but the Device Posture API already reveal that. One could argue that in some way it is like the pointer MQ which is dynamic and exposing whether a device with detachable keyboard has it connected or not, also revealing how the device is being used.

Yes, it does add a bit of entropy but nothing that couldn't be derived from the viewport size today (or even combining with other APIs) but I'm open to discussing this further.

I am not aware of such a precedence. I agree with your arguments.