Until someone confirms that they are what the name and what the speculation is about.
Yes - it exposes an API to set device encryption keys to the websites that you visit with it- At least that's how I interpret the last section "The dangerous functions".
I can't find any information anywhere that either confirms or denies the possibility to bypass Google's restrictions with web views. I assume it's possible, because it's possible on most platforms, but I suppose it depends on the implementation.
I've seen parental controls that employ an (on-device) MitM proxy and DNS filtering to ensure safety, and those apps will prevent almost any app from displaying unwanted content.
(without even talking about this key management stuff, because at this point it's merely speculation as the author didn't test what they actually do: “you have two methods which I don’t know what they do, but they sound scary”)
And IIRC it's rather difficult to set up a webview that allows multiple domains or URLs (but I'm no android dev, and the last time I had to fiddle with this, was years ago)
Blocking external domains shouldn't be that hard, but I also don't think parental controls are of any interest or priority for most app developers.
IIRC whitelisting was the default in webviews; not sure if it still is, or if our expert Android dev configured it this way, but even getting a build that allowed to load content from our new domain required a new build. (Let alone that someone, even if we had links or such in our about.html, would be able to navigate there).
1. Just limit the webview browser location to the same list as allowed by the parental control.
2. By default limit the webview browser location to the domain first opened by the app i.e locked to a single domain by default.
3. Allow webview browser to be expanded via a regex/pattern list of domains.
4. Limit the number of webview browser location changes so even if you can access a search engine with a global domain allowlist, it would just return to the first page after N window.location changes.
There's plenty of introspection you can do via JS (which is already being used to set/inject that `mm` object), it could even check for certain DOM elements, HTTPS fingerprint, etc. to determine if the page is an "intended" destination for the particular integrated webview browser.
But finding an example where you can navigate elsewhere is not proof that all webviews are broken; maybe they have this "security issue" by default and allow a dev to tighten it (bad sec. practice IMO), and maybe android versions or SDK-versions differ in how they adhere, IDK. But the times that I encountered this and fiddled with it, it was a PIAS to even allow loading a page from another domain.