I've been hacking away at a browser-based tool that uses anthropic APIs on the backend. But what I really want is for the browser to talk to my local claude becuase I have MCPs, skills, network access for a bunch of things.
I started with a little proxy installed on my computer that the browser can call but knew it would never pass any security review. The alternative I didn't originally know about was Native Messaging.
It's a fairly benign way to let a browser talk to and execute commands on your computer. But doing it without disclosing is, I agree, very bad.
Nothing wrong about running http server on your localhost and talk to it. A lot of applications do that. The best thing: you don't need to appease extension appstores, you just ship.
The only nuance is that recent chrome versions treat it as a separate permission, so user need to allow it once.
Yes, native messaging is the "proper" way to do that, but, again, nothing wrong with localhost http server. You have origin headers so you can allow access from your whitelisted website, if necessary.
You only have origin headers that you can trust if the traffic originated from a browser you trust.
Anything else on the machine that can send network traffic can now hook into your service. Which is quite a bit looser than being able to start a new process running that native message host and hook into its stdio.
This is how native messaging works in extensions. Apps declare via manifest that extensions can talk to them.
Further - the user still has to install the extension in the browser and the user has to approve the permissions popup that explicitly states the extension will have permission to "Communicate with cooperating native applications." See: https://developer.chrome.com/docs/extensions/reference/permi...
So it's hardly undisclosed. Every user with the extension has accepted this permissions popup that communicates that this is happening and allowed.
(whether permissions prompts like this are actually helpful is a different topic).
The problem for me is that this is littering my drive with files in directory's for browsers I have never installed. I have never installed Arc or Brave or a few other of the browsers, but now I have directory's for them in my Application Support folder.
Is it an easy cleanup? Sure. But I shouldn't be seeing support folders for apps I have never installed on my machine, ever.
> But I shouldn't be seeing support folders for apps I have never installed on my machine, ever.
I don't know why you think this?
Macos uses application support as a place for user preferences and configuration. That chrome directory claude desktop creates is configuration FOR CLAUDE DESKTOP that instructs chrome (existing or future installs) that it's allowed to start processes related to claude desktop.
On windows - this would have been a registry key for chrome pointing to the manifest file location
On linux - it would be in .config/google-chrome
These directories/settings explicitly exist in well-known locations to allow applications to configure and interoperate with each other.
---
That fact that you might not have chrome installed at this moment is irrelevant. Honestly, I much prefer that it place the file regardless for two reasons
1. You might install chrome later, and this flow shouldn't require you to start claude desktop again to work
2. To be smart here is WAY worse. It would mean claude desktop needs to scan your machine for a variety of applications on each launch, get their install locations correct across each OS version, and have permissions to do this check, and then change behavior based on the results. Which I imagine based on the hyperbole in this thread already... is going to get them even worse press - not to mention be just incredibly annoying to maintain and flakey to support.
I've been using Edge for a couple years now. I used to laugh at the idea of using Internet Explorer I mean Edge but it's actually pretty good and quite performant.
Same Chromium rendering engine (e.g. as opposed to using Firefox or Safari, which I'd prefer but especially for frontend development testing against Chromium is ideal given their market share) and same keyboard shortcuts as Chrome so was an easy transition.
Previous version that was [flagged] away from the homepage, even though I now see that the flag was since removed:
https://news.ycombinator.com/item?id=47829800 (125 upvotes, 34 comments)
The flag was removed and it was boosted back to front page by mods, it had a fair shake.
So this is a [dupe]
I only learned about Native Messaging this week.
I've been hacking away at a browser-based tool that uses anthropic APIs on the backend. But what I really want is for the browser to talk to my local claude becuase I have MCPs, skills, network access for a bunch of things.
I started with a little proxy installed on my computer that the browser can call but knew it would never pass any security review. The alternative I didn't originally know about was Native Messaging.
It's a fairly benign way to let a browser talk to and execute commands on your computer. But doing it without disclosing is, I agree, very bad.
(tool I'm hacking away at needs to talk to local claude and acli: https://withlattice.com)
Check out the hidden --sdk-url CLI option for claude.
It turns it into a websocket endpoint you can just connect to (iirc it's what the Python SDK does under the hood).
detail: https://medium.com/coding-nexus/i-found-a-hidden-flag-in-cla...
That’s very cool - did not know about that.
Listening for commands to run seems similarly dangerous as having a proxy installed!
Nothing wrong about running http server on your localhost and talk to it. A lot of applications do that. The best thing: you don't need to appease extension appstores, you just ship.
The only nuance is that recent chrome versions treat it as a separate permission, so user need to allow it once.
Yes, native messaging is the "proper" way to do that, but, again, nothing wrong with localhost http server. You have origin headers so you can allow access from your whitelisted website, if necessary.
I'd argue native messaging is much more secure.
You only have origin headers that you can trust if the traffic originated from a browser you trust.
Anything else on the machine that can send network traffic can now hook into your service. Which is quite a bit looser than being able to start a new process running that native message host and hook into its stdio.
Personally, this is a nothing-burger.
This is how native messaging works in extensions. Apps declare via manifest that extensions can talk to them.
Further - the user still has to install the extension in the browser and the user has to approve the permissions popup that explicitly states the extension will have permission to "Communicate with cooperating native applications." See: https://developer.chrome.com/docs/extensions/reference/permi...
So it's hardly undisclosed. Every user with the extension has accepted this permissions popup that communicates that this is happening and allowed.
(whether permissions prompts like this are actually helpful is a different topic).
The problem for me is that this is littering my drive with files in directory's for browsers I have never installed. I have never installed Arc or Brave or a few other of the browsers, but now I have directory's for them in my Application Support folder.
Is it an easy cleanup? Sure. But I shouldn't be seeing support folders for apps I have never installed on my machine, ever.
> But I shouldn't be seeing support folders for apps I have never installed on my machine, ever.
I don't know why you think this?
Macos uses application support as a place for user preferences and configuration. That chrome directory claude desktop creates is configuration FOR CLAUDE DESKTOP that instructs chrome (existing or future installs) that it's allowed to start processes related to claude desktop.
On windows - this would have been a registry key for chrome pointing to the manifest file location
On linux - it would be in .config/google-chrome
These directories/settings explicitly exist in well-known locations to allow applications to configure and interoperate with each other.
---
That fact that you might not have chrome installed at this moment is irrelevant. Honestly, I much prefer that it place the file regardless for two reasons
1. You might install chrome later, and this flow shouldn't require you to start claude desktop again to work
2. To be smart here is WAY worse. It would mean claude desktop needs to scan your machine for a variety of applications on each launch, get their install locations correct across each OS version, and have permissions to do this check, and then change behavior based on the results. Which I imagine based on the hyperbole in this thread already... is going to get them even worse press - not to mention be just incredibly annoying to maintain and flakey to support.
Google Chrome installs a bunch of spyware too, nobody bats an eye
I'm batting my eye.
I've been using Edge for a couple years now. I used to laugh at the idea of using Internet Explorer I mean Edge but it's actually pretty good and quite performant.
Same Chromium rendering engine (e.g. as opposed to using Firefox or Safari, which I'd prefer but especially for frontend development testing against Chromium is ideal given their market share) and same keyboard shortcuts as Chrome so was an easy transition.
I am beginning to suspect that Anthropic may not be as ethical as they purport themselves to be.
Oh no it's the model that's ethical, not the company.
They work with Palantir. That says what you need to know about their ethics.
A corporation being shady? Imagine that!