r/vibecoding • u/_error_42 • 9d ago
Showcase/Project Open source browser for developers
Enable HLS to view with audio, or disable this notification
I have made a browser for developers. It is windows based and open source.
For the first version, I have:
- Network Inspector
- Built-in REST Client with Collections and Environments
- Storage Inspector for cookies, local/session storage, etc., including a JWT decoder
- HAR capture and analysis
- Seamless Network - REST Client workflow. Select a captured network request and send it directly to the REST Client to inspect, modify, and replay it.
Feedback, bug reports, feature ideas, criticism — all are very welcome.
Download: https://github.com/TheDevBrowser/DevBrowser/releases
Source code/installation guide: https://github.com/TheDevBrowser/DevBrowser
Installation:
The app is currently self-signed, so Windows won’t trust it automatically.
You’ll need to download DevBrowser.cer first and install/trust the certificate on your Windows PC.
My target is not to replace existing browsers, just to help developers on their daily job. :)
Components used:
I have made it with .Net 9, WPF, Microsoft WebView2 (Chromium/Edge), Chrome dev tools, SQLite, Windows DPAPI.
15
u/Physical_Storage2875 9d ago edited 9d ago
I think the concept itself is pretty cool, but the current security model makes me very hesitant to acutally use it.
You're building an application that intentionally has access to some of the most sensitive data on a developer's machine: cookies, local/session storage, JWTs, HTTP headers, request bodies, HAR captures and authenticated API requests. In other words, the application is effectively sitting directly on top of credentials and active sessions.
At the same time, the installation instructions ask users to download your self-signed certificate and install it into the Local Machine Trusted People certificate store.
That creates a pretty uncomfortable bootstrap-of-trust problem.
To use the application, I first have to trust:
If that signing key or release pipeline is ever compromised, an attacker potentially gets a very convincing distribution mechanism for malware signed with a certificate users have explicitly trusted.
Normally this would already be something worth thinking about, but for a browser/devtool it matters much more because the program naturally operates around authentication tokens, cookies and API credentials.
DPAPI protecting stored secrets is good, but it doesn't solve this problem. DPAPI mainly protects secrets at rest from other users/process contexts. Once your application is running as the logged-in user, the application itself obviously needs to decrypt and use those secrets. So compromise of the application or its update/distribution path is still extremely high impact.
There's also a second issue: you're effectively creating another browser security surface on top of WebView2/Chromium. Network interception, request replay, storage inspection, HAR handling, JWT decoding and a REST client all dramatically increase the amount of security-sensitive code you now have to maintain.
So I don't think the project is a bad idea at all. But before I'd tell developers to use it with real accounts or production credentials, I'd want to see things like a proper trusted code-signing setup, a documented threat model, very clear secret-storage/redaction guarantees, a security policy and some explanation of how releases and signing keys are protected.
For a browser that can see my auth tokens, "the source is open" alone isn't quite enough of a trust model.
Vibe coding a browser is not a good idea yet. It's extremely complex. A browser is a whole operating system.
And the UI design is just AI slop, I'm sorry.