BluEclipse
BluEclipse
BluEclipse browser tools
A browser extension that stops the request and then closes the hole it leaves behind, with every filtering decision made on the machine it runs on. The constraint was the point: block properly without becoming another heavy process in the browser.

ADvoidance is a browser extension that blocks advertisements, trackers and telemetry requests — and then removes the page furniture that blocking alone leaves standing.
A modern web page loads a great deal more than the thing you came for. Advertising networks, tracking scripts, telemetry services and embedded promotional widgets each add requests, visual clutter and processing that has nothing to do with the article, the product or the form in front of you. The cost is paid in bandwidth, in battery, and in attention.
Blockers exist to address exactly this, and plenty of them work. The question ADvoidance was built around was narrower and more awkward: how much of that job can be done by something genuinely small? A blocker that runs on every page of every tab all day is in a position to become the very thing it was installed to remove.
Websites usually reserve the space for an advertisement before the advertisement itself arrives. The layout is written expecting a banner of a particular size, and that space is committed whether or not anything ever fills it.
So a blocker that only stops the network request produces a strange result. The advertisement is gone, and the hole it was going to sit in is still there — a column of empty space, a stranded heading, a bordered box containing nothing. The page is quieter than it was, but it is not cleaner, and in places it is harder to read than if the advertisement had simply loaded.
ADvoidance therefore works in two passes:
The second pass is what separates this from hiding things with a stylesheet. Visual hiding makes an element invisible while leaving it in the document, still occupying its box and still shaping everything around it. Removing or collapsing the element lets the page reflow into a layout that makes sense without it.
An extension that protects you from tracking has no business building a second tracking layer to do it.
This is the constraint the rest of the design answers to. Filtering happens on the device, against rules that ship inside the installed package. There is no BluEclipse service in the path, which means there is no browsing history for us to hold, secure, subpoena-proof or eventually lose.
The extension does handle information — it could not block anything otherwise. What matters is where that information goes:
| Handled | Destination |
|---|---|
| Hostname of the site in the active tab | Read on device, to apply your rules and name the site in the popup |
| Hostnames you choose to whitelist | Chrome extension storage, on your machine |
| The enabled or disabled setting | Chrome extension storage, on your machine |
| Daily and total blocked-request counts | Counted and kept locally |
| Requests the browser reports as blocked by a client | Counted locally, never transmitted |
| Page elements matched by cosmetic rules | Inspected in the page, never sent anywhere |
Every row ends on the same machine it started on. None of it is sold, rented or transferred, and none of it is used for advertising or profiling. The extension does not download or execute remote JavaScript or WebAssembly either: the executable code and the filtering rules are both part of the package you installed, so what is running is what was reviewed.
Preferences and counters live in Chrome extension storage until you change them, reset them, or uninstall the extension — at which point they go with it.
The visible interface is a popup with a toggle, a site name and a count. Under it sit two browser-level techniques doing quite different work: request filtering, which decides what is allowed to load, and DOM inspection, which decides what is left to tidy. Keeping those two honest about each other is most of the engineering.
Everything else was a question of what to leave out. The priorities were set early and held:
A blocker is unusual in that it never stops running. It evaluates rules on every request of every page in every tab, for as long as the browser is open. Features that would be unremarkable in an application you open, use and close are charged against you continuously here, which makes restraint a functional requirement rather than an aesthetic one.
ADvoidance started as a small engineering project around a straightforward question — how lightweight can an effective blocker be? — and it turned into a proper tour of browser request pipelines, extension APIs, filtering rules, DOM analysis and client-side privacy tooling. The scope stayed small. The problem did not.
ADvoidance is one of the smaller things BluEclipse builds. It is also a fair illustration of how we approach the larger ones: understand what the problem actually is, take out the complexity that is not earning its place, and build around what the person using it is really trying to do.
Not every product needs to become a platform. Sometimes the right answer is a small tool that does one job properly and then gets out of the way.
ADvoidance is a BluEclipse Technologies product.
Everything ADvoidance handles, and where it stays, is written down in plain language rather than buried in a policy you need a lawyer to parse.
Browser extensions, request-level filtering and privacy tooling that keeps its processing on-device — that is the kind of work this represents.