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

171–180 of 200 posts

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

#171

Post by tehryanx »

miguelspizza wrote: post #166
tehryanx wrote: post #159

Earlier quoted context omitted.

I'm not following. Say I have your browser extension running, and it's interfacing with an MCP-B enabled banking application using my session to access my data in that app. I also have it connected to MCP-B enabled rogue web app that I mistakenly trust. My browser has an entire architecture built around preventing data from crossing between those two origins, but what's stopping a malicious instruction from the rogue…

Ah I see. Yes this is a concern, but this issue is actually not unique to MCP-B and is just a generally issue with agentic workflows that rely on a dynamic toolset from 3p vendors. (which any MCP server local or remote has the ability to be) > With MCP-B, isn't it just automatically provided with whatever credentials are already stored in cookies/etc for a given MCP-B enabled app? Not exactly, MCP-B just allows your…

I do think the threat model here is a bit unique though.

If I'm running two MCP servers on my machine, I'm the one that installed them, I'm the one that assigned what permissions they have in my environment, and I'm the one that explicitly decided what level of access to give them within whatever resource they're accessing. That gives me reasonably strong control over, or at least full knowledge of, what data can be shared between them.

With MCP, I can use oauth to make very deliberate decisions about the scope of access I want to give the agent.

With MCP-B, it's the web application owner that installed the interface and what access it has to my data, and the agent running in my client gets access to whatever that third party deemed appropriate.

With MCP-B the agent has the same access I do by default, with the only restrictions being up to the app owner rather than it being up to me.

MCP auth is not perfect by any stretch, but the key thing it gives the user is the capacity to restrict what the agent has access to with some granularity. That's super important because the agent can't be trusted when it's consuming inputs the user didn't explicitly define. MCP-B doesn't have this, if you have the agent in your browser it has access to whatever resources you have so long as they were exposed by a tool call, which isn't somethign the user has any say in.

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

#172

Post by JambalayaJimbo »

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.

AI is a very leaky abstraction. You will always be worried

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

#173

Post by tracerbulletx »

mupuff1234 wrote: post #75

I still don't understand MCP. If according to all the AI companies soon AI will replace devs than why bother with MCP?

It's pretty much standardizing on a couple endpoints for providing a list of resources/actions/prompt templates and calling to fetch those resources/actions/templates and feed them to the model context. It's really kind of trivial, but it's nice there's a standard I guess so you can write a service that anyone can use in their favorite client.

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

#174

Post by tehryanx »

owebmaster wrote: post #168
tehryanx wrote: post #145

Earlier quoted context omitted.

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.

a sandboxed user is not an untrusted user of the client but an unstrusted user of the host, that is why the client is sandboxed.

sandboxing is a general term for actor isolation, and its context agnostic.

For example, when you use the sandbox attribute on an iframe in a web application, it's not the user that's untrusted, it's some other user that's attempting to trigger actions in your client.

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

#175

Post by miguelspizza »

tehryanx wrote: post #171
miguelspizza wrote: post #166

Earlier quoted context omitted.

Ah I see. Yes this is a concern, but this issue is actually not unique to MCP-B and is just a generally issue with agentic workflows that rely on a dynamic toolset from 3p vendors. (which any MCP server local or remote has the ability to be) > With MCP-B, isn't it just automatically provided with whatever credentials are already stored in cookies/etc for a given MCP-B enabled app? Not exactly, MCP-B just allows your…

I do think the threat model here is a bit unique though. If I'm running two MCP servers on my machine, I'm the one that installed them, I'm the one that assigned what permissions they have in my environment, and I'm the one that explicitly decided what level of access to give them within whatever resource they're accessing. That gives me reasonably strong control over, or at least full knowledge of, what data can be…

I see your point. The MCP-B zero config nature from a user perspective is simultaneous it's biggest strength and weakness. You can think of it kind of like putting your Social Security number into a website. You are putting a bunch of trust that they are going to protect it properly.

With MCP-B you are putting trust in both the model and the website owner. It opens up the user to risk for sure, but it's up to them to determine if the upside is worth it.

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

#176

Post by Gracana »

latexr wrote: post #121
57473m3n7Fur7h3 wrote: post #117

Earlier quoted context omitted.

The built-in RSS reader in Firefox was removed. (But extensions exist to add RSS reader to Firefox.) Google killed Google Reader. (Other products exist you can use instead.) Facebook removed support for RSS feeds. (You can replace it with third party tools or API calls.) It’s not dead dead, but it did seem to lose some momentum and support over time on several fronts.

> It’s not dead dead It’s not dead, period. Not dead, dead dead, dead dead dead, or any other combination. Yes, some integrations were removed, but on the whole you have more apps and services for it than ever. The death of the behemoth that was Google Reader was a positive there. Maybe fewer people are using it, but the technology itself is fine and continues to be widely available and supported by most websites, wh…

