←back to thread

281 points felarof | 8 comments | | HN request time: 1.219s | source | bottom

Hey HN, we're a YC startup building an open-source, privacy-first alternative to Perplexity Comet.

No invite system unlike bunch of others – you can download it today from our website or GitHub: https://github.com/browseros-ai/BrowserOS

--- Why bother building an alternative? We believe browsers will become the new operating systems, where we offload much bunch of our work to AI agents. But these agents will have access to all your sensitive data – emails, docs, on top of your browser history. Open-source, privacy-first alternatives need to exist.

We're not a search or ad company, so no weird incentives. Your data stays on your machine. You can use local LLMs with Ollama. We also support BYOK (bring your own keys), so no $200/month plans.

Another big difference vs Perplexity Comet: our agent runs locally in your browser (not on their server). You can actually watch it click around and do stuff, which is pretty cool! Short demo here: https://bit.ly/browserOS-demo

--- How we built? We patch Chromium's C++ source code with our changes, so we have the same security as Google Chrome. We also have an auto-updater for security patches and regular updates.

Working with Chromium's 15M lines of C++ has been another fun adventure that I'm writing a blog post on. Cursor/VSCode breaks at this scale, so we're back to using grep to find stuff and make changes. Claude code works surprisingly well too.

Building the binary takes ~3 hours on our M4 Max MacBook.

--- Next? We're just 2 people with a lot of work ahead (Firefox started with 3 hackers, history rhymes!). But we strongly believe that a privacy-first browser with local LLM support is more important than ever – since agents will have access to so much sensitive data.

Looking forward to any and all comments!

Show context
layer8 ◴[] No.44524345[source]
I would prefer this as a browser extension, not as its own browser application.
replies(4): >>44524916 #>>44527052 #>>44529634 #>>44530097 #
felarof ◴[] No.44524916[source]
We would've preferred to build this as browser extension too.

But we strongly believe that for building a good agent co-pilot we need bunch of changes at Chromium C++ code level. For example, chromium has a accessibility tree for every website, but doesn't expose it as an API to chrome extension. Having access to accessibility tree would greatly improve agent execution.

We are also building bunch of changes in C++ for agents to interact with websites -- functions like click, elements with indexes. You can inject JS for doing this but it is 20-40X slower.

replies(4): >>44525458 #>>44526251 #>>44527064 #>>44530334 #
1. esafak ◴[] No.44525458[source]
Could you upstream that change in order to make it an extension in the future? I think people would not value it any less.
replies(1): >>44525486 #
2. felarof ◴[] No.44525486[source]
We don't mind upstreaming. But I don't think Google Chrome/Chromium wants to expose it as an API chrome extensions, if not they would've done this long time ago.

From Google's perspective, extension are meant to be lightweight applications, with restricted access.

replies(1): >>44526840 #
3. jazzyjackson ◴[] No.44526840[source]
I'm not really interested in AI agents for my webbrowser, but it would be pretty cool to see a fork of chromium available that, aside from being de-googled, relaxes all the "restricted access" to make it more fun to modify and customize the way you guys are. Just a thought, may be more of a market for the framework more than the product :)

See Sciter. A very cool, super lightweight alternative to Electron, but unfortunately it seems like a single developer project and I could never get any of the examples to run.

https://sciter.com/

replies(3): >>44526902 #>>44530171 #>>44530495 #
4. felarof ◴[] No.44526902{3}[source]
Yes, we want to do this too! We'll expose much more richer APIs.

What use-cases do you have in mind? like scraping?

5. Imustaskforhelp ◴[] No.44530171{3}[source]
I always wonder about what sort of js engine such projects use since at the end of the day imo, it is all just a dance b/w js engine, html and css. Html & Css feels a little solved problem but the problem is of the js engine.

Sciter uses quickjs and I just checked and its like 35-36x times slower than V8 JIT

Also another interesting rabbit hole is that I found Duktape in the quickjs benchmarks and I saw https://blogcpp.org/ as one of the projects within Duktape but I can't even see the project on github. We really need some better way of preserving open source stuff I guess

replies(2): >>44538439 #>>44538945 #
6. nicoburns ◴[] No.44530495{3}[source]
I'm making a new sciter-style webview https://github.com/DioxusLabs/blitz
7. mdaniel ◴[] No.44538439{4}[source]
> We really need some better way of preserving open source stuff I guess

Not some rando's blog engine in C++, or other kinds of stupid throw-away code

Anyway <https://web.archive.org/web/20241122030659/https://github.co...> -> $(fossil clone https://code.rosaelefanten.org/blogcpp) which takes a stunning amount of time but then reports

    Round-trips: 15   Artifacts sent: 0  received: 2751
    Clone done, wire bytes sent: 4127  received: 124543126  remote: 2a03:4000:34:5e::1
    Rebuilding repository meta-data...
      100.0% complete...
    Extra delta compression... none found
    Vacuuming the database...
    project-id: 40a055cb170ae83c46b4ed9bf3b6a60e6e541aa0
    server-id:  cee9059305219c887fd29c677cbafb372252518a
    admin-user: mdaniel (password is "x2hEAaXUDj")
    opening the new ./blogcpp.fossil repository in directory ./blogcpp...
    3rdparty/ConfigParser/ConfigParser.cpp
    ...
    project-name: BlogC++
    repository:   /home/runner/blogcpp.fossil
    project-code: 40a055cb170ae83c46b4ed9bf3b6a60e6e541aa0
    checkout:     fbea390316bc3aace7de0a9ccdba90ecc1949a10 2024-12-17 22:03:16 UTC
    parent:       9e604d205e7922ef1af87952fe1bebef0cbac336 2022-01-15 02:22:33 UTC
    tags:         trunk
    comment:      fuck you github (user: Cthulhux)
    check-ins:    20
8. jazzyjackson ◴[] No.44538945{4}[source]
good callout wrt being slower than JIT. ofc for certain applications it's not a showstopper, ie, if you're not using javascript for your MVC but doing more of a progressive enhancement thing.

CSS2 is closer to trivial, but CSS3 is practically a 3D game engine with all of its matrix transforms, transitions, animations, variables - not to mention all the different layout schemes (Sciter blogged about introducing display:flex and display:grid two months ago)

The most interesting part of Sciter to me is that data persistence goes way beyond localStorage (string key: string value) or filesystem API, instead it's DyBase [0][1] behind the scenes, which looks to be a very intriguing style of storing trees of data in the host language's datatype (including whatever classes you define) without mucking about with the leaky abstractions of an ORM.

[0] https://github.com/c-smile/sciter-js-sdk/blob/main/docs/md/s...

[1] http://www.garret.ru/dybase.html