---
title: "Why use an open-source website blocker?"
canonical_url: https://torwache.com/guides/open-source-website-blocker/
md_url: https://torwache.com/guides/open-source-website-blocker/index.md
---
[Guides & comparisons](https://torwache.com/guides/)

Technical guideFact-checked August 25, 2026

# Why use an open-source website blocker?

Open source does not magically make an extension trustworthy. It does make important claims inspectable: what permissions are declared, where the list is stored, and whether anything is sent away.

On this page

[What you can verify](https://torwache.com/guides/open-source-website-blocker/#verify)[What source cannot prove alone](https://torwache.com/guides/open-source-website-blocker/#limits)[A five-minute audit](https://torwache.com/guides/open-source-website-blocker/#audit)[How torwache is built](https://torwache.com/guides/open-source-website-blocker/#architecture)

## Four privacy claims source code can support

Requested permissions

The manifest lists the browser capabilities the extension asks Chrome to grant.

Network requests

You can search for request clients, remote endpoints, telemetry libraries, and update services.

Storage location

You can see whether the blocklist uses local storage, browser sync, or an external account.

Page access

Content scripts and host permissions reveal whether code can run inside visited websites.

## A public repository is not the whole trust chain

Source availability does not automatically prove that a store package was built from that exact revision. Large projects may also be technically open while remaining difficult to audit because the shipped bundle is generated, minified, or dependent on remote services.

Prefer small projects with reproducible packaging, readable release notes, few runtime dependencies, and a manifest that matches the store permission prompt.

## A five-minute browser-extension audit

1.  1
    
    ### Open the manifest
    
    Read the permissions and host permissions first.
    
2.  2
    
    ### Search for network APIs
    
    Look for `fetch`, XMLHttpRequest, WebSocket, telemetry, and remote URLs.
    
3.  3
    
    ### Find the storage calls
    
    Confirm whether data is stored locally, synchronized, or sent to a backend.
    
4.  4
    
    ### Check content scripts
    
    Understand which websites can run extension code and what that code reads.
    
5.  5
    
    ### Compare the package
    
    Look for a documented build or packaging command and inspect the release artifact.
    

## Why torwache is intentionally easy to inspect

The source is strict TypeScript organized as small WXT entrypoints and modules for the blocklist, domain rules, storage, navigation guard, and blocked page. WXT and Vite compile it to browser-native JavaScript, HTML, and CSS; there is no runtime UI framework. The only runtime dependency is tldts, used to reject public suffixes such as `co.uk` and private suffixes such as `github.io`.

You can [read the repository](https://github.com/alexgutjahr/torwache), inspect the typed[WXT configuration](https://github.com/alexgutjahr/torwache/blob/main/wxt.config.ts), or[download the tested release zip and its checksum](https://github.com/alexgutjahr/torwache/releases). The build generates the Manifest V3 file. Automated checks fail if its permissions or capabilities expand unexpectedly, and the package test verifies the ZIP's deterministic output and Store layout. The point is not “trust us because open source.” The point is that you do not have to.

## Block the site. Keep everything else.

torwache is free and open source, keeps its blocklist local, and has no account, ads, timers, streaks, or analytics inside the extension.

[Add to Chrome](https://chromewebstore.google.com/detail/ibffnlnhgaoppogfnaejknianccnknlj)

[Read the source](https://github.com/alexgutjahr/torwache)