Scoop + Docker's VPNKit + cnn.com

[rebeccacremona]

Background

Versions of Docker Desktop for Mac prior to 4.19.0 used a utility called VPNKit to ensure that traffic from the Docker helper VM makes it to the live web even when users are running restrictively-configured VPNs on the host. Beginning in 4.19.0, for macOS Ventura and above, they switched to gVisor, which they say results in "5x faster container-to-host networking." A person running 4.19.0 can opt into using VPNKit by opening ~/Library/Group\ Containers/group.com.docker/settings.json and toggling networkType from gvisor to vpnkit. (I quit Docker before making the change; I don't know what happens if you make a change while the Docker daemon is running.)

Observed behavior

If Scoop is installed in a Docker image, and you run a container that attempts to capture https://cnn.com on a machine configured to use VPNKit, it will reliably fail with the following trace:

file:///scoop/node_modules/@harvard-lil/scoop/utils/blocklist.js:57
    return Boolean(val.match?.(matcher))
                       ^

TypeError: Cannot read properties of undefined (reading 'match')
    at file:///scoop/node_modules/@harvard-lil/scoop/utils/blocklist.js:57:24
    at Array.find (<anonymous>)
    at file:///scoop/node_modules/@harvard-lil/scoop/utils/blocklist.js:70:28
    at Array.findIndex (<anonymous>)
    at ScoopProxy.findMatchingBlocklistRule (file:///scoop/node_modules/@harvard-lil/scoop/intercepters/ScoopProxy.js:218:30)
    at ScoopProxy.onConnected (file:///scoop/node_modules/@harvard-lil/scoop/intercepters/ScoopProxy.js:141:23)
    at Server.emit (node:events:513:28)
    at TLSSocket.onSocketConnect (file:///scoop/node_modules/@harvard-lil/portal/Portal.js:194:17)
    at TLSSocket.emit (node:events:525:35)
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1479:10)

The error may occur anywhere in the process, including at the very end when the capture is complete:

[13:49:02] INFO 🍨 Starting capture of http://cnn.com/.
[13:49:02] INFO STEP [1/10]: Out-of-browser detection and capture of non-web resource
[13:49:02] INFO Requested URL is a web page
[13:49:02] INFO STEP [2/10]: Wait for initial page load
[13:49:22] WARN STEP [2/10]: Wait for initial page load - failed
[13:49:22] INFO STEP [3/10]: Capture page info
[13:49:22] INFO STEP [4/10]: Browser scripts
[13:50:02] INFO captureTimeout of 60000ms reached. Ending further capture.
[13:50:02] INFO STEP [5/10]: Wait for network idle
[13:50:03] INFO STEP [6/10]: Scroll-up
[13:50:03] INFO STEP [7/10]: Screenshot
[13:50:04] INFO STEP [8/10]: Out-of-browser capture of video as attachment (if any)
[13:50:05] WARN STEP [8/10]: Out-of-browser capture of video as attachment (if any) - ended due to max time or size reached.
[13:50:05] INFO STEP [9/10]: Capturing certificates info
[13:50:06] INFO STEP [10/10]: Provenance summary
[13:50:06] INFO Closing browser and intercepter
file:///scoop/node_modules/@harvard-lil/scoop/utils/blocklist.js:57
    return Boolean(val.match?.(matcher))
                       ^

TypeError: Cannot read properties of undefined (reading 'match')

Sometimes the container immediately exits with an error code when this happens; sometimes the container keeps running (without accomplishing any further work) until you kill it.

With gVisor, capture reliably succeeds: I have never seen an error like the above.

What's going on here?

Unclear.

It turns out there are a lot of settings related to VPNKit in ~/Library/Group\ Containers/group.com.docker/settings.json, among them:

  "vpnKitMTU": 1500,
  "vpnKitMaxConnections": 2000,
  "vpnKitMaxPortIdleTime": 300,

But, nothing I tried seemed to have any effect. I tried increasing the MaxConnections to 5000, increasing MaxPortIdleTime to 900, and increasing the MTU to 3000, one at a time, and it still threw the same error, in the same way.

So... who knows...

Is this a bug, or a fatal Docker environment quirk?

I don't know! What do you think?

It seems extremely weird that, evidently, with whatever-all is going on behind the scenes, url is evidently coming back as undefined here. It's hard to imagine what a useful non-fatal decision would be: if url is undefined, this exchange is going to be messed up...

But, since this often happens really late in the process, so late that we could definitely have a beautiful WACZ, I feel like it would be good to try to recover. Maybe serverSocket.destroy() with a warning message?