Do we actually gain anything from doing this work?

 * as you've noted, it's already hard to call arbitrary code thanks to proguard
 * the ClassLoader in question is the Chromium ClassLoader. Apps already can (and do) obtain this via other reflection-y means

---

If we still want to do this work, what are the "certain classes" we will permit to be called? Can we get away with a whitelist? Is this whitelist any different from the whitelist produced by our proguard.flags file [1]?

[1] https://cs.chromium.org/chromium/src/android_webview/apk/java/proguard.flags?q=f:proguard.flags&sq=package:chromium&dr

Yeah it's not obviously worth it - and this would be a new source for bugs.

The whitelist should be heavily related to classes we avoid obfuscating - I think it should only contain classes from the support library glue though.

This was specifically requested by feature council as a condition of the API to get the classloader being public. While it's true that it's possible to get the classloader other ways and that proguard makes it hard to abuse this anyway, the fact that the underlying API is public means that they want it to have a specifically restricted scope, as otherwise it implies apps are supposed to be able to do this.

Ack. Our support library code appears to only fetch "org.chromium.support_lib_glue.SupportLibReflectionUtil" [1]. Is this the only class we should whitelist, or do we want to whitelist others to support other use cases for this API?

There's sadly no documentation on *how* this is expected to filter. RuntimeException for loading a non-whitelisted class? Return null for non-whitelisted class? Should we also improve the API docs to mention this is a "filtering" classloader, and document what it does when misused by apps?

[1] http://cs/android/frameworks/support/webkit/src/main/java/androidx/webkit/internal/WebViewGlueCommunicator.java?l=64&rcl=b3edde5d60c2f38cc67d7c420194c9a8d30c47f8

Maybe this could help: https://stackoverflow.com/questions/3092449/implementing-a-filtering-class-loader

I guess we just need to:

 * override loadClass
 * throw an exception for classes we intend to filter out

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/clank/internal/apps/+/0d0b15a592330daeadaca3a57f280d92c6b909f4

commit 0d0b15a592330daeadaca3a57f280d92c6b909f4
Author: Nate Fischer <ntfschr@google.com>
Date: Fri Jun 01 19:08:03 2018

No verification needed, I verified locally before landing.