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

MCP-B: A Protocol for AI Browser Automation

mcp-b.ai

Post reply on HN
Print view View original

141–150 of 200 posts

Re: MCP-B: A Protocol for AI Browser Automation

#141

Post by johschmitz »

ActorNightly wrote: post #89
teruakohatu wrote: post #55

Earlier quoted context omitted.

I had that opinion too. You can ask an agent to browse a web page and click a button etc. They will work out how to use a browser automation library. But it’s not worth the cost, time spent waiting or the inconsistency between implementations. MCP just offloads that overload, much like how they can use bash tools when they are quite capable of writing an implementation of grep etc.

The whole point is that you shouldn't have to worry about implementation. AI should do it for you.

At the end of the day you often need to consider the energy efficiency of a system which is also reflected in the cost of operating it. For use cases where this is relevant the suggested MCP approach potentially offers large benefits compared to what's probably meant here by "AI". However, the disadvantages of public access discussed in other threads need to be considered as well, therefore, I expected this only to be used for certain niche use cases. Testing and retro fitting non-public websites come to mind.

Re: MCP-B: A Protocol for AI Browser Automation

#142

Post by owebmaster »

tehryanx wrote: post #140
miguelspizza wrote: post #99

Earlier quoted context omitted.

Not sure I understand. The model has no more access than the user does. proper security implementation still lies with the website owner

I think the point is that you shouldn't be giving the agent the same privileges as the user. This is one of the biggest issues with how people are using agents rn imo. The agent should be treated as an untrusted user in your client, given restricted privileges scoped to only the exact access they need to perform a given task.

> The agent should be treated as an untrusted user in your client,

An untrusted user in a client is a hacker/invasor, not an agent.

Re: MCP-B: A Protocol for AI Browser Automation

#144

Post by throwawaymaths »

TeMPOraL wrote: post #120
jacquesm wrote: post #113

Prediction: this will go the same way as RSS. Companies don't like you to be in control of how you use their data.

Indeed. Though I guess a better example would be: it'll go the same way as REST APIs (which happen to be fundamentally the same thing as MCP anyway). Remember the time when REST was the new hot thing, everyone started doing API-first design, and people thought it'll empower people by letting programs navigate services for them programmatically? Remember when "mashups" were the future? It all died before it could come…

REST did not die. it mostly became a mechanism for business managers to separate concerns between frontend and backend.

i wonder if mcp will become, "let the project people talk to the backend team and the frontend team separately and the AI will figure out the middle"

Re: MCP-B: A Protocol for AI Browser Automation

#145

Post by tehryanx »

owebmaster wrote: post #142
tehryanx wrote: post #140

Earlier quoted context omitted.

I think the point is that you shouldn't be giving the agent the same privileges as the user. This is one of the biggest issues with how people are using agents rn imo. The agent should be treated as an untrusted user in your client, given restricted privileges scoped to only the exact access they need to perform a given task.

> The agent should be treated as an untrusted user in your client, An untrusted user in a client is a hacker/invasor, not an agent.

an untrusted, but permitted, user is why sandboxes exist. There are plenty of times you want to allow an untrusted user to have capabilities in a system, that's why you restrict those capabilities.

Re: MCP-B: A Protocol for AI Browser Automation

#146

Post by lcnPylGDnU4H9OF »

owebmaster wrote: post #142
tehryanx wrote: post #140

Earlier quoted context omitted.

I think the point is that you shouldn't be giving the agent the same privileges as the user. This is one of the biggest issues with how people are using agents rn imo. The agent should be treated as an untrusted user in your client, given restricted privileges scoped to only the exact access they need to perform a given task.

> The agent should be treated as an untrusted user in your client, An untrusted user in a client is a hacker/invasor, not an agent.

That’s not really a reason not to treat the agent like it’s “rogue”. The point is, if it accepts any untrusted inputs then, from a security perspective, it is possible for any given (untrusted) input to contain a prompt injection payload that jailbreaks the model and tells it to do things it shouldn’t do.

As such, it can be told to do bad stuff in a way that can’t be prevented and therefore should not be given read access to anything you don’t want others to know about, nor write access to any data of which you care about the integrity.

Re: MCP-B: A Protocol for AI Browser Automation

#147

Post by ep103 »

throwawaymaths wrote: post #144
TeMPOraL wrote: post #120

Earlier quoted context omitted.

Indeed. Though I guess a better example would be: it'll go the same way as REST APIs (which happen to be fundamentally the same thing as MCP anyway). Remember the time when REST was the new hot thing, everyone started doing API-first design, and people thought it'll empower people by letting programs navigate services for them programmatically? Remember when "mashups" were the future? It all died before it could come…

REST did not die. it mostly became a mechanism for business managers to separate concerns between frontend and backend. i wonder if mcp will become, "let the project people talk to the backend team and the frontend team separately and the AI will figure out the middle"

This is already the way my company wants to go.

Put MCP in front of every GET API, and let teams explore on their own

Re: MCP-B: A Protocol for AI Browser Automation

#148

Post by miguelspizza »

tehryanx wrote: post #140
miguelspizza wrote: post #99

Earlier quoted context omitted.

Not sure I understand. The model has no more access than the user does. proper security implementation still lies with the website owner

I think the point is that you shouldn't be giving the agent the same privileges as the user. This is one of the biggest issues with how people are using agents rn imo. The agent should be treated as an untrusted user in your client, given restricted privileges scoped to only the exact access they need to perform a given task.

Again, that's up to the website owner. They can give the model anywhere from no access to full access to the client side api.

> The agent should be treated as an untrusted user in your client, given restricted privileges scoped to only the exact access they need to perform a given task

I agree, this is exactly what MCP-B does

Re: MCP-B: A Protocol for AI Browser Automation

#149

Post by miguelspizza »

csomar wrote: post #74
rapind wrote: post #29

Earlier quoted context omitted.

I was checking that out too. Looks like claude was co-author on the initial commit, which is like 90%. https://github.com/MiguelsPizza/WebMCP/commit/26ec4a75354b1c...

The main author doesn't have a GitHub account or un-linked his account (on purpose or by accident).

Looks like Claude put me down as a co-author with my real name (Alex Nahas) instead of my GitHub handle (MiguelsPizza)

Re: MCP-B: A Protocol for AI Browser Automation

#150

Post by ImPostingOnHN »

miguelspizza wrote: post #99
mehdibl wrote: post #61

From the blog post: "The Auth problem At this point, the auth issues with MCP are well known. OAuth2.1 is great, but we are basically trying to re-invent auth for agents that act on behalf of the user. This is a good long term goal, but we are quickly realizing that LLM sessions with no distinguishable credentials of their own are difficult to authorize and will require a complete re-imagining of our authorization sy…

Not sure I understand. The model has no more access than the user does. proper security implementation still lies with the website owner

When you say "the user", do you mean that if Alice set up the MCP, and Bob, Charlie, and Dave all access it, the MCP will only execute commands as Bob, or Charlie, or Dave, depending on who is accessing it?
Post reply on HN