The browser process should not handle messages from web content

(drawing source here)

Sometimes features are proposed in which the Chrome user interface (in the browser process) handles messages directly from web content (JavaScript, HTML etc.). For example, this could be done using the postMessage APIs which have been put in place for Android WebView apps. This is not allowed, because:

• Overall system security relies on simple and predictable security properties. Adding extra message channels causes complexity, non-discoverability and non-predictability.
• Chrome's security strategy relies on isolating web content using sandboxed renderer processes and site isolation. Any communication outside of that renderer process presents a risk of a sandbox escape. All such communication has to be via Mojo such that the mojom interface definition files go through our IPC security review process (and will benefit from other future Mojo security improvements).
• Websites are untrustworthy. TLS can’t guarantee the provenance of a website — even pinning has limits — and so you must assume any messages from websites are malicious. Processing such messages in the browser process in C++ is likely a violation of the Rule of Two and is extremely dangerous.
• Even if you can comply with the Rule of Two (for example by using a safe language) it's simply difficult to produce robust APIs that are safe against malicious data: the open web platform API review process is designed to flush out any concerns. Any APIs or functionality accessible to web content therefore needs to go via that process to give the best chance of spotting danger.
• There are non-security concerns: It does not comply with the spirit of an open web platform which should be equally available on all user agents.

In order to support WebView and CCT, APIs exist in Chrome to establish web message channels between the embedding application and web page. These exist only to support these "embedding the web" scenarios, which are often used to build site- or purpose-specific browsers. General browser features should not use them because of the reasons stated above.

Other mechanisms of bypassing normal processes might include exposing unreviewed APIs to a component extension, and making its APIs available to web content. These are similarly not allowed.