The argument there sounds like "libwebkit2gtk was never built to be resilient against non-trusted content" and "has no sandboxing". I don't have enough expertise to accurately judge both claims, but the last message in that above bug tread does not like a change is being considered.
The original bug report for this issue contains the following text [0]:
Although there is apparently some sandboxing in the use of webkit in
emacs (I read that it uses a seperate process, although not anywhere
authoritative), this still seems to be equivalent to shipping a
JavaScript enabled browser without any security support.
Debian packages in stable need security team support. It seems more like a procedural argument about support (i.e., "We don't want the security team to bother with another web browser embedded in Emacs") rather than technical ("It's impossible to have sandboxed Webkit in Emacs").
From a security perspective, this addon seems like the worst of both worlds: it's WebKit, so it's commonly attacked and prodded at, and it's relatively unsupported, so 0days are likely to stick around and fester.
As much as I love the idea of this, I would probably run it as a separate user, or maybe in a chroot or restricted namespace. Unfortunately, it would be pretty inconvenient to use a text editor that can't read my files!
The webpage for the library says it is suitable as the engine for web browsers and is used in a couple of browers. I think emacs is being used with an older version (>2) of the library that does not have full isolation.
This is very nice. I use Emacs extensively, even for reading email, but I do not allow Emacs to connect to the Internet directly.
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.
An effective exploit could be very high-value, though. Almost by definition, it would target users running development environments where lots of highly sensitive and highly profitable credentials and access could likely be obtained. It's not hard to imagine someone deciding it was worth their while, if browsing from Emacs via embedded Webkit were to catch on in a meaningful way.
OTOH emacs is used by a lot of people with access to sensitive data and/or industrial secrets, so the potential for malicious exploits is disproportional to its footprint
It isn't; you gain access to this functionality by building Emacs to use libgtk+ and instantiating the widget via a Lisp interface. (Not sure that's the right library. It might be different these days; I've been building my own Emacsen for a long time now, and I deliberately don't build with GTK or any other widget library since in my early experience that was a fertile source of Emacs-crashing bugs - which, of course, serves also to demonstrate that widgets live in the Emacs process and not outside it.)
Readit News
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914568
The argument there sounds like "libwebkit2gtk was never built to be resilient against non-trusted content" and "has no sandboxing". I don't have enough expertise to accurately judge both claims, but the last message in that above bug tread does not like a change is being considered.
From a security perspective, this addon seems like the worst of both worlds: it's WebKit, so it's commonly attacked and prodded at, and it's relatively unsupported, so 0days are likely to stick around and fester.
As much as I love the idea of this, I would probably run it as a separate user, or maybe in a chroot or restricted namespace. Unfortunately, it would be pretty inconvenient to use a text editor that can't read my files!
[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843462
Is there a reason for the scare quotes? In the Reddit thread, the author of xwwp says that the concerns are legitimate: https://np.reddit.com/r/emacs/comments/ifieb8/towards_a_seri...
https://webkitgtk.org
https://packages.debian.org/buster/epiphany-browser
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.
Firejail and other userland tools provide nice interfaces to these.
[1] https://lwn.net/Articles/580893/