Lots of design decisions in Emacs make a lot of sense for a text editor, or for a Lisp VM in the 80s, but are quite insecure if you plan to browse a potentially hostile environment.
Emacs is so obscure that nobody bothers to work on emacs exploits, so your worry is not really justified.
Stealing source code is a valuable enough goal, and doable cross platform with the file system APIs.
If exfiltrating source code was easy to detect, ssh secret keys are stored in consistent locations across machines and are comparatively small. Stealing these would be quite lucrative.
Emacs is a general-purpose programming environment that also implements an editor. By design, it has no internal boundaries. Anything that can run in that environment can read and write the filesystem and process environment, open arbitrary sockets, execute arbitrary commands, and otherwise interact with the local system - and, given TRAMP, also remote systems - as the user under whose account Emacs is running. You don't need to know much of anything about the underlying system to use these capabilities. You just need to know about Emacs. And whatever you do need to know about the underlying system to perform whatever attack you have in mind, Emacs will happily help you learn.
What about RCE in such an environment does not say "game over" to you?
Maybe those numbers look completely different for people who use Emacs as their browser, no idea, but I'd doubt it, I'd still expect esoteric distros like Nix or Qubes to be a small minority.
And since most companies aren't Google or otherwise really, really good at security, and people are lazy, I'd expect to find a lot of passwordless SSH keys with access to prod servers and the like on those machines. And if not, there will be some other way to penetrate prod, if you own the machine and are determined. There will be some way to access secrets, too, in most places – there are companies that store them in git along with their code, since Github is very secure etc.
[1] https://insights.stackoverflow.com/survey/2020#technology-de...
Not sure anybody uses Qubes.
This feature uses webkit2gtk [1] which is the base for multiple full web browsers [2] and supports webkit2's normal web process isolation [3]. Is the sandboxing disabled for some reason?
[1] https://emacs.stackexchange.com/questions/48670/the-status-o...
[2] https://wiki.archlinux.org/index.php/List_of_applications#We...
[3] https://webkitgtk.org/ & https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-secu...
Firejail and other userland tools provide nice interfaces to these.
It'd be more like the old integration between js2-mode and MozRepl (RIP), where you can drive the browser and send code for evaluation, but the browser isn't part of Emacs in the way xwidget-webkit allows.
You make a good point about X. I don't know a great deal about its security either, and most of what I do know comes from jwz's various salty comments about the risks of poorly implemented screen lockers. Based on that, and for whatever it's worth, the strong impression I have of X server security is that, for any client permitted to connect in the first place, there is likewise little to none of it.
It's been a while since I looked in detail at Emacs' xlib integration. But it's evidently comprehensive enough for EXWM to exist, and looking at the EXWM readme, I find it's based on a pure-Lisp X protocol implementation. So I assume that anything an X client can ask an X server to do, you can ask an X server to do from within Emacs, and you don't even need that Emacs to have been specially compiled with support for the protocol - you just need it to evaluate some Lisp, and you're off and running.
I think I'll stick with eww for the foreseeable future.
So now VNC is your trust boundary. I should try eww again too.