> Also, Chrome sometimes crashes with a segfault when I dismiss dialogs too fast.

Does this create an entry in chrome://crashes? If so, please share the "Uploaded Crash Report ID".

I suspect the dialog in question is from Android itself (https://textslashplain.com/2017/01/13/client-certificates-on-android/) which might make this challenging to fix.

The crash ids are 67dc9aa935304fd3, 3611e69a3591340d, and ad50b5e28a096914.

This amounts to a denial of service on the browser, since the attacker can't control the content of the dialog. Flagging appropriately.

I believe the code that intermediates this is in chrome/browser/ui/android, so there is probably something we can do to mitigate.

I'm not sure what to make of the crash stacks on the reports on comment 2. They are unsurprisingly in the JNI that manages the dialog.

We treat browser DoS as a functional issue, rather than a security issue (although the result is annoying it doesn't leak information).

It should be largely resolved by deduplicating the prompts by host (issue #624495), which is needed also in the non-malicious case.

But someone intent on making a nuisance could still get around it via other means. I think the next change we want is to cancel client cert requests when their corresponding URLRequest has cancelled, presuming the prompt hasn't shown yet. (Currently we show prompts all at once and let Android deal with it, but deduplicating will require we queue them up.)

After that, being a nuisance is probably still possible, though renderer and socket limits would complicate it. If needed, we can then look at more dedicated rate limits around that prompt. But ultimately we have some difficulty because once the prompt itself is shown, we have no control over it.

The crash itself I would expect is memory exhaustion, but the stack trace is odd, so maybe there's something else wrong there. But ultimately we will just crash from memory exhaustion.