5 ms·

Do note that since the removal of NPAPI plugins years ago, locally-installed software that intends to be used by one or more public websites has to run an HTTP

by ronsor 1y ago

Do note that since the removal of NPAPI plugins years ago, locally-installed software that intends to be used by one or more public websites has to run an HTTP server on localhost. It would be really annoying if this use case was made into an unreasonable hassle or killed entirely. (Alternatively, browser developers could've offered a real alternative, but it's a bit late for that now.)

donnachangstein 1y ago
[flagged]
- afavour 1y ago
  > Googlers present a solution no one is asking for, I'm asking for it. Random web sites have no business poking around my internal network.
  - moralestapia 1y ago
    >I'm asking for it. Proof? Link to issue? Mailing list? Anything? I think you just made that up.
    - ImPostingOnHN 1y ago
      > Proof? ... Anything? I saw them ask for it in the post you're responding to. I am also asking for it right now. That's 2 people asking for it so far. > Link to issue? Mailing list? That is not necessary.
      - moralestapia 1y ago
        Wow, so Google is sitting on a time machine that can see the future. Amazing!
        ImPostingOnHN 1y ago
        What an interesting, non-sequitur response.
RagingCactus 1y ago
I don't believe this is true, as https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web... exists. It does need an extension to be installed, but I think that's fair in your comparison with NPAPI.
michaelt 1y ago
Doesn't most software just register a protocol handler with the OS? Then a website can hand the browser a zoommtg:// link, which the browser opens with zoom ? Things like Jupyter Notebooks will presumably be unaffected by this, as they're not doing any cross-origin requests. And likewise, when a command line tool wants you to log in with oauth2 and returns you to a localhost URL, it's a simple redirect not a cross-origin request, so should likewise be allowed?
- ronsor 1y ago
  That works if you want to launch an application from a website, but it doesn't work if you want to actively communicate with an application from a website.
  - fn-mote 1y ago
    This needs more detail to make it clear what you are wishing for that will not happen. It seems like you're thinking of a specific application, or at least use-case. Can you elaborate? Once you're launching an application, it seems like the application can negotiate with the external site directly if it wants.
    - xp84 1y ago
      #1 use case would be a password manager. It would be best if the browser plugin part can ping say, the 1password native app, which runs locally on your pc, and say "Yo I need a password for google.com" - then the native app springs into action, prompts for biometrics, locates the password or offers the user to choose, then returns it directly to the browser for filling. Sure you can make a fully cloud-reliant PW manager, which has to have your key stored in the browser and fetch your vault from the server, but a lot of us like having that information never have to leave our computers.
      - spiffyk 1y ago
        Browser extensions play by very different rules than websites already. The proposal is for the latter and I doubt it is going to affect the former, other than MAYBE an extra permanent permission.
ImPostingOnHN 1y ago
> locally-installed software that intends to be used by one or more public websites has to run an HTTP server on localhost if that software runs with a pull approach, instead of a push one, the server becomes unnecessary bonus: then you won't have websites grossly probing local networks that aren't theirs (ew)
- rhdunn 1y ago
  It's harder to run html and xml files with xslt by just opening them in a web browser (things like nunit test run output). To view these properly now -- to get the css, xslt, images, etc. to load -- you now typically have to run a web server at that file path. Note: this is why the viewers for these tools will spin up a local web server. With local LLMs and AI it is now common to have different servers for different tasks (LLM, TTS, ASR, etc.) running together where they need to communicate to be able to create services like local assistants. I don't want to have to jump through hoops of running these through SSL (including getting a verified self-signed cert.), etc. just to be able to run a local web service.
  - ImPostingOnHN 1y ago
    I'm not sure any of that is necessary for what we're talking about: locally-installed software that intends to be used by one or more public websites. For instance, my interaction with local LLMs involves 0 web browsers, and there's no reason facebook.com needs to make calls to my locally-running LLM. Running HTML/XML files in the browser should be easier, but at the moment it already has the issues you speak of. It might make sense, IMO, for browsers to allow requests to localhost from websites also running on localhost.
