# Search, a WebKit browser, and the size a Chromium browser refuses to be

> Search is a six-megabyte macOS browser built on the WebKit engine that Safari already uses, which is the whole reason it opens instantly, and the README is unusually honest about the trade that buys: it fills in the Chrome extension APIs WebKit does not have itself. It is also the rare browser where the privacy claims come with a table saying who can read what.

**driceroland/Search** — A small, fast WebKit browser for macOS, by Office Commun.

- Repository: https://github.com/driceroland/Search
- Stars: 2,292 · Forks: 210
- Language: Swift
- License: MIT
- Published: 2026-09-30 · Updated: 2026-09-30 · Language: en
- Canonical page: https://hysenlabs.com/projects/driceroland-search

## One engine, already on the machine, and what that buys

The architectural decision is stated in one sentence and everything else follows from it: it uses WebKit, the engine already inside every Mac, which is what Safari runs on.

That sentence is the product. A Chromium-based browser on a Mac carries a second copy of an engine, which means a download of hundreds of megabytes, an update path separate from the operating system's, and a process permanently resident in memory that you did not choose to have. The README attributes the app's size, about 6 MB on disk, and its instant launch, to not doing that. The project description says about 3 MB, so the two figures in the README are inconsistent, and either way the ratio against a Chromium browser is the point rather than the exact number.

The consequence for a developer is worth stating plainly. Because WebKit ships with macOS, there is nothing to vendor, nothing to pin and nothing to patch on your schedule. An engine bug is fixed when Apple ships the fix, on the same cadence as every other part of the system. That is a genuine operational advantage for a browser and it is also the trade: you take Apple's update schedule and Apple's security model, and you have no say in the engine's version.

The second consequence is the one the README is upfront about further down. WebKit has a real extension engine, the one Safari uses, and it does not implement every API a Chrome extension can call. So a browser built on WebKit that wants to offer Chrome extensions has to fill the gaps itself. The README names them: bookmarks, history, downloads, side panel, offscreen documents, fonts, notifications, speech, and OAuth sign-in. Search implements those itself, on top of WebKit's engine.

So the extension story is not that Chrome extensions simply work. It is that they mostly work, through a compatibility layer the author wrote, with a stated list of the gaps it fills. That is a more useful statement than a compatibility badge, and it is the thing to evaluate before you migrate.

The framing of the whole project is in the same place. The README says it was built by a design studio that spends its day in a browser and was tired of the ones that had become products, and then the line that sets the design test: this one is a tool.

## What it refuses to have, and why the refusals are the design

There is a section titled what it doesn't do, and it is more informative than the features list because every item is a decision somebody could have made differently.

No extension you have to install to feel at home. Ad blocking, element hiding, reading mode, picture-in-picture and password management are all built in, and extensions exist for everything else. That is a different extension strategy from every other browser, where the default state is a browser with nothing and the ecosystem supplies the rest. The reasoning is visible in the feature list: the author considers ad blocking, clutter hiding and reading mode to be table stakes rather than extensions, which is a defensible position and a controversial one.

No sync, no account, no cloud. Tabs, history and passwords stay on the Mac. There is no server at all, which the privacy table states directly with a dash in the who-can-read-it column for anything else. For someone who has spent a decade signing into a browser account, that is a genuine trade rather than a feature, and it means multi-device tab continuity is absent by design.

No telemetry, no analytics, no crash reports. The README then enumerates exactly what does leave the machine: the pages you request, their icons, and one small request a day to check for a newer version. Naming the third item is the detail that makes the claim checkable, and it is corroborated elsewhere in the same document, since the automatic updater checks once a day and verifies the build is signed by the publisher before installing it.

One window. Tabs are the only kind of new there is, so there is no window management, no pop-out windows and no separate application windows. Combined with Split View, which is two pages inside one window with a draggable divider, that is a coherent position. The browser is a single surface with a tab strip, and a user who wants two pages side by side gets exactly that rather than two windows.

The section also lists the built-in keyboard equivalents for what extensions would otherwise do, which is the argument for the built-ins in one line. Ad blocking, hiding an element permanently on a site, reading mode, floating video and keychain passwords each have a keystroke.

## The privacy table, which is the rarest thing in a browser README

Most browser privacy sections are a paragraph of assurance. This one is a table with three columns: what, where it is, and who can read it. Four rows and a fifth catch-all, and each row names a real macOS mechanism rather than a vague promise.

Passwords are in the macOS login keychain as ordinary keychain items tagged with the application's name. That specific detail matters, because it means the items are not in some private encrypted blob the browser invented. They are keychain items, so the system's own access control applies, and any other application that wants one triggers the standard permission dialog. The README says readable only by Search and signed by the publisher, and that any other app triggers the system's permission dialog, which is the mechanism rather than the promise.

