There are two flaws in the current implementation:
There are many ways (see e.g. https://github.com/cure53/HTTPLeaks) to replace XHR and consequently evade the wrapper. This can be mitigating by monitoring the requests using Web Request API.
The confirm method puts a lot of responsibility on the user who needs to have a good knowledge about the requests on each visited page.
Because we mimic Firefox behaviour, a Chromium derived browser becomes more easily fingerprintable. This can be fixed by properly wrapping BatteryManager.prototype getters and setters.
The standard provides an event gamepadconnected and gamepaddisconnected that fires at least on the window object. We do not mitigate the event to fire and consequently, it is possible that an adversary can learn that a gamepad was (dis)connected but there was no change in the result of the navigator.getGamepads() API.
The standard provides events vrdisplayconnect, vrdisplaydisconnectvrdisplayactivate and vrdisplaydeactivate that fires at least on the window object. We do not mitigate the event to fire and consequently, it is possible that an adversary can learn that a VR display was (dis)connected but there was no change in the result of the navigator.activeVRDisplays() API.