{"id":6731,"date":"2026-09-30T11:21:52","date_gmt":"2026-09-30T09:21:52","guid":{"rendered":"https:\/\/www.imtlazarus.com\/?p=6731"},"modified":"2026-10-01T09:42:04","modified_gmt":"2026-10-01T07:42:04","slug":"safe-browsing-isnt-blocking-its-guiding","status":"publish","type":"post","link":"https:\/\/www.imtlazarus.com\/en\/2026\/09\/30\/safe-browsing-isnt-blocking-its-guiding\/","title":{"rendered":"Safe browsing isn’t blocking. It’s guiding."},"content":{"rendered":"\n

Ask most school IT teams how web filtering works and you will hear a version of the same answer: a list of sites students can reach, and a much longer list they can’t.<\/p>\n\n\n\n

It is a sensible starting point. It is also why so many filtering strategies end up in the same place: an arms race between the block list and the students looking for a way around it, with teachers caught in the middle.<\/p>\n\n\n\n

Blocking tells a student where they can’t go. It says nothing about what should happen once they are somewhere they are allowed to be. And today, the places students most need to be online are exactly the places schools can’t simply block.<\/p>\n\n\n\n

The problem with thinking in domains<\/h3>\n\n\n\n

Traditional filtering makes its decisions at the level of the domain. A site is either on the list or off it.<\/p>\n\n\n\n

That worked reasonably well when the web was a set of separate destinations. It works much less well now. Think about what a student opens in a single lesson: a search engine, a video platform, a shared document, an AI assistant. Each one is a legitimate learning tool. Each one can also surface content that has no place in a classroom.<\/p>\n\n\n\n

Block the domain and you lose the learning. Allow it and you accept whatever comes with it.<\/p>\n\n\n\n

That is the trade-off domain-level filtering forces on schools. It is why IT teams spend so much time weighing whole sites against each other, and why students keep finding the gaps anyway.<\/p>\n\n\n\n

Guiding works inside the session<\/h3>\n\n\n\n

IMTLazarus takes a different approach. It does not filter by DNS, at the level of the domain. It works through code injection, inside the browsing session, at the level of the content itself.<\/p>\n\n\n\n

That changes the question. It stops being “can students reach this site?” and becomes “what should students experience here, during this lesson?”<\/p>\n\n\n\n

In practice, a useful tool can stay open for the lesson while the content that does not belong there is kept out of it. The same thinking applies to AI. Instead of choosing between banning an assistant and leaving it wide open, schools can set guardrails that shape what it will and won’t do for students.<\/p>\n\n\n\n

Schools no longer have to choose between the tool and the safeguard.<\/p>\n\n\n\n

Guiding, not watching<\/h3>\n\n\n\n

There is a second reason this matters, and it goes beyond the IT office.<\/p>\n\n\n\n

When filtering is only about blocking, the natural next step is more monitoring: more logs, more alerts, more watching. But visibility is not the same as governance. Knowing what a student did after the fact does not help them make a better choice in the moment.<\/p>\n\n\n\n

Guiding shapes the environment so that good choices are the easy ones. Students still explore, search and ask questions. They just do it in a space designed for learning. That is the difference between accompanying students and simply watching them.<\/p>\n\n\n\n

Being clear about where it works<\/h3>\n\n\n\n

Good guidance is also honest guidance. IMTLazarus is designed first and foremost for class time on school-managed devices. A school can choose to keep filtering active all day, but if families decide on different settings at home, school filtering does not extend to that use.<\/p>\n\n\n\n

We think schools deserve that clarity, and so do families. Filtering is also one of the ways schools meet obligations such as CIPA<\/a>, and IMTLazarus helps schools meet them.<\/p>\n\n\n\n

Five questions to ask of any filtering approach<\/h3>\n\n\n\n