Spotted on Chrome M68 on Linux, but is likely platform independent, and has likely been around for a while.

Ramin, passing to you.

Reporting crashes from Incognito is WAI, similarly as for UMA; we need to know whether the product works correctly. However, as always, we should not leave local traces.

Pri=2, as this is not a regression.

+ivanpe

As far as I see, the only stored data is Crash Report ID and time of crash.
If this is the only locally stored data, I think it's an acceptable incognito no-history violation given the usability of the report.

But then the next question is, doesn't sending the crash log to Google violate incognito privacy promises? Even if it includes the last URL, it can include PII.

Ivan,
Am I correct about the locally stored data?
Could you please point me to a doc with the collected data for crash report, or privacy discussion about it?

+mark, +jperaza

Mark, Joshua, do you know whether Chrome uploads minidumps when users are using incognito mode?

I wasn't able to find any details about that in go/chrome-pdd and go/crash-pdd.

Yes, it does.

Are the only locally stored data crash report id and time?

It stores the entire crash dump locally, subject to the same purge policy that every other crash dump is under.

We save them locally to allow users an opportunity to upload the crash reports in the future if they weren’t uploaded for any reason. They might not have been uploaded because upload was turned off and the user wanted to select individual reports for upload rather than give blanket authorization, or the initial upload attempt may have failed.

We do want to collect crash reports for things that happen in incognito sessions, otherwise we’d lose crash coverage of a very important feature of our browser. Furthermore, although we would have the technical ability to decide on a per-renderer basis whether each is associated with incognito or not, we have no ability to do this for the browser process. A browser crash is a browser crash, and we can’t reason as to whether a browser crash is an “incognito browser crash” or a “non-incognito browser crash.” There is only one browser.

The design of our crash reporting clients is such that we do need to spool the crash report to disk before upload. It’s too much meat to hold in memory, and we also want the system to be resilient against things that might tear down the crash handler process during a time-consuming upload and against upload failures, along with the user-controllable upload retry discussed above.

Thank you.

Crash reports are definitely required to ensure stability of the incognito mode and I should emphasis that the issue here is not privacy vs. Google but it's privacy vs local state, as storing incognito history on disk is clearly against incognito promises.

So I have a few follow up questions, please point me to appropriate reading if required.

1- Is data sensitization (purging user data) happening before writing the crash dump to disk, before upload, or server side?
2- Is the stored data encrypted? If yes, where is the key?
3- Is it possible to keep a flag stating that when crash happened, there has been incognito windows open or not? And based on this flag, use harsher precautions for storage of the data?

Gentle reminder on this.

mark@,
Would you prefer to discuss it in a meeting?

The answers to your questions are generally “no,” but I’ve been putting some thought into designing something that should help, at least for renderer processes. I put a brief description at https://chromium-review.googlesource.com/c/chromium/src/+/989401/100/android_webview/common/crash_reporter/aw_crash_reporter_client.cc#b36 (look for “one-shot”).

Do you think that would be an appropriate mitigation?

Happy to discuss more as needed.

Yes, if crash dumps go directly to uploader and there would be no trace on disk, it would be great.

You are separating WebView from the rest of crash reports, can't the others include user data?

Is there a time line for this change? This is a very high priority incognito related issue.

mark@,
Gentle ping on #13.