- From: Alexis Menard <alexis.menard@intel.com>
- Date: Tue, 17 Sep 2024 14:56:16 -0400
- To: Nick Doty <ndoty@cdt.org>, <www-style@w3.org>
- Message-ID: <c57372cb-4d68-42b6-bbed-c560775dce65@intel.com>
Hi, Thanks Nick for starting the discussion and doing a great job at summarizing the issue. We do have Permission Policy for iframes, but none of the existing permissions seems to unlock an API which has a CSS surface (either env variables or MQs for example). I may be mistaken, I did a quick glance. So specifically for the Device Posture API, we can put the JavaScript API behind a permission policy and block iframes to access the API if we wanted to, but this will not block iframe's CSS blocks to be parsed, and resolved. Also, one can access CSS MQs state via JavaScript. Implementing restriction in a CSS engine would be a novelty and before some of us dig more into the implication of doing that into said engine, I think it's better to clarify the goals and more (and usefulness). Personally, I think the privacy exposure is very limited (especially considering that the devices are becoming very popular) but I think it could be an issue in the future for other APIs, so the need could still exist. We should probably extend the discussion beyond MQs, at the very least we should consider CSS env variables. I'm interested in the feedback and discussions. Thanks. On 9/17/24 14:34, Nick Doty wrote: > Hello CSS friends, > > The Privacy Interest Group recently [0] discussed the Device Posture > API, which raised some questions about the privacy impact of media > queries and, more specifically, whether media query functionality > should be delegated or qualified in some way to indicate whether a > particular embedded frame (or embedded frames generally) should have > access to the values of a particular media query. > > The particular use case where this came up was that a top-level site > might want to know when or whether the device has been folded: this > has some privacy impact in potentially letting multiple origins try to > correlate whether visitors are actually the same user by correlating > when a device environment changes on embedded frames in multiple > origins. (This is sometimes called ephemeral fingerprinting, although > it's a pretty distinctly different technique from what we typically > call browser fingerprinting.) While the functionality might be > important for a top-level site, it might not be important or desirable > to communicate to every embedded frame. In thinking about the > possibility of fenced frames, for example, or the use of permissions > policy to delegate particular functionality to iframes (or exclude > functionality from certain iframes), the Web platform sometimes > indicates that a capability shouldn't be available to a frame. > > That was a lot of set-up. The question for the CSS WG is: does CSS > have some way, or would you be interested in standardizing some way, > to indicate whether media query values (or perhaps other CSS > functionalities) should be available to frames or to a particular > frame? There might be a privacy/interoperability benefit in aligning > permissions that are delegated-or-not to frames with CSS > functionality. There could be an opportunity to improve the privacy of > media queries or CSS generally and also to mitigate privacy risks when > adding new capabilities looking forward. > > This is my brief summary as co-chair of a discussion in July; it's > likely imperfect. Questions or discussion would be welcome, on email, > github or at TPAC. > > Cheers, > Nick, for PING folks > > [0] Okay, it was actually a couple months ago and I got behind on > sending this follow-up to you all. Minutes here: > https://www.w3.org/Privacy/IG/summaries/PING-minutes-20240718#b-device-posture-api---httpsgithubcomw3cpingprivacy-requestissues136-pete >
Received on Tuesday, 17 September 2024 18:56:29 UTC