-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
State extension for JS Self-Profiling API. #682
Comments
Hi folks! Regarding the mitigation against cross-origin leakage that you've described - can you expand on this a little bit and be a bit more clear about what the mitigation strategy is? Are there ways that you could envision this API being used to intentionally and maliciously leak data across origin boundaries? It would be good if you could elaborate on the potential misuse (and mitigations). |
I see that you mention this is good for identifying different behavior across UAs, but given that this will mostly be available on the same engine for a long time (Chromium) do you expect developers to correlate this data with other data, e.g. specific OS's, devices etc, like identifying that layout is a big issue in say India as it takes very long on a Moto G5 phone etc? |
Hi @cnpsc we're just coming back to this in our call today. Can you give us an update on progress? We'd like to understand: what is the multi-stakeholder situation (has this been discussed with anyone outside of the Chromium community?) The explainer also does not start from the user need as we've tried to emphasise in our explainer explainer. What user needs is this in service of? Also would this go to Web Performance working group after incubation in WICG? Have you had any discussions with that WG? |
Hi @torgo ! For the user's need I used the explainer's template and put it in the goals' section https://github.com/WICG/js-self-profiling/blob/main/markers.md#goals |
Hi @cnpsc yes it's describing the problem from the developer perspective rather than from the end-user perspective. It may seem like make-work but we're really trying to emphasize (in the TAG review process) the idea of end-user-centricity - in other words, that people who are working on new APIs for the web are thinking about new functionality from the end-user perspective. Also remember the explainer is not just for TAG review. For example - what you write in the explainer could help ti inform eventual developer documentation (e.g. on MDN). So yes please if you could start with the (end) user need that would be much appreciated. And thanks for the pointer to the discussion with the Web Perf working group - this is exactly the kind of "trajectory" information we are looking for when we review something in WICG or another community group. |
@cnpsc @acomminos any update? |
Just taking another look at this at our face-to-face. I'm still concerned about the multi-stakeholder issue - ChromeStatus shows no additional implementer interest. From @atanassov : What is the story around user consent – because essentially you are using cycles on the user's device. Should it be gated behind a permission? From @cynthia : what about main thread CPU starvation caused by a worker or an external process? Also |
Thanks for the feedback, I tried to address the comments below !
For the user consent story, this has been explored in the original tag review for the feature, reasoning is that this is a source of bias in the performance profile and it limits ability to profile first load.
External processes are out of scope, the goal is to help developers understand how their own application behave in the wild.
Thanks adding the annotations !
AFAIK at the time there was no 'disabled by default' support for Feature/Permission policy when this was added to the spec. |
Thank you for the response. Just to not lose context here - is there multiple stakeholder interest for this?
What about workers? The main concern was about the main thread profile data missing context about high compute pressure, caused either by a worker or an external process. It would be useful if there was a way to share some context when main thread is not getting enough CPU time, as the perf timings for those scenarios would be very different. |
Hi @cynthia, this development has been paused to gather more stakeholder feedback. Thanks ! |
Thanks @cnpsc, feel free to request a re-open once you feel like you have reached a point where this warrants a review. |
Braw mornin' TAG!
I'm requesting a TAG review of State extension for JS Self-Profiling API.
Non javascript execution is hard to identify in traces captured with JS Self-Profiling API:
From a trace we cannot differentiate idle activity from top level UA activity, so for example code that triggers asynchronous rendering work cannot be measured properly.
https://www.chromestatus.com/feature/5676352050036736
Further details:
You should also know that...
We'd prefer the TAG provide feedback as (please delete all but the desired option):
💬 leave review feedback as a comment in this issue and @-notify @cnpsc @acomminos
The text was updated successfully, but these errors were encountered: