Intent to Ship: Device Posture API

[Alexis Menard]

Contact emails

alexis...@intel.com

Explainer

https://github.com/w3c/device-posture
https://www.w3.org/TR/device-posture/#introduction

Specification

https://www.w3.org/TR/device-posture

Summary

This API helps developers to detect the current posture of a foldable device. The device posture is the physical position in which a device holds which may be derived from sensors in addition to the angle. From enhancing the usability of a website by avoiding the area of a fold, to enabling innovative use cases for the web, knowing the posture of a device can help developers tailor their content to different devices. Content can be consumed and browsed even when the device is not flat, in which case the developer might want to provide a different layout for it depending on the posture state in which the device is being used.

Blink component

Blink>FoldableAPIs

TAG review

https://github.com/w3ctag/design-reviews/issues/575

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

None

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/882)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/328)

Web developers: 

https://github.com/w3c/device-posture/issues/111#issuecomment-2363251667

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

Feature is disabled on WebView for now. See https://issues.chromium.org/issues/335314107 for more details.

Debuggability

Besides the usual DevTools debugging of the CSS and JavaScript API, a specific device has been added into the Device Emulation mode.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

The API will work on all the platforms but only Android and Windows will return posture information (other platforms do not have this category of devices)

Is this feature fully tested by web-platform-tests?

Yes

The tests aren't complete yet because we need integration with WebDriver to emulate posture changes. It's being worked on. https://github.com/web-platform-tests/wpt/tree/master/device-posture

Flag name on chrome://flags

device-posture

Finch feature name

kDevicePosture

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1066842

Sample links

https://github.com/foldable-devices

Estimated milestones

Shipping on desktop	131
Origin trial desktop first	125
Origin trial desktop last	128
DevTrial on desktop	95
Shipping on Android	131
Origin trial Android first	125
Origin trial Android last	128
DevTrial on Android	123

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5185813744975872?gate=6219681092599808

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/prHGPxF62i4
Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8c244153-79c4-483e-8449-4aca14b35636%40chromium.org

This intent message was generated by Chrome Platform Status.

[Domenic Denicola]

This looks like a really solid spec that has benefited from years of iteration and had good TAG review discussion. The fact that you specified and are working on WebDriver hooks to emulate posture changes during testing, and added DevTools integration, are more great signs of maturity. I'm excited to approve this.

The only blocker is that https://github.com/w3c/device-posture/issues/111 remains open and changing that after shipping would be a significant change. It sounds like your current plan is to expose this information across iframes. Can you confirm? If so, are you ready to close that issue and lock in the current state?

A more conservative plan would be to not expose the information across cross-origin iframes. You could then loosen that in the future, probably by introducing a permissions policy: either with a default allowlist of '*' to get the current behavior (but allow top frames to restrict), or a default allowlist of 'self' to keep the restriction by default (but allow top frames to share). Absent strong use cases for sharing cross-origin by default, that would be my suggestion.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/540e383c-1e1c-4918-9f10-c3fb2dd9bc19%40intel.com.

[Alexis Menard]

Hi,

Thanks for your approval.

I can confirm that the API is exposed to iframe through JS and CSS.

Concerning your suggestion I agree that we could put this behind a permission policy but unfortunately if the intent is to limit potential ephemeral fingerprinting then it will not help at all. In Chromium it's easy to gate the JS API behind a permission policy but there is no prior art of a CSS API being gated behind a permission policy (I may be wrong). So the iframe CSS code will still be parsed which would not impede accessing the posture. Finally one can just use JavaScript to query the posture using `matchMedia` so in order for this whole permission to truly block we would need to patch the CSS engine deep down.

I had this discussion with the PING and they agreed that we don't have any mechanism in place even CSS to support such a thing. There is a discussion which started few weeks ago between the PING and CSS WG. I believe that in the future this use case could come up for some other APIs especially when things are exposed through env variables. So unless there is some idea of a spec or update to permission policy spec I'm not sure if we should start modifying the CSS engine deeply.

Coming back to this API, to be honest I think the fingerprinting is very low risk, ephemeral and is going to be less and less relevant as more and more users are using foldables especially in the folded posture (remember that any other device including desktop returns the continuous posture).

