#647: scheduler.postTask()
Discussions
Discussed
Jun 28, 2021 (See Github)
Punted
Discussed
Aug 30, 2021 (See Github)
Sangwhan: the use case makes sense...
Ken: completed origin trial in 93 and now available by default in chrome
Dan: looking at responses to security and privacy. The question about data features expose to an origin..
Sangwhan: this is the ugly thing... competing with cpu time for other things in the browser. You could pull it off in chromeos where the browser is the only thing that's running?
Dan: they say information gained is likely to be benign but i'm not sure what information the're talking about
Sangwhan: CPU usage... imagine .. one listening to compute pressure and the other post burst tasks that run through loops in a specific pattern.. could mitigate in the implementation
Dan: we could feed back that they need to suggest mitigations
Sangwhan: it's a stretch. You could do this without this api
Ken: very highly unlikely and unrelable side channel
Dan: they actually have a mitigations section in the spec, and talk about what information might be gained. I think this is good. I think we should close it.
Sangwhan: [leaves closing comment]
Comment by @cynthia Aug 31, 2021 (See Github)
Sorry this took so long - I believe this was a priority request and for some reason, it fell through the cracks. We looked at this during our breakout today and were very happy to see all the security concerns properly addressed in the draft spec, and are happy to see a feature that would be useful for developers finally landing on the platform. For these reasons, we're happy to see this proceed.
Thanks for bringing this to our attention, and sincere apologies it took so long.
OpenedJun 14, 2021
Ya ya yawm TAG!
I'm requesting a TAG review of
scheduler.postTask()
.Userspace tasks often have varying degrees of importance (related to user experience), but the Platform lacks a unified API to schedule and control prioritized work;
scheduler.postTask()
provides this functionality.Further details:
You should also know that...
We'd prefer the TAG provide feedback as (please delete all but the desired option):
🐛 open issues in our GitHub repo for each point of feedback
CAREFULLY READ AND DELETE CONTENT BELOW THIS LINE BEFORE SUBMITTING
Please preview the issue and check that the links work before submitting.
In particular, if anything links to a URL which requires authentication (e.g. Google document), please make sure anyone with the link can access the document. We would prefer fully public documents though, since we work in the open.
¹ We require an explainer to give the relevant context for the spec review, even if the spec has some background information. For background, see our explanation of how to write a good explainer. We recommend the explainer to be in Markdown.
² A Security and Privacy questionnaire helps us understand potential security and privacy issues and mitigations for your design, and can save us asking redundant questions. See https://www.w3.org/TR/security-privacy-questionnaire/.