It's unclear to me that this should have a permission. LGTM1
On Mon, Oct 7, 2024, 7:19 AM Alexis Menard <alexis.men...@intel.com> wrote: > > > On Mon, Oct 7, 2024 at 9:31 AM Ian Clelland <iclell...@chromium.org> > wrote: > >> >> >> On Mon, Oct 7, 2024 at 7:36 AM Alexis Menard <alexis.men...@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. > > >> >> Ian >> >> >>> 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. >>> >>> >>> On Mon, Oct 7, 2024, 12:24 AM Domenic Denicola <dome...@chromium.org> >>> wrote: >>> >>>> 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. >>>> >>>> On Thu, Oct 3, 2024 at 11:42 PM Alexis Menard <alexis.men...@intel.com> >>>> wrote: >>>> >>>>> Contact emails alexis.men...@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 >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EFoldableAPIs> >>>>> >>>>> 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 >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>> ? 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 >>>>> <https://chromestatus.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+unsubscr...@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 >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/540e383c-1e1c-4918-9f10-c3fb2dd9bc19%40intel.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>>> 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+unsubscr...@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 >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra_U0%3DqYJnDGBM8Zm-yLh7XNT1tA1uKt1a6VzuDBHBdDYA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> 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+unsubscr...@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 >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOaK9AntwL_dhXaSvEHVAfoisf4fexB_tNTidO9BjqiWUxM2vQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> 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+unsubscr...@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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK_TSXKv4q4Zj%2B-iDr%3DEbdENuZbdpFqxaaNrqXn6ZgdYX%2BGEXw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > 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+unsubscr...@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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOaK9Am-Bas35FSfRbiFBcihOtrHYMMi6J_z7qfyjcMa8VQAqg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA44PQgUHazeY_g09S_J1Sy%2BwiwD4pAJ-gW6HgazT0wyLR6ATQ%40mail.gmail.com.