Thanks.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra_U0%3DqYJnDGBM8Zm-yLh7XNT1tA1uKt1a6VzuDBHBdDYA%40mail.gmail.com.

[Ian Clelland]

On Mon, Oct 7, 2024 at 7:36 AM Alexis Menard <alexis...@intel.com> wrote:

Hi,

Thanks for your approval.

I can confirm that the API is exposed to iframe through JS and CSS.

Concerning your suggestion I agree that we could put this behind a permission policy but unfortunately if the intent is to limit potential ephemeral fingerprinting then it will not help at all. In Chromium it's easy to gate the JS API behind a permission policy but there is no prior art of a CSS API being gated behind a permission policy (I may be wrong). So the iframe CSS code will still be parsed which would not impede accessing the posture. Finally one can just use JavaScript to query the posture using `matchMedia` so in order for this whole permission to truly block we would need to patch the CSS engine deep down.

We've never shipped any CSS gating based on permissions policy, but we have experimented with it; in particular, we've released experimental policies to restrict the use of animations on properties which affect layout, and to restrict the values which can be used for the font-display property. These have since been removed from the code, as we're not pursuing those anymore, but the idea of controlling the CSS engine with permissions policy has been tried.

I'm not sure if the fact that this API is exposed through media queries makes this more complex, but from a spec perspective, as long as you can describe the behaviour in terms of what the current document is "allowed to use", then you should be able to express the right constraints to use permissions policy.

Ian

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOaK9AntwL_dhXaSvEHVAfoisf4fexB_tNTidO9BjqiWUxM2vQ%40mail.gmail.com.

[Alexis Menard]

On Mon, Oct 7, 2024 at 9:31 AM Ian Clelland <icle...@chromium.org> wrote:

On Mon, Oct 7, 2024 at 7:36 AM Alexis Menard <alexis...@intel.com> wrote:

Hi,

Thanks for your approval.

I can confirm that the API is exposed to iframe through JS and CSS.

Concerning your suggestion I agree that we could put this behind a permission policy but unfortunately if the intent is to limit potential ephemeral fingerprinting then it will not help at all. In Chromium it's easy to gate the JS API behind a permission policy but there is no prior art of a CSS API being gated behind a permission policy (I may be wrong). So the iframe CSS code will still be parsed which would not impede accessing the posture. Finally one can just use JavaScript to query the posture using `matchMedia` so in order for this whole permission to truly block we would need to patch the CSS engine deep down.

We've never shipped any CSS gating based on permissions policy, but we have experimented with it; in particular, we've released experimental policies to restrict the use of animations on properties which affect layout, and to restrict the values which can be used for the font-display property. These have since been removed from the code, as we're not pursuing those anymore, but the idea of controlling the CSS engine with permissions policy has been tried.

I'm not sure if the fact that this API is exposed through media queries makes this more complex, but from a spec perspective, as long as you can describe the behaviour in terms of what the current document is "allowed to use", then you should be able to express the right constraints to use permissions policy.

Interesting. I'll try to dig the CL just out of curiosity.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK_TSXKv4q4Zj%2B-iDr%3DEbdENuZbdpFqxaaNrqXn6ZgdYX%2BGEXw%40mail.gmail.com.

--

Alexis Menard
Software Engineer @ Intel

[Alex Russell]

It's unclear to me that this should have a permission.

LGTM1

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOaK9Am-Bas35FSfRbiFBcihOtrHYMMi6J_z7qfyjcMa8VQAqg%40mail.gmail.com.

[Domenic Denicola]

To be clear, I'm OK if the relevant standards body (i.e. the W3C Devices and Sensors WG) has decided that this does not require a permissions policy. But I would like it to be resolved one way or another before we approve this for shipping. Right now it is listed as an open issue in the spec, and it's one that will be hard to change after shipping, so per the "Anticipated spec changes" of our I2S template, I'd like to get that resolved.

[Yoav Weiss (@Shopify)]

+1 to either resolving this before shipping, or shipping a restricted version (not exposing this to cross-origin iframes at all, or adding a default `self` permission policy), which we'd be able to relax in the future if needed.

