In theory, yes. But if you follow the link and that leads to downloading the JS and running it, you're already too late inspecting it.
And even if you review it once (and it wasn't too large or obfuscated via minification), the next time you load a page, the JS can be different. I guess there could be a web browser extension for pinning the code?
The only practial alternative I know of is to have a local client you can review once (and after updates).
So the trick is to use the #fragment part of the URL, that is not sent to the server.
Of course the JS one downloads from the server could easily upload it to it, so you still need to trust the JS.
Alas my game PC is going to stick with Windows due to bad state of VR in Linux :/. And therefore one day it might need to update to Windows 11.
In particular if you have a headset that is not Valve Index, though apparently with Meta Quest one can use ALVR, as long as you get the actual games running.
Then there are the cases where you want the LLM to actually interact with the page, using the current web page state and your credentials.
For example, one might want to tell it to uncheck all the "opt in" checkboxes in the page.. And express this task in plain English language.
Many useful interactive agent tasks could be achieved with this. The chatbot would be merely the first step.
I haven't done it, but you could try socket activation.
Maybe consider static ip assignment in your DHCP server (e.g. internet router) if at all possible.. Then you can add a name to it to /etc/hosts.
Alternatively you could use Avahi to provide mdns names to your local network
Do you have that file? If not, then unset SSH_AUTH_SOCK will work just as well.
If it does exist, then I suppose it has good chances of working correctly :). ssh-add -l will try to use that socket and list your keys in the service (or list nothing if there are no keys, but it would still work without error).
At the end of the log you find:
822413 connect(4, {sa_family=AF_UNIX, sun_path="/run/user/1000/gcr/ssh"}, 110) = 0
...
822413 read(4,
meaning it's trying to interact with the ssh-agent, but it (finally) doesn't give a response.
Use the lsof command to figure out which program is providing the agent service and try to resolve issue that way. If it's not the OpenSSH ssh-agent, then maybe you can disable its ssh-agent functionality and use real ssh-agent in its place..
My wild guess is that the program might be trying to interactively verify the use of the key from you, but it is not succeeding in doing that for some reason.
I guess it's worth checking if those names point to the expected binaries, but I also think it would be highly unlikely they would be anything else than just /usr/bin/ssh and /usr/bin/ssh-agent.
As mentioned, -v (or -vv) helps to analyze the situation.
My theory is that you already have something providing ssh agent service, but that process is somehow stuck, and when ssh tries to connect it, it doesn't respond to the connect, or it accepts the connection but doesn't actually interact with ssh. Quite possibly ssh doesn't have a timeout for interacting with ssh-agent.
Using eval $(ssh-agent -s) starts a new ssh agent and replaces the environment variables in question with the new ones, therefore avoiding the use of the stuck process.
If this is the actual problem here, then before running the eval, echo $SSH_AUTH_SOCK would show the path of the existing ssh agent socket. If this is the case, then you can use lsof $SSH_AUTH_SOCK to see what that process is. Quite possibly it's provided by gnome-keyring-daemon if you're running Gnome. As to why that process would not be working I don't have ideas.
Another way to analyze the problem is strace -o logfile -f ssh .. and then check out what is at the end of the logfile. If the theory applies, then it would likely be a connect call for the ssh-agent.
I think the main problem is that Chromium still contributes towards the browser engine monoculture, as it is bug-for-bug compatible with Chrome. Therefore if you switch to Chromium, it's still enough for the web sites to test for Chrome compatibility, which they will, because it has the largest market share. Users of competing browsers suffer, further driving the lure of Chrome (or Chromium).
On the other hand, if people switched to some other engine, one that does not share the same core engine or even the same history, this will no longer hold: web sites would need to be developed against the spec, or at least against all the browsers they might realistically expect their customers to use.
Where should they be "taking" funding instead?