BrowserSignatureInvalid message

Okay, so I'll open by saying I know I'm in an unsupported configuration. I'm not looking for anyone to fix it for me, that's on me. I'm hoping I can get one piece of information that will help me fix it on my own.

The one question is: What method does 1Password-BrowserSupport (currently) use to determine what the parent process is in order to match it with /etc/1password/custom_allowed_browsers on Linux? And is it by de-referencing /proc/$PARENT_PID/exe? If I can get that one hint, I think that I will be able to work through the rest of it from there.

I suspect that because of the insane config that I'm trying to run, 1Password-BrowserSupport can't access whatever information it usually uses to validate what process is calling it. Because of that, it's failing with a BrowserSignatureInvalid message.

If you're curious, here's the gory details:

I've currently got 1password running successfully in a container, all except for the browser integration. It doesn't notice that it's in a container and seems to be happy, except this one thing.

The browser is Zen in a Flatpak (I know, I know, all the unsupported configs in one post). What currently happens is that in the browser Flatpak, Zen:

1. Calls the native messaging wrapper, which
2. Execs to flatpak-spawn, which
3. Execs to a wrapper in the host, which
4. Uses podman (via distrobox) to exec into the container, which
5. Execs to conmon (inside the container) which then
6. Runs 1Password-BrowserSupport as a subprocess

Testing this chain on another binary, it looks like everything is working fine. There are no extra processes in the process chain, and all command line arguments are passed without alteration. Input 

Debugging the extension code, I'm getting the following response message:

{
  "type": "BrowserVerificationFailed",
  "content": "BrowserSignatureInvalid"
}

I have the following in my /etc/1password/custom_allowed_browsers (in the container):

zen-bin
flatpak-session-helper
zen
conmon
bash

(Yes, I tried putting bash in there in case it was getting hung up on that)

My suspicion is that it might be trying to read /proc/$PPID/exe, which would work on flatpak-session-helper, but not on conmon (if I understand what's going on under the hood correctly). It would be awesome to get that confirmed which would allow me to hone in on the right solution.

I'm just hoping my insanity tickles some dev on the team in the right way to confirm or deny it. I promise to write a blog post about this if I get it working.