Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Claude for Chrome

anthropic.com

Post reply on HN
Print view View original

291–300 of 433 posts

Re: Claude for Chrome

#291

Post by makeitdouble »

asdff wrote: post #204
parsabg wrote: post #126

I built a very similar extension [1] a couple of months ago that supports a wide range of models, including Claude, and enables them to take control of a user's browser using tools for mouse and keyboard actions, observation, etc. It's a fun little project to look at to understand how this type of thing works. It's clear to me that the tech just isn't there yet. The information density of a web page with standard rep…

It is kind of funny how the systems are set up where there often is dense and queryable information out there already for a lot of these tasks, but these are ignored in favor of the difficult challenge of brute forcing the human consumer facing ui instead of some existing api that is designed to be machine readable already. E.g. booking flights. Travel agents use software that queries all the airlines ticket inventor…

This was the Rabbit R1's connundrum. Uber/DoorDash/Spotify have APIs for external integration, but they require business deals and negociations.

So how to evade talking to the service's business people ? Provide a chain of Rube Goldberg machines to somewhat use these services as if it was the user. It can then be touted as flexibility, and blame the state of technology when it inevitably breaks, if it even worked in the first place.

Re: Claude for Chrome

#292

Post by artifact_44 »

dfabulich wrote: post #272

Claude for Chrome seems to be walking right into the "lethal trifecta." https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/ "The lethal trifecta of capabilities is:" • Access to your private data —one of the most common purposes of tools in the first place! • Exposure to untrusted content —any mechanism by which text (or images) controlled by a malicious attacker could become available to your LLM • The abilit…

[dead]

Re: Claude for Chrome

#293

Post by mkl »

dotproto wrote: post #269
mkl wrote: post #179

Earlier quoted context omitted.

Just make a separate browser profile for it. That's easy in Chrome.

Also pretty easy with Firefox's new profile manager https://support.mozilla.org/kb/profile-management

Oh, excellent. I use profiles in Firefox too, but it's been quite awkward in comparison.

Re: Claude for Chrome

#294

Post by nsonha »

whatevertrevor wrote: post #239
kokanee wrote: post #189

Earlier quoted context omitted.

Just the pesky matter of figuring out what humans will do for money, and then we'll be free to run in the meadows like we were meant to

Maybe in the short term, but I think ultimately there are lots of things Humans want (AI or no AI), and that means there's a lot of value to create in the world still. Which means there will still be jobs, just maybe not as much in the churning-out-websites-and-"content"-business. Don't get me wrong I'm not trying to flippant about the potential for destroyed value here. Many industries (like journalism*) really need…

Physical crafts and some niche software still. Once robots are given opposable thumbs and large motion models get enough data, there will be nothing left. The tech is already there, just the matter of time. I'm counting on the human race to keep direct funding to software slop and delay that future, but damn China.

Re: Claude for Chrome

#295

Post by medhir »

onesociety2022 wrote: post #217
medhir wrote: post #26

Personally, the only way I’m going to give an LLM access to a browser is if I’m running inference locally. I’m sure there’s exploits that could be embedded into a model that make running locally risky as well, but giving remote access to Anthropic, OpenAI, etc just seems foolish. Anyone having success with local LLMs and browser use?

The primary risk with these browser agents is prompt injection attacks. Running it locally doesn't help you in that regard.

True, I wasn’t thinking very deeply when I wrote this comment… local models indeed are prone to the same exploits.

Regardless, giving a remote API access to a browser seems insane. Having had a chance to reflect, I’d be very wary of providing any LLM access to take actions with my personal computer. Sandbox the hell out of these things.

Re: Claude for Chrome

#296

Post by jimbokun »

afarviral wrote: post #281
dfabulich wrote: post #272

Claude for Chrome seems to be walking right into the "lethal trifecta." https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/ "The lethal trifecta of capabilities is:" • Access to your private data —one of the most common purposes of tools in the first place! • Exposure to untrusted content —any mechanism by which text (or images) controlled by a malicious attacker could become available to your LLM • The abilit…

How would you go about making it more secure but still getting to have your cake too? Off the top my head, could you: a) only ingest text that can be OCRd or somehow determine if it is human readable b) make it so text from the web session is isolated from the model with respect to triggering an action. Then it's simply a tradeoff at that point.

I don't believe it's possible to give an LLM full access to your browser in a safe way at this point in time. There will need to be new and novel innovations to make that combination safe.

Re: Claude for Chrome

#298

Post by maximilianthe1 »

kccqzy wrote: post #284
afarviral wrote: post #281

Earlier quoted context omitted.

How would you go about making it more secure but still getting to have your cake too? Off the top my head, could you: a) only ingest text that can be OCRd or somehow determine if it is human readable b) make it so text from the web session is isolated from the model with respect to triggering an action. Then it's simply a tradeoff at that point.

I think Simon has proposed breaking the lethal trifecta by having two LLMs, where the first has access to untrusted data but cannot do any actions, and the second LLM has privileges but only abstract variables from the first LLM not the content. See https://simonwillison.net/2023/Apr/25/dual-llm-pattern/ It is rather similar to your option (b).

Can't the attacker then jailbreak the first LLM to generate jailbreak with actions for the second one?

Re: Claude for Chrome

#299

Post by arthurcolle »

maximilianthe1 wrote: post #298
kccqzy wrote: post #284

Earlier quoted context omitted.

I think Simon has proposed breaking the lethal trifecta by having two LLMs, where the first has access to untrusted data but cannot do any actions, and the second LLM has privileges but only abstract variables from the first LLM not the content. See https://simonwillison.net/2023/Apr/25/dual-llm-pattern/ It is rather similar to your option (b).

Can't the attacker then jailbreak the first LLM to generate jailbreak with actions for the second one?

Yes they can

Re: Claude for Chrome

#300

Post by csomar »

afarviral wrote: post #281
dfabulich wrote: post #272

Claude for Chrome seems to be walking right into the "lethal trifecta." https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/ "The lethal trifecta of capabilities is:" • Access to your private data —one of the most common purposes of tools in the first place! • Exposure to untrusted content —any mechanism by which text (or images) controlled by a malicious attacker could become available to your LLM • The abilit…

How would you go about making it more secure but still getting to have your cake too? Off the top my head, could you: a) only ingest text that can be OCRd or somehow determine if it is human readable b) make it so text from the web session is isolated from the model with respect to triggering an action. Then it's simply a tradeoff at that point.

In the future, any action with consequence will require crypto-withdrawal levels of security. Maybe even a face scan before you can complete it.
Post reply on HN