Home › Local build

I assemble a local blocklist

I describe a small browser add-on a person can keep on their own computer. Mozilla Firefox and Chromium-based browsers both speak a dialect of WebExtensions. The samples below are text to read and copy by hand. This page does not install anything, and it does not include a list of real gambling sites.

I choose a browser-local fence on purpose

A WebExtension can ask the browser to block requests that match rules the reader wrote. Manifest Version 3, used by current Chromium extensions and supported in Firefox with some differences, exposes declarativeNetRequest for that job. I prefer it to a content script that hides buttons, because hiding a button still leaves the network request possible. I am not certain every Firefox version matches every Chromium key; Mozilla’s own extension documentation is the place to confirm the keys before you load a folder.

I keep the file shape small

The manifest names the extension and points at a rules file. Replace the example host with names you have already decided to close. Do not paste a list from a stranger, including from me — I am not maintaining one.

{
  "manifest_version": 3,
  "name": "Local access block",
  "version": "1.0.0",
  "permissions": ["declarativeNetRequest"],
  "declarative_net_request": {
    "rule_resources": [{
      "id": "local-blocks",
      "enabled": true,
      "path": "rules.json"
    }]
  }
}

[
  {
    "id": 1,
    "priority": 1,
    "action": { "type": "block" },
    "condition": {
      "urlFilter": "||example.com^",
      "resourceTypes": ["main_frame"]
    }
  }
]

example.com is a reserved documentation name, not a casino. main_frame means the top-level page. Subresources can still load if you only block the frame; if that matters to you, widen resourceTypes after you read the browser’s rule reference. I leave that choice open because a wider rule can also break an unrelated page that embeds a blocked name.

I load it only as a temporary local add-on

1. Create a folder that contains only the manifest and rules.json.
2. In Firefox, use the debugging page for extensions and load the folder as a temporary add-on. In Chromium, use the extensions page with developer mode and load the unpacked folder.
3. Visit https://example.com and confirm the top-level navigation fails. Then visit a bank or health site you still need, and confirm it opens.
4. Write down how to remove the add-on. A block you cannot undo during an emergency is a different kind of risk.
5. Repeat the idea in every browser you actually use. An add-on does not follow you into a browser you did not configure.

Store pages and signing rules change. I do not describe how to publish an extension, because publishing would turn a private list into something other people might install without understanding it.

I mention the hosts file as a sibling, not a duplicate

On Windows and macOS, a hosts entry can map a name to a non-routable address before many apps ask the network. That can cover more than one browser, which an extension cannot. It still misses an app that ships with a hard-coded address, and it still misses IPv6 if you only wrote an IPv4 line. I do not paste a full hosts template here; the gap notes cover why a single line is easy to overtrust.

I decline to automate the list

A script that “discovers” casino domains would need a source, and sources of that kind go stale or name businesses I will not promote. JavaScript in the extension should not fetch a remote list on a timer. A remote list is a trust decision, and a broken or hostile list could block mail or banking. If you later add such a fetch, you have left the design I am willing to describe.

Continue with gap checks or return to access layers.