IshKebab 1y ago
It would be amazing if that method of communicating with a local app was killed entirely, because it's been a very very common source of security vulnerabilities.

by ronsor 1y ago

donnachangstein 1y ago

[flagged]

afavour 1y ago
> Googlers present a solution no one is asking for, I'm asking for it. Random web sites have no business poking around my internal network.
- moralestapia 1y ago
  >I'm asking for it. Proof? Link to issue? Mailing list? Anything? I think you just made that up.
  - ImPostingOnHN 1y ago
    > Proof? ... Anything? I saw them ask for it in the post you're responding to. I am also asking for it right now. That's 2 people asking for it so far. > Link to issue? Mailing list? That is not necessary.
    - moralestapia 1y ago
      Wow, so Google is sitting on a time machine that can see the future. Amazing!
      - ImPostingOnHN 1y ago
        What an interesting, non-sequitur response.

RagingCactus 1y ago

I don't believe this is true, as https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web... exists. It does need an extension to be installed, but I think that's fair in your comparison with NPAPI.

michaelt 1y ago

Doesn't most software just register a protocol handler with the OS? Then a website can hand the browser a zoommtg:// link, which the browser opens with zoom ? Things like Jupyter Notebooks will presumably be unaffected by this, as they're not doing any cross-origin requests. And likewise, when a command line tool wants you to log in with oauth2 and returns you to a localhost URL, it's a simple redirect not a cross-origin request, so should likewise be allowed?

ronsor 1y ago
That works if you want to launch an application from a website, but it doesn't work if you want to actively communicate with an application from a website.
- fn-mote 1y ago
  This needs more detail to make it clear what you are wishing for that will not happen. It seems like you're thinking of a specific application, or at least use-case. Can you elaborate? Once you're launching an application, it seems like the application can negotiate with the external site directly if it wants.
  - xp84 1y ago
    #1 use case would be a password manager. It would be best if the browser plugin part can ping say, the 1password native app, which runs locally on your pc, and say "Yo I need a password for google.com" - then the native app springs into action, prompts for biometrics, locates the password or offers the user to choose, then returns it directly to the browser for filling. Sure you can make a fully cloud-reliant PW manager, which has to have your key stored in the browser and fetch your vault from the server, but a lot of us like having that information never have to leave our computers.
    - spiffyk 1y ago
      Browser extensions play by very different rules than websites already. The proposal is for the latter and I doubt it is going to affect the former, other than MAYBE an extra permanent permission.

ImPostingOnHN 1y ago

> locally-installed software that intends to be used by one or more public websites has to run an HTTP server on localhost if that software runs with a pull approach, instead of a push one, the server becomes unnecessary bonus: then you won't have websites grossly probing local networks that aren't theirs (ew)

rhdunn 1y ago
It's harder to run html and xml files with xslt by just opening them in a web browser (things like nunit test run output). To view these properly now -- to get the css, xslt, images, etc. to load -- you now typically have to run a web server at that file path. Note: this is why the viewers for these tools will spin up a local web server. With local LLMs and AI it is now common to have different servers for different tasks (LLM, TTS, ASR, etc.) running together where they need to communicate to be able to create services like local assistants. I don't want to have to jump through hoops of running these through SSL (including getting a verified self-signed cert.), etc. just to be able to run a local web service.
- ImPostingOnHN 1y ago
  I'm not sure any of that is necessary for what we're talking about: locally-installed software that intends to be used by one or more public websites. For instance, my interaction with local LLMs involves 0 web browsers, and there's no reason facebook.com needs to make calls to my locally-running LLM. Running HTML/XML files in the browser should be easier, but at the moment it already has the issues you speak of. It might make sense, IMO, for browsers to allow requests to localhost from websites also running on localhost.

IshKebab 1y ago

It would be amazing if that method of communicating with a local app was killed entirely, because it's been a very very common source of security vulnerabilities.