The Bench Marker
A password manager on this machine occupies 553 megabytes. Its own program code, the part that actually knows about passwords, is one megabyte. The remaining 552 are a web browser it brought with it.
That is not an accusation, it is a measurement, and the rest of this piece is about what the number means. The claim under examination is the one every engineering team makes when it picks this route, usually in a single line of a decision document: bundling a browser engine costs nothing worth arguing about.
How This Was Measured
Every application in /Applications on one Mac running
macOS 26.5.2, sized with the Unix tool du -sm. For each
one, the bundled runtime under Contents/Frameworks was
measured separately from the application's own code in
app.asar. Engine linkage was read with
otool -L against the main binary, which shows whether
an application draws on the system's WebKit or ships an engine of
its own. Bundled Chromium versions were read out of the framework
binary with strings.
No timings, no memory figures, nothing that depends on what else the machine was doing. These are numbers on disk, and anyone with a Mac can reproduce every one of them in about two minutes. That matters here more than sophistication: a measurement you cannot repeat is an anecdote with decimal places.
du -sm /Applications/*.app
du -sm "<App>.app/Contents/Frameworks"
du -sm "$(find "<App>.app" -name app.asar | head -1)"
otool -L "<App>.app/Contents/MacOS/<binary>" | grep WebKit
strings "<App>.app/Contents/Frameworks/Electron Framework.framework/Electron Framework" \
| grep -oE "Chrome/[0-9.]+"The Numbers
Two applications ship their own engine. Proton Pass comes to 553 MB, of which 457 MB is the Electron framework and 1 MB is the application itself, so ninety-nine per cent of what was downloaded is scaffolding. Slack comes to 310 MB, of which 274 MB is framework and 10 MB is Slack.
Against that, applications drawing on the system's own engine: Strongbox, which does the same job as Proton Pass, is 62 MB. Typora, which renders its entire interface as a web view, is 44 MB. A Safari extension in the same category is 7 MB.
So a password manager that ships its own browser is roughly nine times the size of a password manager that does not, and the browser it brought along is on its own seven times the size of the entire native competitor.
One more figure, and it is the one that matters. The Chromium inside Slack reports version 148. The Chromium inside Proton Pass reports 142. Two applications, one machine, six major versions apart. Chromium ships a major version roughly every four weeks.
The Obvious Explanation, Which No Longer Holds
The standard defence is that bundling guarantees identical rendering everywhere, and that the alternative means fighting three different engines. It is worth taking that seriously for a moment, because it used to be true and is now mostly not.
The three system web views are not three unrelated engines. WKWebView on macOS is WebKit. WebKitGTK on Linux is WebKit. WebView2 on Windows is Blink, which is a fork of WebKit taken in 2013, which was itself a fork of KDE's KHTML from 2001. They are cousins, not strangers, and Gecko does not appear in this picture at all. On top of that, the browser vendors have spent the last several years deliberately closing the remaining gaps through the Interop programme, which exists precisely so that ordinary HTML and CSS behave the same across implementations.
For an interface built from standard markup, layout and styling, "it will look different on the other engine" is a much weaker argument in 2026 than the folklore suggests. Anyone who has shipped a form, a list and a settings pane knows how far you get on plain CSS these days without touching a vendor prefix.
The Real Reason, Documented by the Alternative Itself
The honest reason to bundle is not rendering. It is versions, and specifically Linux.
Tauri, the framework that exists to use the system web view instead of bundling one, says so in its own documentation. Its guidance is to build against the oldest base system you intend to support, because the WebKitGTK version is whatever the distribution shipped and not what you would choose. Ubuntu 22.04 sat on WebKit2GTK 2.34 for its whole supported life. Distributions could not force migrations onto systems with years of support left, so applications adapt downwards. The project's own AppImage packaging embeds a WebKitGTK runtime for exactly this reason, which is to say the escape from bundling ends in bundling again on the platform that made bundling necessary.
That is a real problem and a fair defence. It is also a Linux problem, and it is paid for on every platform. WKWebView arrives with macOS and is updated with it. WebView2 is maintained by Microsoft on an evergreen channel. On two of the three targets, the argument for carrying your own engine mostly evaporates, and the engine is carried anyway because the build is one build.
Who Patches V8
Which brings us to the part that is not about disk space at all.
A bundled engine is not a frozen library. A frozen library renders the data your application hands it. A frozen browser engine renders whatever arrives: link previews, embedded content, files somebody shared with you. That is a different category of component, and its vulnerability record reflects it. By June of this year Google had shipped fixes for the fifth actively exploited Chrome zero-day of 2026; CVE-2026-11645, an out-of-bounds access in V8, went into the CISA catalogue of known exploited vulnerabilities on 9 June.
When that engine belongs to the operating system, the fix arrives from the operating system, once, for everything that uses it. When each application carries its own, the fix arrives once per application, from the vendor of that application, on that vendor's release schedule. The measurement above is what that looks like in practice: 148 in one application, 142 in another, on the same laptop, on the same afternoon.
It also makes a distinction the industry rarely draws. Slack renders content that other people sent, and Slack is current. A password manager mostly renders its own interface, and can afford to be less current, which raises the more awkward question: if the interface is one megabyte of its own code, what is the browser doing there at all?
Two Honest Caveats
A counter-finding from the same measurement, which complicates the easy version of this argument: Microsoft Teams occupies 1090 MB on this machine and does not use Electron at all. It carries its own WebView2 framework instead. Bringing a web runtime along makes an application heavy regardless of which runtime it is, and "native" is not a synonym for small.
And the limits of the setup, since this series lives on reproducibility: one machine, one operating system, one afternoon. Bundle sizes say nothing about memory use or start-up time, neither of which was measured here. Strongbox and Proton Pass both manage passwords, but they are not feature-for-feature equivalent, and a fair size comparison would need to account for that.
The Point
The measurement does not say that shipping an engine is wrong. It says the trade has been mispriced.
What is actually bought is version control on one difficult platform. What is actually paid is a browser per application, at several hundred megabytes each, and a standing obligation to patch a component whose exploit record is among the busiest in the industry. That obligation is rarely written into the decision document, and it does not expire.
So the default deserves inverting. Draw on the engine the operating system already maintains, and bring your own only where you can name the platform, the version and the reason. Anything else is a browser you have quietly agreed to maintain.
You did not install a password manager. You installed a browser that happens to know your passwords.