History, bookmarks, open tabs and hidden elements are in small JSON files under the application's support directory in the user's Library folder. Readable by the user. That is a design decision with a specific character: a database is better engineering, and plain files are better for a person who wants to look, and for a project whose stated reason for being open source is that anyone can read exactly what a browser handling your passwords and history is doing, plain files are the consistent choice.

Cookies and site data are in WebKit's own store, with the honest note that the sites that set them can read them as in any browser.

Extensions are unpacked in a directory under Application Support, with their data in WebKit's extension store, and each extension can read what it was permitted when you added it. Naming the extensions directory as a visible folder is again the plain-files instinct applied to code.

Anything else: nowhere, because there is no server.

Two details below the table are the kind that show the author thought about the edges. A private tab has its own cookie jar and leaves nothing behind when it closes. And applications you allow in the system privacy settings for automation can read the address and title of your tabs through AppleScript, with private tabs never shown. That last one is a limitation of the macOS automation model rather than a choice, and stating it is better than omitting it, because a reader who assumed otherwise would be wrong about their own threat model.

## The built-ins, and the three that are really about not extending the page

Most of the feature list is ordinary browser competence done without fuss, and four items are worth explaining because each solves a specific irritation rather than adding a capability.

The address field finishes from your own history and never sends what you type anywhere until you press Return. That is a privacy property stated as a behaviour: no suggestion service, no search-as-you-type request, no DNS prefetch of a partial query. On a browser whose selling point is a single field, that field's behaviour is the feature.

Element hiding is permanent. Press a shortcut, click the thing, and it goes, and it is still gone on that site next time, before the page has drawn a single frame. There is a companion keystroke that lists what is hidden on the current page, which is the detail that makes it trustworthy. A hiding feature you cannot inspect is a feature you will eventually distrust, and a hiding feature you can inspect is one you will keep using.

Ad blocking happens at the network level, before the page, so there is nothing to render and nothing to slow down. That is a different implementation from the injected-script approach, and the difference shows up as faster page loads rather than slightly less content. The README notes it is on by default and can be turned off per site if something breaks, which is the right default and the right escape hatch.

Video lifts out of the page into a small window that stays above other applications. On macOS that is a floating panel, and the reason it exists is that a video in a tab competes with everything else on screen while a video in its own window does not.

Split View is the fourth. Two pages in one window with a draggable divider, where the outlined pane receives page commands, and pairs and their widths persist with the user's Space including after a restart. Persisting with the Space rather than in app preferences is the detail that makes it feel native, since macOS spaces are already the user's unit of window organisation.

Session restore is listed as tabs coming back instantly and costing nothing until clicked, which in a WebKit browser is a real feature rather than a given, because lazy restoration requires the engine to defer page construction and that is not free to implement.

## Signing, entitlements, and the updater as an attack surface

The automatic update mechanism is the most security-relevant thing in this repository and it gets one sentence, so it is worth pulling apart.

Once a day the application checks for a newer build, downloads it, verifies it is signed by the publisher, and swaps it in for the next launch. Nothing restarts on its own. The verification step is the part that matters. An update channel that downloads code and runs it is a remote code execution path by design, and the only thing standing between a compromise of the update server and every user of the browser is that signature check. The README says the download is verified as signed by the publisher, which is a code-signing requirement rather than a hash comparison, and a signature is the right primitive because it survives a compromised download host.

Deferring the swap to the next launch is the second correct decision. An updater that replaces a running application either restarts it, which loses unsaved work, or swaps files underneath a running process, which produces a mixed-version state. Waiting until next launch avoids both.

The repository layout supports the analysis. There is a `Search.entitlements` file and a separate `Search.passkeys` entitlements file, which is the expected shape for a macOS application that needs the keychain and, separately, the passkey-related entitlements that Apple's system requires and that must be requested in a dedicated profile. The passkey support described in the feature list, offering the Mac's passkeys for a site under the field, is why the second entitlements file exists.

There is a `Search.sdef`, which is a scripting definition, so the browser is scriptable from AppleScript and the automation caveat in the privacy table follows from that rather than being an accident. There is a `SECURITY.md` and a `.gitleaks.toml`, so secrets scanning is configured in the repository, which is a small signal about the maintainer's habits.

What is not in the README is any statement about how the signing key is protected or how the update feed is authenticated beyond the signature. For a browser that stores passwords in the keychain, that is the question an evaluator should ask, and the source is available to read: the stated reason the code is published is that anyone can read exactly what the browser is doing, and the update path is part of what it does.