I got the feeling that it was dead long ago. Sure there's plenty of readers and lots of sites "support" it, but what they tend to give you is a headline and article blurb feed with links to click through to see the ads. They don't want you consuming their articles through a reader. That's what makes it "dead" to me and a lot of others.

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

#177

Post by threetonesun »

Aurornis wrote: post #158
57473m3n7Fur7h3 wrote: post #117

Earlier quoted context omitted.

The built-in RSS reader in Firefox was removed. (But extensions exist to add RSS reader to Firefox.) Google killed Google Reader. (Other products exist you can use instead.) Facebook removed support for RSS feeds. (You can replace it with third party tools or API calls.) It’s not dead dead, but it did seem to lose some momentum and support over time on several fronts.

These products were phased out because most people weren't using them. RSS is and always was very niche. There are always claims that companies killed RSS for nefarious reasons, but I think the truth is much simpler: Companies stopped putting resources into RSS tools because very few people use them. The people who use RSS are very vocal about their support, but they're a small minority of internet users. Even I star…

Was RSS was not niche, and it's not niche today unless you consider podcasts niche. Also most new social media platforms have RSS built in.

It was nefariously killed by companies, especially news sites, who saw no good way to monetize RSS feeds, and would much rather you keep clicking bookmarks to be served new ads.

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

#178

Post by tehryanx »

miguelspizza wrote: post #175
tehryanx wrote: post #171

Earlier quoted context omitted.

I do think the threat model here is a bit unique though. If I'm running two MCP servers on my machine, I'm the one that installed them, I'm the one that assigned what permissions they have in my environment, and I'm the one that explicitly decided what level of access to give them within whatever resource they're accessing. That gives me reasonably strong control over, or at least full knowledge of, what data can be…

I see your point. The MCP-B zero config nature from a user perspective is simultaneous it's biggest strength and weakness. You can think of it kind of like putting your Social Security number into a website. You are putting a bunch of trust that they are going to protect it properly. With MCP-B you are putting trust in both the model and the website owner. It opens up the user to risk for sure, but it's up to them to…

I appreciate your responses here. The thing that still really stands out to me as a completely novel risk in this framework is that the extension is automatically seeking out and attaching to these servers as soon as a page gets loaded.

This seems really bad to me. There are so many ways for a website to end up in one of my browser tabs without me wanting it there, or even knowing it's there.

If that happens, and that tab just so happens to be a malicious MCP-B enabled page, it could steal all kinds of data from all kinds of different web apps I'm interacting with. I think it should be seen as the responsibility of the framework to enforce some level of data isolation, or at the least opt-in consent mechanisms.

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

#179

Post by miguelspizza »

tehryanx wrote: post #178
miguelspizza wrote: post #175

Earlier quoted context omitted.

I see your point. The MCP-B zero config nature from a user perspective is simultaneous it's biggest strength and weakness. You can think of it kind of like putting your Social Security number into a website. You are putting a bunch of trust that they are going to protect it properly. With MCP-B you are putting trust in both the model and the website owner. It opens up the user to risk for sure, but it's up to them to…

I appreciate your responses here. The thing that still really stands out to me as a completely novel risk in this framework is that the extension is automatically seeking out and attaching to these servers as soon as a page gets loaded. This seems really bad to me. There are so many ways for a website to end up in one of my browser tabs without me wanting it there, or even knowing it's there. If that happens, and tha…

Yea this is a really good idea, Maybe like a popup that say "hey x website has an MCP, do you trust it to connect?"

I guess there would also need to be a way to "audit" a websites full tool list at connection time and throw some sort of warning if tools show up that are not part of this list during use.

Interesting problems for sure. I really appreciate you taking to time to think them through. I'll call these out in the issues section of the repo

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

#180

Post by miguelspizza »

tehryanx wrote: post #178
miguelspizza wrote: post #175

Earlier quoted context omitted.

I see your point. The MCP-B zero config nature from a user perspective is simultaneous it's biggest strength and weakness. You can think of it kind of like putting your Social Security number into a website. You are putting a bunch of trust that they are going to protect it properly. With MCP-B you are putting trust in both the model and the website owner. It opens up the user to risk for sure, but it's up to them to…

I appreciate your responses here. The thing that still really stands out to me as a completely novel risk in this framework is that the extension is automatically seeking out and attaching to these servers as soon as a page gets loaded. This seems really bad to me. There are so many ways for a website to end up in one of my browser tabs without me wanting it there, or even knowing it's there. If that happens, and tha…

Added a summary of what has been brought up here to the repo wiki. Let me know if I missed anything

https://github.com/MiguelsPizza/WebMCP/wiki/Known-Security-I...

Post reply on HN