safetynet/docs/native-runtime/README.md

# Chromium 152 WebRTC binder backport

Status: source patch prepared and checked; **not compiled or runtime verified**.
Do not distribute this patch as a proven security fix until the acceptance gates
below pass against the resulting binary.

## Exact basis and provenance

The adjacent patch targets Chromium `152.0.7977.130`, used by Electron `44.7.0`.
It backports Chromium commit
[`46fcf3faed9db394de7046a100301f64c2842f0e`](https://chromium.googlesource.com/chromium/src/+/46fcf3faed9db394de7046a100301f64c2842f0e)
(CL8485457, bug565837691). Upstream files retain their Chromium copyright notices.

The upstream change fixes a native renderer termination when nested local-scheme
frames request a missing WebRTC binder under `Connection-Allowlist`. It registers
the binders consistently, checks the current document policy when binding, and
uses no-op mDNS/socket implementations to fail without creating network sockets.
It is a temporary transport denial, not WebRTC payload inspection.

Only two context adaptations were needed: insert the policy helper before the
older utilities file's namespace close, and place the conditional mDNS include
beside the existing connection-policy include. The original implementation,
unit tests, WPT tests and GN entries are preserved. The older public
`RenderFrameHost` header exposes both APIs used by the helper:
`HasPolicyContainerHost()` and `GetConnectionAllowlists()`.

On 2026-10-13, the 16 exact touched paths were retrieved individually from the
official Chromium tag into an ignored scratch repository. Unmodified tag files
were restored, with LF line endings, and this command completed with exit0:

```powershell
git -C artifacts/rtc-patch-check apply --check C:/Users/karl/Safetynet/docs/native-runtime/chromium-152-webrtc-binder-backport.patch
```

This proves textual applicability to the tagged files. It does not establish
compilation, compatibility with Electron's existing patches, or runtime safety.
Repeat the check against the complete Electron-patched source checkout.

## Host readiness

Measured host: Ryzen7800X3D, eight exposed logical processors, 16GB RAM (about
4.5GB free during inspection), and 266.6GiB free on NTFS C:. Installed VS2022
Build Tools17.14 includes x64 C++ tools but lacks the ATL/MFC component. SDK
`rc.exe` is26100.7705; `symstore.exe` is28000.2957. No native checkout or
depot_tools/gclient/GN/Ninja installation was found on PATH.

The [version-specific Chromium requirements](https://chromium.googlesource.com/chromium/src/+/152.0.7977.130/docs/windows_build_instructions.md)
specify at least8GB RAM and100GB disk, recommend more than16GB RAM, and require
C++ plus ATL/MFC and SDK26100.7705. This host meets the minimum resources but
requires toolchain completion. Plan substantially more memory and disk headroom
for comfortable builds; actual full-checkout and output size remains unmeasured.
Do not automatically disable endpoint antivirus or change global Git settings.

## Build procedure

Follow [Electron Windows prerequisites](https://www.electronjs.org/docs/latest/development/build-instructions-windows)
and [Electron GN/patch instructions](https://www.electronjs.org/docs/latest/development/build-instructions-gn).
Use a separate short path such as `C:/src/electron44`, outside this application.
Install missing ATL/MFC and depot_tools first. No large downloads or dependency
changes were performed while preparing this review artifact.

1. Set `DEPOT_TOOLS_WIN_TOOLCHAIN=0` in the build process and prepend depot_tools
   to that process's PATH. Keep the application workspace unchanged.
2. Configure gclient with unmanaged `src/electron` pointing at the official
   Electron repository. Bootstrap its source, check out exact `v44.7.0` in
   `src/electron`, then sync with branch heads and tags. Confirm its DEPS pins
   Chromium152.0.7977.130 before applying anything.
3. From `src`, run `git apply --check <absolute-patch-path>` against the already
   Electron-patched checkout, then apply. Any failure requires review; do not
   silently drop hunks. Export the change through Electron's patch system
   (`e patches`) so future synchronizations reproduce it.
4. Generate a release configuration using
   `import("//electron/build/args/release.gn") target_cpu="x64"`.
   For this constrained host, consider `symbol_level=0`,
   `blink_symbol_level=0`, `v8_symbol_level=0`, and local execution. These reduce
   debugging detail; keep a separately instrumented build if native investigation
   requires symbols.
5. Build `ninja -C out/Release -j2 electron`. Build the relevant Chromium native
   test target as well; low parallelism is an initial resource choice, not a
   measured guarantee against memory exhaustion.
6. Only after verification, package with
   `ninja -C out/Release electron:electron_dist_zip` and pin artifact hash,
   Electron/Chromium versions and backport revision in release provenance.

## Acceptance gates

- Compile and run `NoOpMdnsResponderTest.*` and `NoOpP2PSocketManagerTest.*`.
- Execute the upstream local-scheme allow/block WPT cases.
- Run real paired WebRTC data-channel positive controls in initial about:blank,
  srcdoc, blob and cross-origin frames; prove exact synthetic bytes arrive.
- Under the actual managed response-header function, repeat the same attempts:
  no data delivery, no renderer termination, no hanging harness, and successful
  benign HTTP POSTs. Exercise the initial synchronous iframe window before any
  navigation or preload; constructor availability alone is not a pass.
- Verify native socket denial without relying on the JavaScript preload. Check
  redirects and a site-supplied `webrtc=allow` header cannot relax managed policy.
- Run the complete Windows DLP MVP native acceptance suite and inspect actual
  exported OpenTelemetry traces, durable deny events and exporter failures.

## Alternative runtime status

No tested prebuilt alternative is verified. Electron46 nightly20261013 with
Chromium157.0.8091.0 also crashes under the same blocked about:blank/srcdoc
attempts; its tagged binder source lacks the no-op implementation. A later
binary is acceptable only after source inclusion checks and all native gates
above. Current ignored artifacts retain the original crashes and positive
controls; an upgrade must not overwrite that evidence.