Blocking access to unlawful content: what counts as enough?

Setting the expectation first

Law 5651 expects two separate things from a public access provider. The first is a set of internal IP allocation records that answer who, when and which address. The second is taking measures against access to content that constitutes a crime. The two expectations are met with different tools and are very often mixed up.

This article explains the second expectation at the level of concepts. Which measure counts as "enough" depends on the type of business, your user profile and legal interpretation. Get legal advice on that; here we only describe the tools.

Three different concepts

Blocklists

Authorities publish lists of domains and addresses to which access has been blocked. A network device can fetch such a list regularly and stop devices on the network from reaching those addresses. The list defines what is "prohibited"; it is a narrow and precise set. It does nothing about content that is objectionable but not on the list.

DNS filtering

Every domain name is first resolved to an IP address through a DNS query. A filtering DNS server refuses to answer for domains in certain categories or redirects them to a warning page. Categories vary by provider: malware, phishing, gambling, adult content and so on. DNS filtering is broad but coarse; it works at the domain level, not the page level. Devices using DNS-over-HTTPS can bypass it unless network policy prevents that.

Family filters

A family filter is mostly an end-user concept. Carriers and operating systems offer profiles that restrict content unsuitable for children by category. They usually work per person or per account and were not designed for a business's guest network.

Method	What it does	What it does not do
Blocklist	Cuts officially blocked addresses	Does not touch content outside the list
DNS filtering	Cuts domains by category	No page-level distinction; can be bypassed with DoH
Family filter	Restricts content per user profile	Does not scale to a business network

Which device does this job?

Blocking is a network policy task and is applied in two places:

1. DNS side: point the guest network's DNS at a filtering service and use a firewall rule to stop guests from using any other DNS.
2. Firewall side: block specific IP addresses or address ranges, or run a rule set that fetches blocklists automatically.

Both belong to your corporate firewall, your UTM appliance or your filtering DNS provider.

What the appliance does and does not do

Let us be plain: Hotspot-Box is not a content filter. It does not fetch blocklists, it does not filter DNS by category, and it does not offer a family filter. Rather than hide that as a gap, we describe it as a division of labour:

• The box's job is identity and records: it verifies the guest with an SMS code, assigns an internal IP, records the session with timestamps, and protects record integrity with a SHA-256 chain and an RFC 3161 timestamp.
• The box is a firewall that separates the guest network (pfSense based), but it does not replace a corporate UTM.
• You can point the guest network's DNS at a filtering service; that is your network policy, not a feature we advertise.
• The optional DNS query log records domain names requested by devices that use the box's DNS. It is not a blocking tool, and enabling it means updating your privacy notice.

The walled garden (the list of addresses reachable before login) is not a blocking tool either. It simply lets an unauthenticated device reach the portal and the addresses needed for verification.

Example scenario

Picture a student dormitory. Management points the guest network's DNS at a service that offers category filtering and uses the firewall to stop guests from using any other DNS. On the same network, the box verifies every student's device with an SMS code, assigns an internal IP and records the session. If a request arrives one day, management can show two things separately: "this was the device using this address at this time" (the box's record) and "these categories were already filtered on our network" (the DNS service's policy).

The two documents complement each other, but they come from two separate systems. Using one in place of the other weakens both. A filter alone cannot identify anyone; a record alone cannot prove filtering.

An honest answer to "what is enough?"

There is no single answer. This framing may help:

• The expected level of care for a small café and for a school campus is not the same.
• Where minors are a large part of the audience (dormitories, tutoring centres, gaming venues) DNS filtering has become close to standard; get legal advice for your case.
• The tighter the blocking, the worse the guest experience and the higher your support load. Choose categories deliberately.
• No technical measure is one hundred percent. A documented, reasonable and maintained policy is always better than no measure at all.

Whatever policy you choose, the box handles the identity and record side the same way. You can always answer "who and when"; the "what can they reach" decision stays in your network policy.

See industries for example set-ups by sector and products for the product details.

This article is for general information only and is not legal advice.