Live data from Hacker News

Claude for Chrome

anthropic.com

411–420 of 433 posts

Re: Claude for Chrome

#411

Earlier quoted context omitted.

> “it sounds very confident and looks correct, so this thing must be an all-knowing oracle”. I think the majority of the population will respond similarly, and the consequences will either force us to make the “note: this might be full of shit” disclaimer much larger, or maybe include warnings in the outputs. It’s not that people don’t have critical thinking skills— we’ve just sold these things as magic answer machin…

>It’s not that people don’t have critical thinking skills It isn't? I agree that it's a fallacy to put this down to "people are dumb", but I still don't get it. These AI chatbots are statistical text generators . They generate text based on probability. It remains absolutely beyond me why someone would assume the output of a text generator to be the truth.

Because across most topics, the "statistical text generator" is correct more often than any actual human being you know? And correct more often than random blogs you find?

I mean, people say things based on probability. The things they've come across, and the inferences they assume to be probable. And people get things wrong all the time. But the LLM's have read a whole lot more than you have, so when it comes to things you can learn from reading, their probabilities tend to be better across a wide range.

Re: Claude for Chrome

#412
Ironically, this sort of thing could have the side effect of turning web page usability issues into security issues. If your web page is a pain to use, then your users will rely on insecure automation to avoid dealing with it.

I'd like to think that this would apply pressure for making things more usable, but I don't think that's how this story goes.

Re: Claude for Chrome

#413

Earlier quoted context omitted.

It's insane how we're throwing out decades of security research because it's slightly annoying to have to write your own emails.

> it's slightly annoying to have to write your own emails. I find that to be a massive understatement. The amount of time, effort and emotional anguish that people expend on handling emails is astronomical. According to various estimates, email-handling takes somewhere around 25% of the work time of an average knowledge worker, going up to over 50% for some roles, and that most people check and reply to emails on eve…

Do you have any citations for various estimates? This is super interesting to me.

Re: Claude for Chrome

#414

Earlier quoted context omitted.

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

If you read the fine article, you'll see that the approach includes a non-LLM controller managing structured communication between the Privileged LLM (allowed to perform actions) and the Quarantined LLM (only allowed to produce structured data, which is assumed to be tainted). See also CaMeL https://simonwillison.net/2025/Apr/11/camel/ which incorporates a type system to track tainted data from the Quarantined LLM, e…

"Structured data" is kind of the wrong description for what Simon proposes. JSON is structured but can smuggle a string with the attack inside it. Simon's proposal is smarter than that.

Re: Claude for Chrome

#415
post #324

Earlier quoted context omitted.

Why do people keep going down this sophistry? Claude is a tool, a piece of technology that you use. Your parents are not. LLMs are not people.

If you think it's sophistry you're missing the point. Let's break it down: 1. Browsers are open ended tools 2. A knowledgeable user can accomplish all sorts of things with a browser 3. Most people can do very impactful things on browsers, like transferring money, buying expensive products, etc. 4. The problem of older people falling for scams and being tricked into taking self-harming actions in browsers is ancient;…

> If you think it's sophistry you're missing the point. Let's break it down:

I'd be happy to respond to something that isn't ChatGPT, thanks.

Re: Claude for Chrome

#416
Did a quick try out video of the Research Preview Extension in this post: https://news.ycombinator.com/item?id=45046120

TLDR:

- Using VERY HIGH RISK Debugger Permission that malicious websites can exploit to get device access. Very surprising a major tech company shipping product with such risky permissions to consumers. More info on debugger risks: https://dspace.networks.imdea.org/bitstream/handle/20.500.12..., https://issues.chromium.org/issues/40091993.

- Prompt injection risks combined with Debugger permission on user device is asking for trouble.

- Will trigger captchas/bot detection even on your normal browsing due to this permission.

- Kind of slow. Limited to current open tab as opposed to capability of multi tab action because only current active tab get rendered. For example rtrvr.ai can open a batch of tabs and take actions on background tabs.

- For some websites like Bloomberg asking to go to claude.com

Re: Claude for Chrome

#417
post #204

Earlier quoted context omitted.

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…

This is definitely true but there are more reasons that explain why so many teams choose the seemingly irrational path. First, so many APIs are designed differently, so even if you decide the business negotiation is worth it you have development work ahead. Second, tons of vendors don’t even have an API. So the thought of building a tool once is appealing

Re: Claude for Chrome

#418
post #345
post #267

Earlier quoted context omitted.

This is a massive problem in healthcare, at least here in Canada. Most of the common EMRs doctors and other practitioners use either don’t have APIs, or if APIs exist they are closely guarded by the EMR vendors. And EMRs are just one of the many software tools clinics have to juggle. I’d argue that lack of interoperability is one of the biggest problems in the healthcare system here, and getting access to data throug…

I’m not sure how unique or a new problem this is first individually to me and then generally. Automation technologies to handle things like UI automation have existed long before LLMs and work quite fine. Having an intentionally imprecise and non deterministic software try to behave in a deterministic manner like all software we’re used to is something else.

The cost to develop and maintain UI automation is prohibitive for most companies

Re: Claude for Chrome

#419
post #267
post #204

Earlier quoted context omitted.

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 is a massive problem in healthcare, at least here in Canada. Most of the common EMRs doctors and other practitioners use either don’t have APIs, or if APIs exist they are closely guarded by the EMR vendors. And EMRs are just one of the many software tools clinics have to juggle. I’d argue that lack of interoperability is one of the biggest problems in the healthcare system here, and getting access to data throug…

It begs the question though. If these vendors are so closely guarded of their API to try and shake down people for an enterprise license, why would they suddenly be permissive towards the LLM subverting that payment flow? Chances are the fact the LLM can interact with these systems is a blip: once they do see appreciable adoption the systems will be locked down to prevent the LLM from essentially pirating your service for you.

Re: Claude for Chrome

#420
post #204

Earlier quoted context omitted.

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…

Dude you do not understand how bad those "APIs" are for booking flights. Customers of Travelport often have screen reading software that reads/writes to a green screen. There's also tele-type, but like most of the GDS providers use old IBM TPF mainframes. I spent the first two years of my career in the space, we joked anything invented post Michael Jackson's song Thriller wasn't present.

And yet, they exist, and software has been built on top of them already.
Post reply on HN