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 < blink-dev@chromium.org> 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 <dom...@chromium.org> >> 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 <rby...@chromium.org> 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 <dtap...@chromium.org> >>>> 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 < >>>>> blin...@chromium.org> wrote: >>>>> >>>>>> Contact emails >>>>>> issac...@microsoft.com, seth.b...@microsoft.com >>>>>> >>>>>> 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 blink-dev+...@chromium.org. >>>>>> 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 blink-dev+...@chromium.org. >>>>> 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 blink-dev+...@chromium.org. >>>> 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 blink-dev+unsubscr...@chromium.org. > 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAANSib6u5uhW6LYw6y_op9Pr7QcNXNWgNUbQ9s%2BmYmuoapFAAg%40mail.gmail.com.
