I have searched the existing issues and discussions.
Problem Description
Description:
Currently, the browse_url feature in Open WebUI is implemented server-side, which poses several challenges:
Server-side internet access is restricted via whitelisting, limiting its usability.
Users lack control over the exact queries sent by the LLM, which can lead to unintended data exposure.
Proposed Solution:
Implement a client-side browsing approach, allowing the user's local machine to handle web requests instead of the server.
Desired Solution you'd like
Key Features:
Client-Side Execution
Offload web search and browsing tasks to the user's machine.
Use browser APIs (e.g., fetch, WebView, or an extension) to perform searches directly.
User-Controlled Query Validation
Provide an interactive mode where users can review and approve search queries before they are executed.
Display the exact request generated by the LLM, giving full transparency.
Security & Privacy Enhancements
Ensure that sensitive data is not accidentally sent to external services.
Allow users to define custom filtering rules or manually edit queries before execution.
Alternatives Considered
No response
Additional Context
Expected Benefits:
✅ Bypasses server-side internet restrictions (whitelist issues). ✅ Improves user control and transparency over web queries. ✅ Reduces risks of unintended data exposure by enforcing query validation.
Would love to hear thoughts from the maintainers on feasibility and best practices for implementation!
François
Originally created by @flefevre on GitHub (Mar 25, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/12026
### Check Existing Issues
- [x] I have searched the existing issues and discussions.
### Problem Description
**Description**:
Currently, the browse_url feature in Open WebUI is implemented server-side, which poses several challenges:
Server-side internet access is restricted via whitelisting, limiting its usability.
Users lack control over the exact queries sent by the LLM, which can lead to unintended data exposure.
**Proposed Solution:**
Implement a client-side browsing approach, allowing the user's local machine to handle web requests instead of the server.
### Desired Solution you'd like
**Key Features:**
1. Client-Side Execution
Offload web search and browsing tasks to the user's machine.
Use browser APIs (e.g., fetch, WebView, or an extension) to perform searches directly.
2. User-Controlled Query Validation
Provide an interactive mode where users can review and approve search queries before they are executed.
Display the exact request generated by the LLM, giving full transparency.
3. Security & Privacy Enhancements
Ensure that sensitive data is not accidentally sent to external services.
Allow users to define custom filtering rules or manually edit queries before execution.
### Alternatives Considered
_No response_
### Additional Context
**Expected Benefits:**
✅ Bypasses server-side internet restrictions (whitelist issues).
✅ Improves user control and transparency over web queries.
✅ Reduces risks of unintended data exposure by enforcing query validation.
Would love to hear thoughts from the maintainers on feasibility and best practices for implementation!
François
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @flefevre on GitHub (Mar 25, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/12026
Check Existing Issues
Problem Description
Description:
Currently, the browse_url feature in Open WebUI is implemented server-side, which poses several challenges:
Server-side internet access is restricted via whitelisting, limiting its usability.
Users lack control over the exact queries sent by the LLM, which can lead to unintended data exposure.
Proposed Solution:
Implement a client-side browsing approach, allowing the user's local machine to handle web requests instead of the server.
Desired Solution you'd like
Key Features:
Offload web search and browsing tasks to the user's machine.
Use browser APIs (e.g., fetch, WebView, or an extension) to perform searches directly.
Provide an interactive mode where users can review and approve search queries before they are executed.
Display the exact request generated by the LLM, giving full transparency.
Ensure that sensitive data is not accidentally sent to external services.
Allow users to define custom filtering rules or manually edit queries before execution.
Alternatives Considered
No response
Additional Context
Expected Benefits:
✅ Bypasses server-side internet restrictions (whitelist issues).
✅ Improves user control and transparency over web queries.
✅ Reduces risks of unintended data exposure by enforcing query validation.
Would love to hear thoughts from the maintainers on feasibility and best practices for implementation!
François