Hush: a Safari content blocker that hides cookie nags and tracking scripts

What Hush blocks, and what it deliberately leaves alone

Hush targets two things: cookie consent notices and privacy-invasive tracking. The README describes it as blocking "nags to accept cookies and privacy invasive tracking in Safari." The project is explicit that it does not block ads. The FAQ gives the reason: ads, however annoying, might be important for makers and businesses on the internet, and the maintainer does not want to take their revenue. That is a product decision, not a technical gap, and it changes who should install it. If you want a general-purpose ad blocker, Hush is the wrong tool by design. If your complaint is the banner that covers the page before you can read anything, Hush is aimed exactly at that.

Hush also does not answer consent dialogs. The FAQ states it "will block specific scripts and elements on the website, but can't and won't interact with the website itself and thus won't click on any buttons." So the notice is hidden rather than dismissed. The site still receives whatever request it would have received; Hush just removes the element and the script from view. That distinction matters for anyone who assumes a hidden banner means a recorded consent choice.

How the blocking actually works: a generated rule list, not a browser extension script

Hush is not a traditional extension that runs JavaScript inside each page. The README calls it "primarily a host of rules that integrates with Safari in a native, lightweight way." The repository layout supports that: there is a Shared/ directory, an iOS/ target, a macOS/ target, and a data/ directory that feeds the build. Safari consumes the compiled rule list through its native content blocker API, which is why the app can stay small and why it has no access to browsing history or passwords. The README states there is "absolutely no access to your browser habits or passwords" and that "nothing leaves your device."

The rules are not written by hand in the app. The Makefile shows a Deno pipeline: `fetch_external` pulls external list data into ./data with network and write permissions, and `blocklist` reads ./data and emits the compiled rule list. The Xcode build target calls `MINIFY=1 make blocklist` and redirects the output into blockerList.json inside the app bundle. The licence section credits the Fanboy List from easylist.to under CC BY 3.0, which is the upstream source the pipeline pulls from. So the maintenance surface is the rule data plus the build scripts, not a large Swift codebase.

Installing Hush and enabling it in Safari

There is no package manager step for end users. The README points to the App Store for both platforms, with a direct DMG download for macOS. The same App Store ID, 1544743900, is linked for iOS and macOS. iOS requires iOS 14 or later; macOS requires macOS 11 or later.

After installing, the app itself has almost nothing to configure. The README describes setup as enabling it in Safari settings, Content Blockers. Once enabled, open a site that normally shows a cookie banner. The expected result is that the banner is gone and the page content is readable. If a site still shows a nag, the README says the cause is usually that hiding the notice would break the site, or that the site uses obfuscation to defeat blockers. Either way it asks you to open a GitHub issue or fill in the linked report form.

If you want to build it yourself rather than install from the store, the README gives the prerequisites: Deno and the Xcode command line tools.

brew install deno
xcode-select --install

The Makefile then exposes the build and test targets. Unit tests for the blocklist run with `make test_unit`, which is `deno test`; UI tests run with `make test_ui`, which invokes xcodebuild against the Hush iOS scheme on an iPhone 17 simulator. Compiling the blocklist alone is `make blocklist`.

Where Hush fails: broken sites, obfuscated banners, and no consent record

The README names two failure modes directly. The first is sites that keep showing nags. The stated reason is that on some sites it is not possible to block or hide cookie notices and tracking consent screens without also breaking the site, and that others have obfuscations in place to prevent blocking. This is a rule-list blocker, so it wins or loses on the specificity of its selectors. When a site renders its consent UI through the same container as its content, hiding the container hides the content too.

The second failure mode is the reverse: sites that break. The README's troubleshooting order is to disable Hush in settings, reload, and see whether the site recovers. If it does, the project wants an issue report. That is a reasonable workflow but it puts the diagnosis on you, and it means a broken checkout or login page is a real possibility on sites the list has not been tuned for.

The third limitation is conceptual. Because Hush hides rather than dismisses, it does not record a consent decision. The FAQ is blunt that compliance is up to the website owners and that blocking all cookies also breaks a lot of websites. The maintainer's own stated compromise is to use incognito mode, which is why the app exists. If you need a durable, auditable consent state, Hush does not provide one and does not claim to.

Hush compared with a general-purpose ad blocker

The obvious alternative is an ad and tracker blocker such as one built on the EasyList family, which Hush already draws from for its own data. The difference is scope and intent. A general blocker filters ads, trackers and annoyances together, and its rule lists are tuned for that broader goal. Hush filters only the consent layer and tracking scripts, and the README states the ad exclusion is deliberate so as not to take revenue from publishers. In practice that means a general blocker will remove more from the page, including things you may want to keep, while Hush will leave ad slots in place and only remove the notice in front of them.

A second difference is platform. Hush is a Safari content blocker for iOS and macOS. The related searches show people asking about a Chrome version, and the README gives no Chrome build, no Chrome Web Store link and no Chromium target in the repository. The targets are iOS/ and macOS/ only. If Safari is not your browser, Hush is not available to you, and no amount of rule-list tuning changes that.

Maintenance, licensing and what the MIT terms mean for forks

The last push to the default branch was on 2026-07-26, and the repository is not archived. The only tagged release listed is v1.0 from 2020-12-23. That combination tells you where the work happens: the app binary has been stable for years, and ongoing effort goes into the rule data and the Deno scripts rather than into versioned app releases. Anyone tracking the project should watch commits to data/ and scripts/, not the releases page.

Hush itself is MIT licensed, copyright Joel Arvidsson. That permits reuse and redistribution with the licence and copyright notice retained. The blocklist data is a separate matter: the README credits the Fanboy List from easylist.to under CC BY 3.0, copyright Rick Petnel and contributors. If you fork Hush and ship the compiled blocklist, the attribution requirements for that upstream data travel with it, and the two licences are not identical. This is a description of what the repository states, not legal advice.

Upgrade cost is close to zero for end users, since updates arrive through the App Store and there is no configuration file to migrate. For self-builders the cost sits in the toolchain: Deno, Xcode, and a working simulator for the UI test target.

Editorial conclusion

Hush fits Safari users on iOS 14 or later and macOS 11 or later who want cookie notices and tracking scripts hidden without a general ad blocker, and who accept that the app cannot click consent buttons for them. It is the wrong pick if you want ads blocked or a Chrome extension, since the project targets Safari and says ad blocking is not its purpose. Before adopting it, check the App Store listing for your region, confirm the Content Blockers entry appears under Safari settings, and read the open issues for sites you use daily, because the README notes that some sites cannot be cleaned without breaking them.

Frequently asked questions

Official sources

1. License: MIT
2. oblador/hush on GitHub
3. Project website
4. README
5. Releases