Whitelist or blacklist: the two architectures of safe browsing

Two families, same street, both serious about their standards. In one house, the computer reaches exactly forty-one approved sites — the bank, the school portal, the airline, the grocery — and nothing else exists. In the other, the browsing is broad but guarded: known-bad categories are walled off, images pass through sight protection, new territory gets judged as it loads. Ask either family why theirs is the kosher way and you will get a confident answer. The truth is more useful than either answer: these are two engineering architectures with different failure modes, and mature households often run both — for different people.

The whitelist: nothing exists until approved

Allow-only architecture inverts the internet's default. Its strengths are structural:

• Certainty. The reachable universe is enumerable — you can read the whole list. For a child's first browsing, a storefront terminal, or a household that wants the question closed, enumerability is the feature.
• No race against the new. The internet mints new destinations by the second; allow-only never has to have heard of them. Novelty is unreachable by default.
• Auditability. "What can this device reach?" has a finite, printable answer — the property institutions and schools prize, for reasons detailed in device security for schools.

Its costs are just as structural. Every legitimate new need — the government form, the new supplier's portal, this year's camp registration — is a request, a wait, an administrator. Run wide, a whitelist turns one parent into a help desk; run narrow, it quietly teaches the household to route around it, and workaround culture is the beginning of the end for any standard. The allow-only pattern shines brightest where needs are stable and the user count is high — which is why it anchors the strictest tier of household setups described in kosher internet at home.

The blacklist: everything exists except the barred

Block-known-bad architecture keeps the internet's default and fights it. Done seriously, it is not a list at all but a layered judgment: category walls, live evaluation of new destinations, image-level sight protection, search that never surfaces the barred in the first place. Its strengths:

• Breadth without a queue. The legitimate long tail — the obscure form, the one-off research need, the supplier nobody anticipated — just works. No administrator, no Tuesday request.
• Fit for real work. Parnassah browsing is unpredictable by nature; the architecture that tolerates unpredictability is the one work can live on, the case built in kosher internet for the home office.

Its classic weakness is the race: the new bad thing exists before anyone has barred it. This is exactly where the last decade's engineering moved the frontier — from static lists to live evaluation, where new territory is judged on what it is rather than whether it was previously catalogued. How that evaluation layer works image-by-image is the subject of image safety while browsing.

“The whitelist fails closed and annoys; the blacklist fails open and races. Serious architecture is about choosing which failure you can live with — per person.”

kolbo.life

The real answer: per-person, one platform

The store-counter question "which is kosher?" dissolves once you see households as fleets. The nine-year-old's device: allow-only, forty destinations, closed question. The mother's device: guarded-broad, because the household's logistics live online. The office machine: guarded-broad with work categories opened, per the work-versus-home split. Same standards, different architectures, chosen by role.

What makes per-person architecture livable is running it on one platform instead of three products. A browser built kosher from the ground up — the position of KolBo Browser, "the first kosher Chrome," with "nothing to disable, nothing to bypass" — can hold both postures as configurations of one secured engine, alongside search that is, in the homepage's words, "a proprietary search engine, not a filtered feed." One engine, per-person policy, no seams between products — seams being where every workaround lives.

Frequently asked questions