71–80 of 107 posts
This looks very useful for web apps. We have a use case for legacy Windows apps. How feasible is this kind of technology for performing agentic workflows in legacy native apps?
What about OmniParser ? https://www.microsoft.com/en-us/research/articles/omniparser...
Earlier quoted context omitted.
Yes, I was able to figure out a secure way to control the browser with AI Agents at rtrvr.ai without using debugger permissions/tools so it is most definitely possible. I meant by in production in the sense how you are advising your users to setup the local installation. Even if you launch browser use locally within a container but your restarting the user's Chrome in debug mode and controlling it with CDP from withi…
Injecting JS into the page or controlling it using extension APIs is not a secure way to control the browser.
Your claim is analogous to saying that Apple's app store is not secure. We had to go through stringent vetting and testing by Google to list in the Chrome Store. Any basis or reasoning you can provide for your claim?
Regardless, its a wild leap to claim a Chrome Store Chrome Extension is more insecure than this arbitrary binary?
This looks very promising. Thank you for making it open source! At first glance, I couldn't find if you can run it using local models (ollama?). Is that at all possible? Edit: for anyone else looking for this, it seems that you can: https://github.com/browser-use/browser-use/blob/70ae758a3bfa...
this is the best thing to ever happen to the RPA world
The cool thing is that we can extract xPaths from the agent runs and re-run these scripts deterministically. I think that's a big advantage over pure vision-based systems like Operator.
The title says make your website more accessible for agents... But then the quick start seemingly just acts from the agentic side to find a post on Reddit. So I didn't fully grok what this is about. My initial guess is you use agents on a website, allow them to think long, then come up with some selectors to speed up subsequent tries. But it's really not clear to me
Then we present this list to the LLM with the task and the LLM outputs input_text(id 3, Hello World).
Finally, we execute the Playwright code to perform the actual action of inputting text into this element.
Earlier quoted context omitted.
Injecting JS into the page or controlling it using extension APIs is not a secure way to control the browser.
Yeah, sorta feels like docker on a new instance is safer than connecting to actual browsers and injecting js code there… would love to skip cdp protocol though, it’s quite restrictive
Perhaps we are talking past each other, your literally giving instructions to your users to connect to their actual browsers: https://docs.browser-use.com/customize/real-browser Where under the hood your launching Chrome with debugging mode but with the user's credentials and passwords. This browser is then controlled via CDP by a highly insecure browser-use binary running in a container. Your users are bound to get pwned with this setup! https://github.com/browser-use/browser-use/blob/70ae758a3bfa...
This looks very useful for web apps. We have a use case for legacy Windows apps. How feasible is this kind of technology for performing agentic workflows in legacy native apps?
> On the open-source side, browser use remains free. You can use any LLM, from Gemini to Sonnet, Qwen, or even DeepSeek-R1. It’s licensed under MIT, giving you full freedom to customize it. As this project is MIT, that means companies like Amazon can deploy a managed version and can compete against you with prices going close to zero in their free-tier and with a higher quotas than what you are offering. I predict th…
Earlier quoted context omitted.
I believe MCP helps here because it standardizes integrations, enhances user control via opt-in plugins, and improves security by avoiding direct endpoint calls. @gregpr07 wouldn't adoption of MCP open up Browser-use to more use cases?
It probably would yeah. I was very against it but this HN post sorta points me to “people want mcp”
Have you inspected or thought through the security of your open source library? You are using debugger tools such as CDP, launching playwright without a sandbox, and guiding users to launch Chrome in debugger mode to connect to browser-use on their main browser. The debugging tools you use have active exploits that Google doesn't fix because they are supposed to be for debugging and not for production/general use. Th…