4 ms·

>This is great for local development. Not just. There is a niche for mixed web/native apps whereby the page is loaded from the web, but interacts (at least in

>This is great for local development. Not just. There is a niche for mixed web/native apps whereby the page is loaded from the web, but interacts (at least in part) with a locally hosted web-server.

nerdponx 6y ago
Or even just browser apps that are easy/encouraged to run locally, like Jupyter Notebook.
- rhizome 6y ago
  Like, started from the local filesystem? I see they have a "Notebook Server," is that what you mean by "locally," rather than starting it from clicking an e.g. "jupyter.html" file? To their credit, it doesn't seem to use Node, and configuration via .py files tells me maybe they have some lightweight server thing that makes it a bit more manageable as a single-user app than via Node or Electron and friends. Anyway, I have a project I have been wanting to be completely self-contained in an HTML file, but that gives me CORS problems, so now I'm thinking maybe the Jupyter posse has implemented a nice compromise I can use.
  - nerdponx 6y ago
    Yes, Jupyter Notebook (and its successor Jupyter Lab) is a Python program that serves a browser (HTML/CSS/JS) application. It is meant to be used equally well when the Jupyter server is on your local machine or somewhere else on the network. Other tools that use similar architectures: Tabula, Kiwi IRC, The Lounge IRC. The user experience is maybe more "technical", but you don't have Electron involved, just whatever web browser you would use for anything else.
    - rhizome 6y ago
      The part that appeals to me is that they're using a smaller than nodejs (and Electron for that matter) local server to do so! CORS means something has to proxy, so seeing the existence of what I'm assuming is a minimum implementation is really helpful. Obviously I'm not hanging out in the right slacks or subreddits. ;)
est31 6y ago
I think it's a problem from a security point of view to allow websites to do this. Often the server that runs on localhost is poorly secured and may even expose "Access-Control-Allow-Origin: *" headers. And even if it doesn't, the browser still has to run a request to find out whether such a header is present, so some attacker controlled data does end up in these services. This in turn can be used for attacks. Maybe these services were coded assuming that an URL can only be 1 kb long? What if you overrun that buffer? For example did you know that cups runs a web server at http://localhost:631 http://localhost:631 ? TLDR: not a fan of this.
- bayindirh 6y ago
  > For example did you know that cups runs a web server at http://localhost:631 http://localhost:631 A typical Linux installation can run much more web servers on localhost. I run transmission-daemon, syncthing, cups, sometimes pagico (which is a desktop app which runs a php/web server backend on loopback). I guess that Firefox folks have thought of this otherwise, it'd be patched pretty quickly.
  - pimterry 6y ago
    CORS solves much of this - servers have to opt in to allowing these requests, just like any other cross-origin requests. Badwebsite.com in general cannot send a POST to bank.com/send-money from inside your browser, and similarly it cannot POST to localhost:631. There's caveats and of course servers can be configured insecurely, but this isn't a general risk by default.
    - minitech 6y ago
      Both of those requests can be sent. CORS just stops the response from being read. It’s up to web servers on localhost to assume they’re at just as much risk as any other non-local service, and they often fail to do so. (See also DNS rebinding that nets an attacker the opposite set of permissions, in a sense.)
      - 6y ago
SomeHacker44 6y ago
Like Zoom. Joy.
bigbubba 6y ago
I hate this shit, I've only seen the sketchiest sort of spyware, like discord, do it. Browsers should forbid it, since it's a blatant end-run around the limitations a 'web app' would normally have. Furthermore, browsers even having this ability facilitates inter-protocol exploitation. It's not only local webservers that are put at risk by this, other sorts of local servers can be attacked as well. See CVE-2016-8606 for an example of a browser being used to attack a guile repl.
edoceo 6y ago
Yes, I have a localhost running python script to communicate with serial devices and printers, so this makes it a bit easier. (I currently slide in a self-signed cert)

>This is great for local development. Not just. There is a niche for mixed web/native apps whereby the page is loaded from the web, but interacts (at least in part) with a locally hosted web-server.

nerdponx 6y ago

Or even just browser apps that are easy/encouraged to run locally, like Jupyter Notebook.

rhizome 6y ago
Like, started from the local filesystem? I see they have a "Notebook Server," is that what you mean by "locally," rather than starting it from clicking an e.g. "jupyter.html" file? To their credit, it doesn't seem to use Node, and configuration via .py files tells me maybe they have some lightweight server thing that makes it a bit more manageable as a single-user app than via Node or Electron and friends. Anyway, I have a project I have been wanting to be completely self-contained in an HTML file, but that gives me CORS problems, so now I'm thinking maybe the Jupyter posse has implemented a nice compromise I can use.
- nerdponx 6y ago
  Yes, Jupyter Notebook (and its successor Jupyter Lab) is a Python program that serves a browser (HTML/CSS/JS) application. It is meant to be used equally well when the Jupyter server is on your local machine or somewhere else on the network. Other tools that use similar architectures: Tabula, Kiwi IRC, The Lounge IRC. The user experience is maybe more "technical", but you don't have Electron involved, just whatever web browser you would use for anything else.
  - rhizome 6y ago
    The part that appeals to me is that they're using a smaller than nodejs (and Electron for that matter) local server to do so! CORS means something has to proxy, so seeing the existence of what I'm assuming is a minimum implementation is really helpful. Obviously I'm not hanging out in the right slacks or subreddits. ;)

est31 6y ago

I think it's a problem from a security point of view to allow websites to do this. Often the server that runs on localhost is poorly secured and may even expose "Access-Control-Allow-Origin: *" headers. And even if it doesn't, the browser still has to run a request to find out whether such a header is present, so some attacker controlled data does end up in these services. This in turn can be used for attacks. Maybe these services were coded assuming that an URL can only be 1 kb long? What if you overrun that buffer? For example did you know that cups runs a web server at http://localhost:631 http://localhost:631 ? TLDR: not a fan of this.

bayindirh 6y ago
> For example did you know that cups runs a web server at http://localhost:631 http://localhost:631 A typical Linux installation can run much more web servers on localhost. I run transmission-daemon, syncthing, cups, sometimes pagico (which is a desktop app which runs a php/web server backend on loopback). I guess that Firefox folks have thought of this otherwise, it'd be patched pretty quickly.
- pimterry 6y ago
  CORS solves much of this - servers have to opt in to allowing these requests, just like any other cross-origin requests. Badwebsite.com in general cannot send a POST to bank.com/send-money from inside your browser, and similarly it cannot POST to localhost:631. There's caveats and of course servers can be configured insecurely, but this isn't a general risk by default.
  - minitech 6y ago
    Both of those requests can be sent. CORS just stops the response from being read. It’s up to web servers on localhost to assume they’re at just as much risk as any other non-local service, and they often fail to do so. (See also DNS rebinding that nets an attacker the opposite set of permissions, in a sense.)
    - 6y ago

SomeHacker44 6y ago

Like Zoom. Joy.

bigbubba 6y ago

I hate this shit, I've only seen the sketchiest sort of spyware, like discord, do it. Browsers should forbid it, since it's a blatant end-run around the limitations a 'web app' would normally have. Furthermore, browsers even having this ability facilitates inter-protocol exploitation. It's not only local webservers that are put at risk by this, other sorts of local servers can be attacked as well. See CVE-2016-8606 for an example of a browser being used to attack a guile repl.

edoceo 6y ago

Yes, I have a localhost running python script to communicate with serial devices and printers, so this makes it a bit easier. (I currently slide in a self-signed cert)