Sangwhan: I have looked at this. Was reviewed by us - this is a re-design. The other API was a polling mechanism. This changes that into an observer based pattern. I'm happy about that change. That said I have some concerns - some gaps in this. The compute pressure - trigger could be cases where it's artificial. Not because you're busy but because you're constraining the system because of power saving. It's one bit of entropy. If you take the browser process and constrain the cores it can access... you will be able to mine this information out by heuristics. Functionality wise it seems sensible. Other thing I'm a little worried about is sample rate - will it cause problems - certain ways of sampling this info can be high CPU consumption - not sure if sampling rate is too high? Overall other question that remains to be answered : do we think this is a good thing? I know Mozilla has been negative about this - it's info that a compute heavy applicaiton would make use of - but it makes more informnation - intimite platform info - to an origin. Do we want to expose this to the web platform?

Dan: will move to devices and sensors wg. You mentioned multistakeholder - any others besides chromium?

Sangwhan: nothing from webkit. Mozilla is against it.

Dan: what is an example of a compute heavy application that we'd expect people to..

Sangwhan: cryptpad plus google meet on a low end machine... if one or the other application can acknowledge that they can't use the whole cpu they can do something about it. Right now there's no information that lets them take action. Now a video conf app can reduce resolution or disable certain streams to reduce data needed to process. Cryptpad could reduce the amount of worker threads to reduce the footprint.

Dan: I think we should raise the issues, in particular the privacy related issue.. they've done a security and privacy.. minimising information exposure.. they are talkinga bout some of these issues in the document itself.

Sangwhan: they reduced the granularity of the information to make it a bit more safe

Amy: is there a UX improvement that could help with the privacy issues? off by default, and you can turn it on if you're doing something compute heavy?

Dan: or the browser can use a heuristic to prompt the user to enable it if it's struggling, with a warning?

Sangwhan: gated behind a permission - but problem because of how observer kicks in ... the user doesn't see it when there are problems, but before...

Dan: can they share additional information about multistakeholder?

Sangwhan: [will leave comment]

bump

Sangwhan: compute pressure makes a lot of sense. the new design is good. the re-design driven by Ken. Some privacy concerns. I think every new capability feature we have to think about the potential trade-offs. The immediate user need is...

Dan: You read my mind.

Sangwhan: if you are web app that is compute heavy - or a video conf that has background blur - the applications dont know when the CPUs are starved. The apps can take away certain non-critical functionality to serve the needs of the user. E.g. non-critical features in video conf deprioritised compared to hearing the person... If they know how much pressure they can adapt. Right now on the web there's no way to adapt. On top of that you have artificial compute pressure - e.g. battery saver - you're trying to save resources. Compute pressure is a way to convey that... Some level of concerns from app implementers that the level of info exposed is not enough - but this is a good compromise...

Dan: is there a permission required for even this level?

Sangwhan: no. You can use compute presure as a way to expose info...

Sangwhan: i have a conflict of interest as I work on this topic in ChromeOS.

Sangwhan: from a user and application dev pov - it sucks if the app is just blasting the CPU...

... 621 was the original issue.... A lot of privacy discussion happened on the previous one. They are aware of the privacy concerns....

Dan: from their privacy considerations it looks like they are excercising data minimization... one of our privacy principles... Also lots of other mitigations against privacy issues listed.

Sangwhan: one thing that may be a small concern is syncronization...

Dan: You could establish cross-origin correlation... I think that should be discussed in the privacy consideration section...

Sangwhan: it would be a very expensive way to do it...

Sangwhan: Overall we see the developer needs are pretty clear.

Dan: data minimization important...

Dan: what's the problem with doing this as a permission gate?

Sangwhan: most video conference apps have to ask for 3 permissions already... how you would convey this to average users is really tricky...

Positive feedback on data minimization approach detailed in the privacy & security considerations seciton - see data minimization for our emerging work in this area. Also the user needs are well defined in the explainer.

We'd like to hear what the developers think about how useful this is especially in multi-core (especially heterogenous) setups, once it moves on to trial.

We noticed that WebKit position is WIP, could you poke that thread and see what they think?

Dan: no activity on multistakeholder. Some concerns from mozilla. Webkit negative from 2021.

Sangwhan: on an old version

Dan: We reviewed and gave positive feedback on the fact they were referencing data minimisation principle in april.

Sangwhan: previous proposal was polling based, had a high granularity, not great usability. Privacy risks due to granularity - that's why webkit says it's a side channel. CPU architectures with a heterogenous setups (big and small clusters, modern intel cpus, atom cores, core cores, common). THe compute pressure, % aggregated, doesn't mean anything, in these kinds of configurations. But you can use those readings to create artificial workloads to create a side channel. A lot of that was saddressed by making it more coarse - high pressure, medium or low pressure, three levels or so. If you're in a high pressure situation a web application can choose to do things to improve the situation within their control, eg. blackground blur is a very expensive feature that video conferencing supports and uses a lot of cpu cycles - could black it out instead. Apps can reactively deal with this. Also reduces the side channel attack surface, but doesn't completely eliminate it. You can sync things - two origins. There are other ways to do this, not overly concerned.

... In low power mode, tell the application to use less energy, you can signal to the application.

... It's a huge gap. If we want applications to be more advanced and considerate about resource consumption this kind of mechanism lets them do that. It benefits good actors. On the other hand, it benefits bad actors.. if a bitcoin minor is sitting in the background and sees 'idle' they can crank it up to medium and not get noticed too much. There's a tradeoff.

Dan: the other signals that are coming through.. the work is happening in devices and sensors. There's multistakeholder with intel and google. Privacy and security considerations section is good. Concerns around lack of multi browser support. But webkit's position was on the old version, so need to review the new version. No information from mozilla. We don't have current information about negative feedback on this version.

Sangwhan: good use cases in video conferencing

Dan: and in web gaming [proposed close satisfied with concerns] - concerns purely based on multiple browser support

Dan: proposed closed, but have concerns about multiple browser support. Any further information since July?

Sangwhan: Probably some of this is going to launch.. experiment ongoing

Dan: based on discussion at the f2f the concerns were not applicable to the latest version.. that they'd been addressed?

Sangwhan: yes, it's been completely redesigned

closed