pennymac has graciously agreed to handle this.

Hey Will,

Planning to move forward with enabling win32k lockdown for all utility child processes.  It's already enabled on renderers - is there any reason I shouldn't enable this for all sandboxed child processes in sandbox_win.cc?  (I.e. there's no reason to identify mojo utility children specifically.)

https://cs.chromium.org/chromium/src/content/common/sandbox_win.cc?q=sandbox_win&sq=package:chromium&l=781

I have rough plans to do this with an A/B test on pre-stable channels.  Do you agree that that is the best way to carefully move forward with this?  Or did you previously do some testing on pre-channels?

I believe there are potential use cases for code running in utility processes to have Win32k support. For example at various times Widevine have considered moving to utility/mojo processes to support new DRM sadness which is typically going to require access to Win32k. Also I vaguely recall PDFium might use a utility process for printing to a GDI device which again would require Win32k but I could be wrong on that. I'd be surprised if we can turn it on in a blanket fashion, but it's worth a try certainly and see what breaks as it shouldn't be too difficult to add a variations switch and setup an experiment to test in Beta, Dev, Canary. I think the biggest difficulty might be generating a suitable metric which demonstrates failure without relying on user feedback.

On hold until I split up Utility procs.

This is still on hold.  Utility hasn't been split up... but new services are generally getting custom sandboxes now.  Custom sandbox types can be individually assessed for win32k lockdown.