Hacker News Reader

Comment by cheez | Hacker News Reader

can you elaborate? My understanding is this is a separate process.

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.)

Would it be insane to use chrome webdriver to do something like this; manipulating a normal chrome(/ium) instance from Emacs?

No, but it wouldn't work the same. Browsing via a Webkit widget is nice because the browser UI (which is just Webkit, without any of the standard browser chrome) lives inside an Emacs buffer, and you interact with it within Emacs' own UI paradigm as well as from Lisp. I think only Lisp interaction would be possible via webdriver.

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.

Without knowing about the implementation, I can speculate (always dangerous ;-)) that the web browser exploit potential is loading a web page, the elements, html, js, images, nested loading of other stuff. So the danger is some kind of crash in the code that evaluates these resources and then stack-overflow kind of deal gets your machine to do something, kind of like a regular browser risk, and there's no hardening against it. This sounds like a capability I want for emacs though, I wonder if there's some way to make it safer; I could create a separate account and ssh in from my main session and run emacs. If I set my display variable to display from fakeme to real me what xwindows risks do I incur? I've never understood that level.

Yeah, I think the attack surface would be in the integration. The Emacs developers are very good in general, but I don't know if they're well placed to address the security concerns of a browser integration, especially in such an otherwise laissez-faire platform as Emacs. Webkit should be pretty secure, I'd expect, but that only helps until you get to where Webkit and Emacs interact in Emacs' own process space.

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 on regular old linux with xwindows like ubuntu or whatever, suppose I want to use this new deal and also I now don't trust X as well as emacs itself. I create another user that can't SU, and I vnc into a new session, and run dangerous-emacs. You could make the history and text files readable from your main user.

So now VNC is your trust boundary. I should try eww again too.

Reply on news.ycombinator.com