As there seems to be active debate happening on the issue, maybe we should let this discussion reach its conclusions?

Ian

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/540e383c-1e1c-4918-9f10-c3fb2dd9bc19%40intel.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra_U0%3DqYJnDGBM8Zm-yLh7XNT1tA1uKt1a6VzuDBHBdDYA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOaK9AntwL_dhXaSvEHVAfoisf4fexB_tNTidO9BjqiWUxM2vQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK_TSXKv4q4Zj%2B-iDr%3DEbdENuZbdpFqxaaNrqXn6ZgdYX%2BGEXw%40mail.gmail.com.

--

Alexis Menard
Software Engineer @ Intel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Alexis Menard]

Everyone,

Thanks for the feedback. Let's take a step back here. The issue mentioned here is one that *i* opened asking whether we should expose this to iframes or not. I wanted to hear feedback from the community: we heard they want it exposed. There isn't an ongoing discussion. 

Now the question is whether we want to put that behind a permission policy. Guarding the JS API behind a permission policy is trivial, the CSS part is not. I'm not against doing the work but we need to take a step back and evaluate why we would guard it behind a permission policy in the first place. The API only exposes two values: continuous and folded. Continuous is returned for *every* devices not a foldable (on all platforms) and when a foldable device is used flat. There is no fingerprinting value in this. When the device is folded there is a possibility of ephemeral fingerprinting (maybe?) where you could determine that it's a folded device across sessions. However, the posture can change (user generated) across browsing session defeating any tracking. What one could determine is if the device is a foldable and folded, however it's easy to determine that a device is a foldable just by using the viewport width/height and various other information. Knowing that the device is folded has no real value per se, at least I couldn't find any.

Finally requiring permission policy was not required by the TAG and PING during their respective reviews. We did discuss the issue with PING but after exposing the fact that the CSS would still leak the information and there wasn't any official CSS recommendation how to gate a CSS API then we did not get opposition in the review.

Ian

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/540e383c-1e1c-4918-9f10-c3fb2dd9bc19%40intel.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra_U0%3DqYJnDGBM8Zm-yLh7XNT1tA1uKt1a6VzuDBHBdDYA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOaK9AntwL_dhXaSvEHVAfoisf4fexB_tNTidO9BjqiWUxM2vQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK_TSXKv4q4Zj%2B-iDr%3DEbdENuZbdpFqxaaNrqXn6ZgdYX%2BGEXw%40mail.gmail.com.

--

Alexis Menard
Software Engineer @ Intel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOaK9Am-Bas35FSfRbiFBcihOtrHYMMi6J_z7qfyjcMa8VQAqg%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a7040733-9c2b-49dd-a638-613d17c5b91dn%40chromium.org.

[Alexis Menard]

We did resolve this in the spec, my bad. As the FYI the W3C Device and Sensors WG has decided to move this API to CR.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-%2BuPc%3DMCHjad6sMrvp_yn27zVK4DfQJb-9tCv7CXuGfQ%40mail.gmail.com.

[Diego González]

💖

[Domenic Denicola]

Thanks for resolving this! LGTM2.

[Alexis Menard]

@Yoav Weiss (@Shopify) does my answer covers your concerns?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9O6NvXoTOG0PzKitFxMgPz%3D32JYEZcSvX7hF%3DXnzs_sw%40mail.gmail.com.

[Yoav Weiss (@Shopify)]

LGTM3

[Diego González]

Congrats! It's exciting seeing the Device Posture API ship. Great work Alexis. 🎉

Sent from Outlook for Android

---

From: Yoav Weiss (@Shopify) <yoav...@chromium.org>
Sent: Wednesday, October 16, 2024 3:41:49 AM
To: Alexis Menard <alexis...@intel.com>
Cc: Domenic Denicola <dom...@chromium.org>; Diego González <die...@gmail.com>; blink-dev <blin...@chromium.org>; Alex Russell <sligh...@chromium.org>; Ian Clelland <icle...@chromium.org>
Subject: Re: [blink-dev] Intent to Ship: Device Posture API