Chrome DOM as a Erlang process?

[zeroexcuses]

1. Please take a look at threepenny-gui: GUI framework that uses the web browser as a display. before responding. Otherwise, what I am proposing and what you think I am proposing might be different.

2. Completely forget about network latency for now. Consider only the case where client (chrome browser) + server (elixir) are both on localhost over websocket.

3. One can imagine a Chrome tab as an “Elixir process”: we can send the Chrome tab messages to update the DOM; the Chrome tab sends us messages on GUI input (mouse movement/click, keyboard press), and results of evaluating arbitrary JS in the tab. [For this discussion, please do not derail with security issues; this is for local dev where we trust both sides.]

4. Is there a library for doing Elixir GUI like this? If so, where? If not, what is the flaw in this idea (no, latency can’t be the issue with everything on localhost). The key idea being:

Chrome tab = we send it msgs for updating DOM; it sends us mgs for GUI input

Thanks

[Exadra37]

@zeroexcuses

[For this discussion, please do not derail with security issues; this is for local dev where we trust both sides.]

From the moment you load Javascript from third parties in your application you cannot trust both parties, even if his only in localhost. Plus, if you have extensions installed in your browser, then you will have another attack vector, because they have too much permissions, a lot more then they should be allowed.

But lets leave it here, and don’t derail more your topic.

[zeroexcuses]

@Exadra37

From the moment you load Javascript from third parties in your application you cannot trust both parties, even if his only in localhost. Plus, if you have extensions installed in your browser, then you will have another attack vector, because they have too much permissions, a lot more then they should be allowed.

But lets leave it here, and don’t derail more your topic.

With all due respect, have you read the threepenny gui design documentation? This seems to be pretty clear as a strawman of

@zeroexcuses

• Please take a look at threepenny-gui: GUI framework that uses the web browser as a display. before responding. Otherwise, what I am proposing and what you think I am proposing might be different.

[zeroexcuses]

@Exadra37

From the moment you load Javascript from third parties in your application you cannot trust both parties, even if his only in localhost. Plus, if you have extensions installed in your browser, then you will have another attack vector, because they have too much permissions, a lot more then they should be allowed.

This “argument” boils down to: “Because Exadraa37 has a Chrome session that executes untrusted JS, it is impossible to secure a Chrome tab”

[derek-zhou]

If it is localhost only, why do we need websocket, or http? A pipe is even simpler and more secure.

[zeroexcuses]

The goal here is to use the Chrome DOM Tree as UI and control it from Elixir.

Non-rhetoric question: is it easy to open unix pipes from standard Chrome? (I have never attempted).

[derek-zhou]

My question was purely theoretical; I did not consider the current limitation of anything.

If someone can take the core chrome or firefox and turn it into a dumb GUI “terminal”, to talk to a backend process via pipe, we can have a generic GUI framework that can work with any language.

[al2o3cr]

From the threepenny doc:

The web server displays a HTML page, which in turn establishes WebSocket connection with the server. The server uses this connection to send JavaScript code that is executed in the client.

This sounds a LOT like what you’d get with a browser + a local server + LiveView.