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 <dgoz...@chromium.org> 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 < > 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/CAFUtAY8SDPjVg%3Da%2B5g6QbShKQHo7Lyv46HGJ8G7CHWeujAVXJA%40mail.gmail.com.
