The data_decoder service (e.g. SafeJsonParser) by default spins up and shuts down a new utility process for every JSON parse request, which is the safe default. We're now seeing more requests from teams that need to parse data in response to network requests. With the current architecture, this means that a remote host could cause repeated utility process spawns by sending specifically crafted network packets (i.e., a remote fork bomb), which we suppose could happen organically for a popular feature or maliciously.

We should consider adding entrypoint variants for the data_decoder service where the caller can manage the lifetime of the Mojo binding themselves. This would allow the client to send all decoder requests for a specific type of data decoder request to the same process (e.g. batch all JSON decoding for parsing a specific HTTP header into one process). This differs from the "ParseShared" mode that was initially discussed where all kinds of data decoder requests would be lumped into the same process. This would allow us to partition the requests by data decoder type and purpose.

For historical discussion  issue 774719  and my CL comment here https://chromium-review.googlesource.com/c/chromium/src/+/729213#message-eab62a551f72255cc674adf01d891b966b909887.