What’s under the hood.

Why a thin shell, not a bundled engine

Most desktop apps that look like they have a browser inside them — Slack, Discord, VS Code, the new Outlook, Teams — are Electron apps. Electron bundles its own copy of Chromium and Node, which means every Electron app you install ships ~150 MB of browser engine that nobody but that app uses. They duplicate. They get out of date independently. They each have to be patched separately when a vulnerability lands.

Egg is a Tauri app. Tauri does not bundle a browser engine. The Egg shell is roughly 5–10 MB of Rust and frontend assets. When it needs to render a page, it calls into the webview the OS already provides — WebView2 on Windows, WKWebView on macOS. The engine is maintained by the OS vendor, updated by the OS vendor, and shared by every other small app on your machine that does the same thing.

The cost of this approach is that we run on two engines instead of one. The benefit is everything else.

Windows: the Microsoft path, not the Google path

On Windows, Egg renders through WebView2, which loads the Edge Runtime, which is built on the open-source Chromium engine. That last sentence is the important one, because it sounds like “Egg uses Chrome” — and it doesn’t.

Chromium is the open-source project. Chrome is what Google ships when it takes Chromium and adds its own service layer on top: Safe Browsing reports to Google, search suggestions go to Google, the Omaha updater talks to Google, sync goes through your Google account, crash reports land in Google’s pipeline, the Finch experiment service decides what to enable for you. None of that is in Chromium itself. All of that is what Microsoft removes when it forks Chromium to build the Edge Runtime — and replaces with its own equivalents pointing at Microsoft.

So when Egg calls WebView2 to render a page, the engine doing the rendering is Chromium, but the service layer talking to a remote server is Microsoft’s, not Google’s. No Safe Browsing checks to Google. No Google account integration. No Google Suggest as you type. No Omaha.

Microsoft’s service layer has its own pieces — SmartScreen for URL reputation, optional telemetry, crash reporting — and several of them are configurable per-host-app through the WebView2 API. Egg disables them: SmartScreen reputation checking off, crash reporting to Microsoft off, optional diagnostic data off. What remains are the parts the runtime requires to function: the runtime updater itself, required diagnostic data, and Microsoft’s patched network stack. We can’t turn those off — they’re part of how the runtime stays current and secure — but they go to Microsoft, not to us, and not to Google.

macOS: the Apple path, no third party

On macOS, there is no Chromium-derived runtime in the picture at all. Egg renders through WKWebView, which is the embeddable form of WebKit — the same engine that powers Safari. WebKit ships with macOS itself. There’s no separate runtime to download, no separate updater, no third-party service layer.

This means the engine on Apple platforms is controlled by Apple, which is the same trust posture you already have with the rest of your operating system. There is no Microsoft involvement on macOS. There is no Google involvement on macOS. The engine updates when macOS updates. Egg gets whatever WebKit version is on the user’s machine.

The tradeoff is compatibility. Sites tested against Chrome occasionally behave differently in Safari, and Egg on macOS will exhibit those same differences. Chrome extensions don’t run on macOS yet for the same reason — the engine isn’t Chromium. We think that’s a fair price for an engine that ships with the OS, gets security updates as part of the OS, and doesn’t add a vendor relationship to your stack.

What this gets you in practice

A small download. The Egg installer is on the order of a Tauri shell, not an Electron-class bundle. The bulk of what makes web pages render is already on your machine.

Security updates that travel with your OS. When Microsoft patches the Edge Runtime, every Tauri-on-Windows app on your machine gets the patch — including Egg — without any of those apps shipping an update. When Apple patches WebKit through a macOS update, the same is true on Mac. The engine isn’t something we have to chase.

No Google data layer on either platform. Egg never goes through Chrome. The Windows path goes through Microsoft. The macOS path goes through Apple. If you don’t want your browser’s service layer talking to Google, this matters. If you do want a Google-backed browser, Egg isn’t one — that’s the whole point.

A real browser, not a webview pretending to be one. WebView2 is the Edge Runtime — the same engine that ships in Edge Browser, just without the address bar and tabs UI. WKWebView is the WebKit that ships in Safari. The rendering, the JavaScript engine, the network stack, the standards support — identical to the consumer browser on each platform. Egg adds the browser shell on top: tabs, URL bar, profiles, bookmarks, history, the agent.

What this doesn’t mean

It doesn’t mean Egg is sandboxed away from the OS — the agent has access to the page, your filesystem (where you grant it), and any tools you give it. The engine choice is about how pages are rendered and which vendor sees the request. Everything Egg builds on top — vertical tabs, profiles, the encrypted vault, sync, the agent — is ours, runs in Rust, and is independent of the engine.

It also doesn’t mean you have to trust us blindly about “no Google.” The engine relationships are visible at the OS level. On Windows you can see the Edge WebView2 process; on Mac you can see com.apple.WebKit processes. They are what we say they are.