Hi all,
This sort of reporting would be incredibly useful for third-party Javascript given how widely it is deployed and potentially dangerous an infinite loop in that context could be. I'm an engineer who writes third-party JavaScript for Google's Display Ads products and having capabilities like this built-in to the browser would enhance our confidence in the safety of the code our publishers entrust us to run on their sites. To that end, we would like to request that the specification further incorporate reporting from hung third-party JavaScript executing within the top-level browsing context. Specifically, we would like to explore the possibility of an additional opt-in mechanism on cross-origin scripts, possibly through a similar mechanism to Heavy Ad Intervention via Report-To <https://developer.chrome.com/blog/heavy-ad-interventions#what_happens_when_an_ad_is_removed>. Upon observing a crash, the user agent would only send reports to an origin after searching the call stack for a frame belonging to the corresponding origin. Overall, we’re quite excited about this proposal and would be interested in partnering on a joint origin trial if third-party scripts could be incorporated into the spec. Thanks, Jacob On Friday, February 23, 2024 at 12:34:43 PM UTC-5 Rick Byers wrote: > Yikes, that definitely sounds like a potential privacy issue to me Dmitry, > thanks! I added it as a question in the design doc > <https://docs.google.com/document/d/19DpvHIiYbmB9wgIP0BdI4vOnfVLcAZFmfIAml7SqRQA/edit#heading=h.rw6xsrmfjjy1>, > > let's take the discussion there rather than blink-dev? > > Rick > > On Fri, Feb 23, 2024 at 5:02 PM Dmitry Gozman <[email protected]> wrote: > >> While reviewing the proposed implementation >> <https://chromium-review.googlesource.com/c/chromium/src/+/4959773>, I >> had the following privacy-related concern, and would like to consult the >> API owners on the topic. >> >> When capturing the stack trace in the renderer process, we do not >> attribute it to the page/frame that is actually running JS. Therefore, when >> two pages or cross-origin frames share the same renderer, we could capture >> a stack trace in one of them, and accidentally send it to the crash >> reporting endpoint from the other. >> >> I wonder whether we consider this a risk? If we do, any ideas about >> mitigating it? For example, we could probably restrict this feature to >> renderers that are known to only host a single origin (not yet sure whether >> that's easily known), so that we cannot mistakenly capture a different >> origin stack trace. Or maybe someone knows how to attribute a stack trace >> to the originating frame? >> >> Thank you, >> Dmitry >> >> >> >> On Tue, Jan 30, 2024 at 4:08 PM 'Issack John' via blink-dev < >> [email protected]> wrote: >> >>> Hi all, >>> >>> Thank you for the great questions and insights. >>> >>> This feature will be restricted to only the execution stacks in the main >>> world. As Rick described, extension code injected into the main world may >>> be visible. >>> >>> *How do you know from the IO thread what the main thread isolate is?* >>> Because blink::MainThreadIsolate is deprecated, I believe we have some >>> options. >>> 1. V8::PerIsolateData::MainThreadIsolate, unless that is also >>> deprecated. (No code comment saying that it is.) >>> 2. >>> MainThreadSchedulerImpl::ForEachMainThreadIsolate(base::RepeatingCallback<void(v8::Isolate* >>> >>> isolate)> callback) >>> Currently, this function only calls the callback for a single >>> isolate but IIUC, we can check if the isolate has a main world and that >>> would be the main thread isolate? >>> >>> The design document now includes the questions that I have received. I >>> am working on getting more information to address the remaining technical >>> questions. >>> >>> Issack >>> On Thursday, January 25, 2024 at 8:05:14 AM UTC-8 Dave Tapuska wrote: >>> >>>> Yes I was thinking of how the stack trace format was standardized as >>>> well. How do wasm call stacks work with this proposal? >>>> >>>> dave. >>>> >>>> On Wed, Jan 24, 2024 at 8:27 PM Domenic Denicola <[email protected]> >>>> wrote: >>>> >>>>> I agree with Dave's take on the importance of not including extension >>>>> scripts themselves, and Rick's take on how it is OK to include >>>>> extension-injected main world scripts. >>>>> >>>>> One additional interop concern that's worth highlighting here is that >>>>> the stack trace format itself is not compatible across browsers. However, >>>>> I >>>>> don't think that should block this intent. It is already exposed >>>>> throughout >>>>> the web platform (via the `error.stack` getter), and there is already a >>>>> lot >>>>> of software, both client- and server-side, which deals with parsing the >>>>> different browsers' formats. I don't think this would make the situation >>>>> any worse. >>>>> >>>>> I do wish that one day browsers would get together and standardize the >>>>> stack trace format. https://github.com/tc39/proposal-error-stacks is >>>>> one attempt at that, but it has been largely dormant for 3 years. >>>>> >>>>> On Thu, Jan 25, 2024 at 5:59 AM Rick Byers <[email protected]> >>>>> wrote: >>>>> >>>>>> Not to distract from Dave's good technical questions. But I just >>>>>> wanted to say that I'm quite excited about this work - I think it's an >>>>>> important capability for any serious platform to have that app >>>>>> developers >>>>>> can get actionable crash and hang reports, and this has been a gap. >>>>>> Thank >>>>>> you for working on it! Don't hesitate to reach out if I can help unblock >>>>>> progress in any way. >>>>>> >>>>>> What you have listed as a spec is more of a design doc so you'll >>>>>> eventually need a formal spec. But the reporting spec editor @Ian >>>>>> Clelland mentioned over breakfast to me today that he was helping to >>>>>> support this work, so that's great to hear. >>>>>> >>>>>> Dave's question about extensions in the main thread and privacy >>>>>> implications is a good one. My initial personal take is that we probably >>>>>> shouldn't report from extension isolated worlds, but when an extension >>>>>> injects script into the main world, I think I can argue that they're >>>>>> explicitly informing the site developer about their presence. In >>>>>> practice I >>>>>> believe sites can detect such extensions already if suitably motivated >>>>>> (eg. >>>>>> hook into the prototype of various APIs and identify their calling >>>>>> patterns >>>>>> or look at JS exception stack traces). I can see an argument for not >>>>>> giving >>>>>> sites easy access to such information in real-time and wonder if this >>>>>> has >>>>>> come up already for the self-profiling API proposal >>>>>> <https://wicg.github.io/js-self-profiling/>? But for an asynchronous >>>>>> crash report sent only after the page has been shut down, I personally >>>>>> don't think it's a threat we should be trying to defend against. I'd go >>>>>> even further and say that if a site is hanging or crashing only under >>>>>> the >>>>>> presence of extension-injected code in the main world, then that's >>>>>> critical >>>>>> information for the site owner to know from a customer support >>>>>> perspective. >>>>>> >>>>>> Rick >>>>>> >>>>>> On Wed, Jan 24, 2024 at 3:10 PM Dave Tapuska <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Just a few thoughts... >>>>>>> >>>>>>> I haven't seen a proposed implementation but I presume you are going >>>>>>> to restrict this only to execution stacks in the main world? >>>>>>> If you get an extension executing scripts in the main world how will >>>>>>> you prevent the endpoint from knowing about the agent's execution >>>>>>> environment such as what extensions they have installed? >>>>>>> How do you know from the IO thread what the main thread isolate is? >>>>>>> (blink::MainThreadIsolate is deprecated, please don't use it). >>>>>>> How do document policies work across same origin documents? What >>>>>>> realms are you checking that the policy applies, do you walk the stack >>>>>>> looking at realms and checking if the policies apply? Or is it the >>>>>>> current >>>>>>> realm or incumbent realm or what? >>>>>>> >>>>>>> dave. >>>>>>> >>>>>>> On Wed, Jan 24, 2024 at 12:47 PM 'Issack John' via blink-dev < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Contact emails >>>>>>>> [email protected], [email protected] >>>>>>>> >>>>>>>> Explainer >>>>>>>> https://github.com/WICG/crash-reporting/issues/12 >>>>>>>> >>>>>>>> Specification >>>>>>>> >>>>>>>> https://docs.google.com/document/d/19DpvHIiYbmB9wgIP0BdI4vOnfVLcAZFmfIAml7SqRQA/edit?usp=sharing >>>>>>>> >>>>>>>> Summary >>>>>>>> >>>>>>>> This feature captures the JS call stack when a web page becomes >>>>>>>> unresponsive due to JavaScript code running an infinite loop or other >>>>>>>> very >>>>>>>> long computation. This helps developers to identify the cause of the >>>>>>>> unresponsiveness and fix it more easily. The JS call stack is included >>>>>>>> in >>>>>>>> the crash reporting API when the reason is unresponsive. >>>>>>>> >>>>>>>> >>>>>>>> Blink component >>>>>>>> Blink>ReportingObserver >>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EReportingObserver> >>>>>>>> >>>>>>>> Motivation >>>>>>>> >>>>>>>> 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. >>>>>>>> >>>>>>>> >>>>>>>> Initial public proposal >>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1445539 >>>>>>>> >>>>>>>> TAG review >>>>>>>> None >>>>>>>> >>>>>>>> TAG review status >>>>>>>> Pending >>>>>>>> >>>>>>>> Risks >>>>>>>> >>>>>>>> >>>>>>>> Interoperability and Compatibility >>>>>>>> >>>>>>>> None >>>>>>>> >>>>>>>> >>>>>>>> *Gecko*: No signal >>>>>>>> >>>>>>>> *WebKit*: No signal >>>>>>>> >>>>>>>> *Web developers*: No signals >>>>>>>> >>>>>>>> *Other signals*: >>>>>>>> >>>>>>>> WebView application risks >>>>>>>> >>>>>>>> *Does this intent deprecate or change behavior of existing APIs, >>>>>>>> such that it has potentially high risk for Android WebView-based >>>>>>>> applications?* >>>>>>>> >>>>>>>> None >>>>>>>> >>>>>>>> >>>>>>>> Debuggability >>>>>>>> >>>>>>>> None >>>>>>>> >>>>>>>> >>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>> ? >>>>>>>> No >>>>>>>> >>>>>>>> Flag name on chrome://flags >>>>>>>> None >>>>>>>> >>>>>>>> Finch feature name >>>>>>>> None >>>>>>>> >>>>>>>> Non-finch justification >>>>>>>> None >>>>>>>> >>>>>>>> Requires code in //chrome? >>>>>>>> False >>>>>>>> >>>>>>>> Tracking bug >>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1445539 >>>>>>>> >>>>>>>> Estimated milestones >>>>>>>> >>>>>>>> No milestones specified >>>>>>>> >>>>>>>> >>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>> https://chromestatus.com/feature/4731248572628992 >>>>>>>> >>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>> <https://chromestatus.com/>. >>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "blink-dev" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to [email protected]. >>>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MW2PPF6784DDB763E2DA7BFC75AE51613ABC27B2%40MW2PPF6784DDB76.namprd00.prod.outlook.com >>>>>>>> >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MW2PPF6784DDB763E2DA7BFC75AE51613ABC27B2%40MW2PPF6784DDB76.namprd00.prod.outlook.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "blink-dev" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZUui22mB-J5SAEmEd%3DCk%2BrcyRSr4tGASLGFcsvRn9QVOQ%40mail.gmail.com >>>>>>> >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZUui22mB-J5SAEmEd%3DCk%2BrcyRSr4tGASLGFcsvRn9QVOQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "blink-dev" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_LQuaFsJXuQvBnwrJUjQeHnsya6QENTVVW9mkkrO26OA%40mail.gmail.com >>>>>> >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_LQuaFsJXuQvBnwrJUjQeHnsya6QENTVVW9mkkrO26OA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "blink-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f0ee10ea-759b-4c01-89e5-63bb2d34a94fn%40chromium.org >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f0ee10ea-759b-4c01-89e5-63bb2d34a94fn%40chromium.org?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f1e6ad62-d2f6-45c5-aaef-3e0f1b111370n%40chromium.org.