## Reading the source, and the 42,000 lines that have no dependencies

The section for developers explains why the source is published in a sentence that also explains the project's whole rationale: so anyone can read exactly what a browser handling their passwords and history is doing, build it themselves, or fix something that bothers them.

Three claims follow and all three are checkable. The code is about 42,000 lines of Swift. There are no dependencies beyond what Apple ships with macOS. And it is one file per concern.

The dependency claim is the load-bearing one. A browser that links nothing but the operating system's frameworks cannot be compromised through a supply chain, because there is no supply chain. It also means the update surface is the application itself, and the credential storage is the keychain, and the extension engine is the system's. That is a genuinely different security posture from every other browser, and it is a direct consequence of choosing WebKit rather than shipping Chromium.

The 42,000 lines figure sets expectations usefully. That is small. It is small enough that a person can read it, which is the project's claim, and it is also small enough to raise the question of what a Chromium-based browser of comparable capability would require, which is a number in the millions when you include the engine. A one-file-per-concern structure also means a person looking for where a behaviour lives can find it by filename, which is the property the argument depends on.

The build section gives a Swift Package Manager manifest, a script that assembles a double-clickable application, and a toolchain requirement of Xcode 16 with Swift 6 on macOS 14 or later. The `Engine/` directory at the top level, alongside `Sources/`, `Tests/`, `Installer/` and `Icon/`, suggests the WebKit bridge is separated from the application, which is the natural way to keep the platform interface in one place.

The remaining top-level entries are the small print of a real project. A version file, a changelog, a roadmap, a notes file, a security policy and a contributing guide. Several shell scripts with names like build, engine, fresh, publish and tap, which is a build and release pipeline. A `bench` directory, so the performance claims are measurable. A `skill/` directory and an `ideas` file, which suggests the project is also used as a place to collect capabilities for an agent to draw on. And a `test-find` entry, which is either a test or a helper for finding one.

## Conclusion

Adopt Search if you want a browser on macOS that starts instantly, blocks ads at the network level, and stores your history in JSON files you can read, and if you are willing to accept that Chrome extensions run on WebKit's engine with compatibility shims rather than Chrome's. Do not adopt it if you need a Windows or Linux build, or if you depend on a Chrome extension that leans on an API the shim does not cover. Verify first by installing it alongside your current browser rather than replacing it, importing your passwords from Chrome in the trial, and checking the two extension APIs the README names as missing, bookmarks and offscreen documents, against the extensions you actually use.

## FAQ

### What is the Search browser?

It is a small, fast, quiet web browser for macOS built by Office Commun, using WebKit, the engine already inside every Mac and the one Safari runs on. It is free, about 6 MB, requires macOS 14 or later, and is distributed from the publisher's site or through Homebrew as a cask.

### Why does Search use WebKit instead of Chromium?

The README attributes its small size and instant launch to not shipping a second copy of Chromium to download, update and keep in memory. The trade is that you take Apple's engine and its update schedule, and that WebKit does not implement every Chrome extension API, which Search fills in itself.

### Do Chrome extensions work in Search?

They run on WebKit's own extension engine, the one Safari uses, and the README names the Chrome APIs WebKit lacks that Search implements itself: bookmarks, history, downloads, side panel, offscreen documents, fonts, notifications, speech and OAuth sign-in. This requires macOS 15.4 or later, and you can load an unpacked extension folder and reload after changes.

### Where does Search store passwords and history?

Passwords are ordinary items in the macOS login keychain tagged with the app name, so the system's permission dialog governs any other app's access. History, bookmarks, open tabs and hidden elements are small JSON files in the app's support directory under the user's Library folder. The README states there is no server and no sync.

### Does Search send any telemetry?

No telemetry, analytics or crash reports are sent anywhere. The README names the only things that leave the machine as the pages you request, their icons, and one small request a day to check for a newer version, and the updater verifies the download is signed by the publisher before installing it.

### What licence is Search released under, and how big is the codebase?

The MIT License, with the text in the LICENSE file at the repository root. The README states the code is about 42,000 lines of Swift with no dependencies beyond what Apple ships with macOS, organised one file per concern, and that the source is published so anyone can read what the browser is doing or build it themselves.

## Sources

- [driceroland/Search on GitHub](https://github.com/driceroland/Search)
- [Issues](https://github.com/driceroland/Search/issues)
- [License: MIT](https://github.com/driceroland/Search/blob/main/LICENSE)
- [README](https://github.com/driceroland/Search/blob/main/README.md)
- [Releases](https://github.com/driceroland/Search/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/driceroland-search