#981: Call stacks in crash reports from unresponsive web pages
Discussions
Log in to see TAG-private discussions.
Discussed
Sep 16, 2024 (See Github)
https://github.com/w3ctag/design-reviews-private-brainstorming/issues/1
Jeffrey: I'm generally favorable.
Peter: Will the browser pop up a request?
Jeffrey: I think the developers expect that not, but it could.
Tess: In the extension case, website users probably won't notice what it's revealing. But the UI could just say "these 5 extensions injected code and might be revealed." Don't rely solely on displaying the stack trace.
Peter: There's room for the UA to be smart. Don't want any crash report sent without my consent. Page should say "page requested a crash report", and let me say yes/no.
Tess: Good to let UAs compete on providing the most user-protecting interface. Spec should be clear enough about these concerns that a new naive engineer does something decent.
satisfied with concerns:
This looks like a worthwhile piece of information to show to developers. We agree with the privacy worries that these uploads might expose what extensions a user is running. We suspect this privacy risk is avoidable in two ways: First, you could automatically omit stacks if any extensions have injected content scripts. Second, you could prompt the user about whether they want to send the report, with a user-comprehensible explanation of what sensitive information's likely to be sent; for example the list of extensions that injected script.
Please continue discussing this in the WebPerf working group and the PING.
</blockquote> Comment by @jyasskin Sep 18, 2024 (See Github)
This looks like a worthwhile piece of information to show to developers. We agree with the privacy worries that these uploads might expose what extensions a user is running. We suspect this privacy risk is avoidable in two ways: First, you could automatically omit stacks if any extensions have injected content scripts. Second, you could prompt the user about whether they want to send the report, with a user-comprehensible explanation of what sensitive information's likely to be sent: for example the list of extensions that injected script.
Please continue discussing this in the WebPerf working group and the PING.
Comment by @aluhrs13 Feb 19, 2025 (See Github)
@jyasskin - We'll talk more amongst implementers, WebPerfWG, etc. but what would TAG think of redacting the frames that have extensions instead of the entire stack?
With the scenarios this will serve, we expect that developers will aggregate and group based on the stacks. When doing that, there's going to be some amount of "unknown" where the UA didn't/couldn't get a stack, the site's processing pipeline fails, etc. Omitting the entire stack leaves the question of "Is this intentionally blank, or was there an issue in getting/processing it?"
Redacting only the frames from extensions would give the site details on something is negatively impacting something on their site with at least a vague pointer to the something on their site that they can look into is much better than nothing.
Comment by @jyasskin Feb 19, 2025 (See Github)
That's a plausible thing to investigate, but I think privacy-focused reviewers are more likely to be helpful than the TAG as a whole. Maybe ask the Privacy WG to review this?
OpenedAug 13, 2024
こんにちは TAG-さん!
I'm requesting a TAG review of Call stacks in crash reports from unresponsive web pages.
When a web page becomes unresponsive, it's often because of JavaScript code which is busy running an infinite loop or other very long computation. When a developer receives a report from the crash reporting API, and the reason is unresponsive, it would be very helpful to include the JS call stack from when the page was deemed unresponsive. This would let the website developer more easily find the find and fix the problem. What happens instead? The page reports that it was terminated due to being unresponsive, but the developer of the page has no further information about how to fix the problem.
Further details:
You should also know that...