Most parental control products answer the first question thoroughly and the second one barely at all. Children and teenagers are targeted with their own lure vocabulary — free in-game currency, follower boosters, cheat downloads, streamer giveaways — and none of it trips a category filter. Add a DNS-verified phishing verdict to the same decision path you already own.
It matches a known phishing site that pretends to give away free game currency.
Currency generators, follower boosters, cheat downloads and giveaway pages that a category filter reads as harmless.
Load the daily feed on-device or at the router and no browsing event ever leaves the household.
A flat CSV of domains drops into Pi-hole, BIND, Unbound or a firmware blocklist without new infrastructure.
A category engine was built to sort the web by subject matter. A phishing database was built to sort it by intent. Family products ship the first and assume it covers the second.
Think about what a content classifier actually does. It looks at a site and decides which bucket it belongs in — gaming, social, adult, shopping, news, streaming — and your product lets a parent switch buckets on and off by age. That model works beautifully for the thing it was designed for. A page about firearms is about firearms whether or not anybody has ever been harmed by reading it, and the categorisation stays true for years.
A phishing page defeats that model on purpose. It is not about anything. It is a pixel-perfect copy of a login screen, hosted on a domain that was registered on Tuesday and will be dead by Sunday, and its subject matter is whatever it needs to be to get a password typed into it. Ask a category engine what a fake game-login page is about and the honest answer is "gaming" — which is a category most family products leave switched on, because blocking gaming outright is not what a nine-year-old's parent wants.
This is why the two controls have to be independent inputs to the same decision. Content policy answers "should this child be looking at this kind of thing right now", and it should stay tuned by age, by time of day, by whatever your product's model of a family looks like. Phishing detection answers "is this specific hostname a currently live credential trap", and the answer to that should be no for every member of the household, at every hour, on every device, regardless of what the content policy says.
A parent who has deliberately allowed gaming has not consented to a fake gaming login page.
The line that separates content policy from safety
Category data ages slowly. Phishing infrastructure ages in hours. A database that refreshes every 24 hours, DNS-verifies every entry through rotating proxy infrastructure and only keeps domains with an active A record is doing a fundamentally different job from a categorisation crawl — it is tracking a fleet that is being rebuilt continuously, and it drops entries as they go dark instead of hoarding them.
| What a household needs | Content filtering alone | Phishing detection alone | Both together |
|---|---|---|---|
| Keep age-inappropriate material off a young child's screen | |||
| Block a fake login page for the child's own gaming account | |||
| Stop a "free currency generator" that looks like an ordinary game site | |||
| Handle a brand-new domain nobody has classified yet | |||
| Protect the parent's device on the same family plan | |||
| Allow gaming while still blocking gaming-themed credential theft | |||
| Explain to a parent exactly why a page was blocked |
Half-filled markers are honest, not hedged: neither approach resolves a domain that has never been seen before, which is why the unknown case belongs in your own risk logic rather than in either database.
Nobody sends a twelve-year-old a fake invoice. The bait that works on a child is built around scarcity, status and the fear of losing an account they care about more than almost anything else they own.
The single biggest category is in-game currency. Every major online game with a virtual economy has spawned an ecosystem of generator sites that promise free currency, free skins, free battle passes or free premium items in exchange for a username and, one step later, a password or a linked-account login. The pages are polished, they use the game's real artwork, and they include a fake progress bar and a queue counter to manufacture urgency. A child who has been asking for a paid item for six months is exactly the person that page was designed for, and "just enter your username, we never ask for your password" is the opening move rather than the whole con.
Social clout is the second axis. Follower generators, view boosters and verification-badge services target the same psychology in slightly older children, and they are frequently promoted inside the platform they are stealing from — a comment on a popular video, a reply to a trending post, a link in a bio. The credential harvested there is often the child's most valuable one, because the same account is the login for a games library, a messaging app and, increasingly, a school-adjacent service.
Then come the softer surfaces that parents rarely think about. Cheat and mod downloads, which combine credential theft with actual malware and which a child will actively hunt for rather than stumble into. Fake giveaway pages tied to a specific streamer or creator, timed to a real event so that the story checks out. Homework-answer and essay sites that ask a student to "sign in with school" and harvest an education SSO credential — the same credential that unlocks the district's email, storage and identity systems, which is why our K-12 education page treats it as a serious school-side risk and not just a household one.
What ties all of these together, from an engineering point of view, is that they are hosted on short-lived domains that exist for days. They are not categorised as harmful because their content is not harmful in the categorical sense — a generator page is, semantically, a gaming page. They are found through search, through in-game chat, through a friend's message, and through short-form video, so they arrive on the device by paths that bypass whatever safe-search or app-store control you have configured. A domain-level known-bad lookup catches them because it does not care what the page claims to be about.
Be honest about the boundary. This service is a known-bad lookup, not a page classifier. It will not score a generator site that was registered an hour ago and has not yet been observed anywhere. Pair the verdict with your own signals — an unfamiliar domain a device has never resolved before, a link arriving from an unknown contact, a page requesting credentials on a network the household does not use — and treat the API as the layer that removes the confirmed cases so your heuristics can focus on the rest.
The phishing check itself should never soften with age — a credential trap is a credential trap at every age. What changes is the interface around it: how much is explained, who is told, and whether the child gets a way forward.
The right posture is a walled garden, and the block page should not try to teach anything. A young child does not need to understand what a phishing domain is; they need a friendly screen that says this page is not one they can visit and offers a route back to something they were already doing.
Notify the parent quietly rather than dramatically. At this age a blocked phishing domain is almost always an accident — a mistyped address, a video-description link, an ad inside a game with in-app advertising — and framing every event as an incident produces alert fatigue in the parent before the child is old enough for it to matter.
This is the age band where the generator sites land hardest, because it overlaps almost exactly with peak engagement in the games that have the biggest virtual economies. Blocking silently here wastes the moment. The block page should name the trick in one sentence a child can repeat to a friend: this site pretends to give away free items so it can steal your login.
Give the child an action that is not just "ask your parent" — a button that reports the link, or a short explanation of what would have happened next. Children in this band are old enough to feel embarrassed about nearly falling for something, and a product that treats a near-miss as a normal, survivable event gets told about the next one.
Teenagers route around controls they experience as surveillance, and a product that silently blocks without explanation is one they will work to defeat rather than trust. Here the phishing block is the one control that is easiest to justify on its own terms: it is not about what they are allowed to look at, it is about somebody trying to steal from them.
Show the domain, show that it is confirmed rather than guessed, and be explicit that content categories and phishing blocks are separate systems. A teenager who understands that the phishing layer applies to their parents' phones too is being treated as a member of the household rather than a suspect, and that framing is what keeps the product installed.
The age dots are a design cue, not a policy. Real households do not divide cleanly at ten and fourteen, and a product that hard-codes those boundaries will annoy every family whose child sits near an edge. Treat the bands as defaults a parent can slide, and keep the phishing verdict outside the slider entirely.
| Across all three bands | What your product should do, and why |
|---|---|
| Never varies with age | Notice what did not change across the three bands: the verdict, the enforcement, and the fact that the block happens. Product teams sometimes propose making the phishing layer advisory for older children, on the theory that teenagers should be allowed to make their own mistakes. That reasoning works for content and fails for credential theft, because the consequence of the mistake is not the teenager's experience of one page — it is a compromised account that is often reused across the household, and increasingly the recovery contact for a parent's account too. |
| Should vary with age | What should change with age is the amount of data the parent receives. A five-year-old's activity can reasonably be reported in full. A sixteen-year-old's should not be, and a product that treats them identically will lose the older child's cooperation, which is the only thing that makes any of this work on a device they carry out of the house. Report blocked phishing domains to the parent at every age; report general browsing in decreasing detail as the child gets older. |
| Never varies by device | The same verdict applies to the tablet in the kitchen, the console nobody can install an agent on and the phone in a teenager's pocket. A household is a single blast radius: one compromised credential is usually reused somewhere else in the same home, so partial coverage buys much less safety than the coverage map suggests. |
Family software runs in places that are hostile to a chatty API call — a battery-constrained phone, a $40 router, a carrier network with millions of subscribers. Choose the shape that matches the constraint you actually have.
Ship the daily feed into the app as a local set and check the hostname before the page loads. The CSV carries domain,category,dns_status and a daily changelog of additions and removals, so an incremental update is small enough for a mobile data connection. This is the shape most consumer products should default to: no per-request cost, no round trip on the critical path, and no browsing event leaving the device at all.
For a router vendor with a family mode, the feed loads directly into the resolver already running on the box — Pi-hole, BIND with an RPZ zone, Unbound, or a vendor firmware blocklist. Every device in the house is covered, including the games console and the smart TV that no agent will ever be installed on, and a mistyped domain simply fails to resolve. Refresh once a day after the 04:30 UTC build and the box needs no other connection to us.
Whole household · no client softwareA mobile carrier running a family plan, or a vendor operating its own DNS service for subscribers, loads the same feed into the recursive resolvers that already serve those subscribers. The check happens in infrastructure the operator owns, at the point where it costs essentially nothing, and no per-household traffic is generated toward us at all. Enterprise feed delivery covers SFTP and S3 drops plus STIX/TAXII for teams that already run a threat-intel pipeline.
Millions of subscribers · flat costWhere a live answer matters more than a local copy — a link a parent pastes into a support form, a URL in a message being screened by your own service, a one-off check from a dashboard — call GET /api/v1/check or POST /api/v1/batch from your servers. Batch takes up to 100 domains per request at one lookup each and the rate limit is 10 requests per second per key. Read the API documentation for the full response shape.
The decision between the feed and the API is unusually clear-cut for consumer family products, and it is worth stating plainly: if your product checks a URL on every page load for every child in every household you serve, an API call per check is the wrong architecture regardless of price. Millions of households multiplied by hundreds of navigations a day is a volume no per-lookup model is designed for, and it puts a network dependency in front of a feature that has to work when the connection is bad.
The feed inverts that. It is a flat $499 per month, or $499/month with a historical archive, priority support, custom format options, 100,000 API credits and a dedicated account manager. You download the full database once a day, hold it locally, and every check thereafter is a set membership test in your own process. The enterprise tier adds SFTP or S3 delivery, custom update frequency, an SLA and on-premise deployment for vendors who need the data inside their own perimeter.
Keep a modest credit balance alongside the subscription anyway. There are always cases where a live, authoritative answer is worth a credit: a customer-support agent investigating a report, a parent-submitted link on your website, a QA harness verifying that your local copy agrees with the source. The open /api/v1/stats endpoint needs no key and consumes no credits at all, which makes it a convenient way for your feed-loading job to confirm the database size and last-update timestamp before it swaps a new build into production. Credit packages are listed on the pricing page.
Consumer family software lives or dies on a single question a journalist will eventually ask: where does my child's browsing history go? Build the answer into the architecture, not into the privacy policy.
Every parental control vendor that has had a bad press cycle has had it about data, not about filtering accuracy. The pattern is always the same — a product that streams every URL a child visits to a cloud service in order to make a decision, a breach or a research disclosure, and a headline about children's browsing histories. The technical detail that would have prevented it is the same one that is easiest to design in from the start: do not send the browsing event anywhere.
The feed makes that straightforward. When your product holds a local copy of the database, the check for a given hostname happens entirely inside the household. Nothing about which sites a child visits, how often, or in what order ever reaches us, because there is no request. The only network traffic is your product fetching the same file every other customer fetches. That is a claim you can put in a marketing page and defend in an audit, and it is qualitatively different from "we anonymise the URLs we collect".
Where you do call the API, the surface stays deliberately narrow. The check endpoint takes a hostname; it does not want a full URL, and it strips the scheme and any path you send anyway. Send only the host. A URL's path and query string are where the personally identifying material lives — a document ID, a session token, a search term, a username in a profile link — and none of it is needed to answer whether a domain is a known phishing host. Normalising to a bare hostname on your side before the call is one line of code and it removes an entire class of accidental data collection.
The third rule is about the key. The API key is the username you chose at registration, it authorises spending against your credit balance, and it must never appear in client-side code — not in a mobile app binary, not in a browser extension, not in a router's firmware image. Anything shipped to a household is readable by somebody. Calls go from your servers, and if a client genuinely needs a live answer it asks your backend, which authenticates the household's own session and calls us with your key. The same discipline is covered from a different angle on our DNS filtering and ISP and telco pages.
The account that holds the subscription, the school app, the carrier plan and the shared tablet all belong to an adult — and each of them is a lure that only works on a household with children in it.
Family-plan billing is the most reliable of these. A message claiming that a family subscription failed to renew, aimed at a parent who genuinely does pay for three or four of them, is a strong pretext precisely because it is plausible. The same is true of carrier family-plan notices, device-locator alerts and "your child's screen-time report is ready, sign in to view it" messages, all of which trade on a parent's willingness to act quickly about something involving their child.
School-app impersonation is the second pattern and it is getting worse as districts adopt more portals. A parent receives a message about a permission slip, a fee, a bus change or a grade, pointing at a page that copies the school's real portal login. Parents rarely know which of the six systems their school uses is legitimate for any given notice, and they have no way to check — which is exactly the gap a lookup fills. Products serving school communities may also want to read our higher education page, where the same portal-impersonation problem appears with a different set of victims.
Then there is the shared device, which is the case most parental control products handle worst. A tablet in a living room is used by a seven-year-old in the afternoon and a parent at night, and profile switching is aspirational at best. If your product only applies protection to the child profile, the household's most exposed device is unprotected for half its waking hours — and the adult session is the one with a saved payment method and an email account that can reset everything else. A domain-level phishing block that applies to the device rather than the profile solves this without any of the awkwardness of applying content categories to an adult.
That is the strategic argument for putting phishing detection in a family product at all: it is the one safety feature parents want for themselves. Content filtering is something a parent does to a child. A phishing block is something the household gets. It converts a product that a teenager resents and a parent feels slightly guilty about into one that plausibly protects everybody, and it is a genuine differentiator in a category where every competitor's feature list is the same list of categories and time limits.
Why this belongs on your roadmap, not just in your backlog
The block itself is the easy part. The interface around it decides whether a family learns something, ignores the alert, or uninstalls the product.
Start with the parent notification, because that is the one most products get wrong in a specific and avoidable way. A notification that says "inappropriate content blocked" teaches a parent nothing and, worse, mixes a phishing event into the same bucket as a curious search. Separate the two channels entirely. A phishing block deserves its own notification type with its own copy: what the site pretended to be, that it was a confirmed match rather than a guess, and one concrete next step — check whether the child entered anything before the block landed.
Say what happened in the household's own vocabulary. "We blocked a fake login page pretending to be a Roblox-style free-currency site" tells a parent what to talk about at dinner. "Category: phishing/malware, confidence 0.98" tells them nothing, even though that is what the API returned. Keep the technical fields for an expandable detail view, where a curious parent can see the domain and the date it was last verified, and where a support agent can read them out.
The weekly family report is where this compounds. A single blocked domain is noise; five in a week clustered around one game is a pattern worth naming, and a report that says so gives a parent a specific conversation to have rather than a vague anxiety to carry. Keep the report short, lead with the phishing section rather than burying it under screen-time charts, and include a plain-language explanation of one lure the family actually encountered that week. That is a genuinely educational artefact, and it is the part of the product parents forward to other parents.
For teenagers, replace silent blocking with a teaching moment wherever the risk allows it. Show the interstitial, name the technique, and explain what would have happened next — that the page collects the password and then tries it against the game, the email account and anything else that shares it. A teenager who has read that explanation three times has been taught something durable that will outlast your product on their device, and they are far more likely to tell you when something slips through than one who has only ever seen a closed door.
The site claimed to give away free in-game currency and asked for a game account login. It matches a phishing site confirmed in today's database.
One phrasing rule worth enforcing across your whole UI: never present the absence of a match as safety. A domain that is not in the database returns a confidence of 0.0 and a null category, which means "no confirmed match today" — not "verified safe". Products that blur that line train families to trust a green tick that was never earned, and the first time it is wrong they lose the household.
Straight answers on cost model, privacy, coverage limits and how this sits next to a category engine you already license.
Because they answer different questions. A category engine sorts the web by subject matter and holds its answers for years; a phishing database tracks short-lived infrastructure that is rebuilt continuously and drops entries as they go dark. A fake game-login page is, categorically, a gaming page — which is a category most family products leave enabled.
Run them as independent inputs to the same decision. Content policy varies by child and by age; the phishing verdict applies to the whole household at all times. Neither replaces the other, and the failure mode of trying is a product that blocks a chemistry article and allows a credential trap.
Yes, and that is the architecture we would recommend for any consumer product. Subscribe to the daily feed, download the full database once a day, and hold it locally on the device, the router or your own resolver. Every check after that is a local set membership test, so no browsing event ever leaves the household and there is no per-lookup cost.
The feed ships as CSV or JSON with a daily changelog of additions and removals, which keeps incremental updates small enough for a mobile connection or a low-powered gateway.
The daily feed is $499 per month, and the annual tier includes a historical archive, priority support, custom format options, 100,000 API credits and a dedicated account manager. That price does not scale with the number of households you serve, which is the whole point for a consumer product.
Credits are monthly subscription and billed monthly, from Growth at $99/month for 25,000 lookups up to Enterprise at $999/month for 750,000 lookups per lookup. Full detail is on the pricing page, and bank transfer is available for feed subscriptions and orders above $4,000.
Not until it has been observed and verified. This is a known-bad lookup over confirmed, DNS-verified domains, not a heuristic classifier that scores an unseen page. We would rather say that plainly than let a family product make a promise it cannot keep.
What it does give you is a high-confidence, unambiguous block on the large body of infrastructure that is already confirmed and still resolving, refreshed every 24 hours. Combine it with your own signals for the unknown case: a domain the household has never resolved before, a credential form on a site with no history, a link that arrived from an unknown contact.
The verdict is per domain, and for this use case that is usually the right granularity. Phishing operations aimed at children generate large numbers of unique paths behind a small number of hosts — a per-victim URL for tracking, the same host underneath. Blocking the host stops all of them at once and makes caching trivial.
It does mean you should not expect a verdict about one page on a large shared platform. If a lure is hosted on a mainstream file-sharing or site-builder service, a domain-level block would be far too broad, and that case belongs in your own policy layer rather than in this database.
No. The API key is the username chosen at registration and it authorises spending against your credit balance, so it must stay on servers you control. Anything shipped to a household — an app binary, a browser extension, router firmware — should be assumed readable.
If a client genuinely needs a live answer, put a thin proxy endpoint on your own backend that authenticates the household's session, applies your own rate limit, and calls us with your key. For the common path, ship the feed to the device instead and skip the network entirely.
Give phishing its own notification channel, separate from content blocks, and write it in household language. Name what the site pretended to be, say that it was a confirmed match rather than a guess, and give one concrete action — check whether anything was typed before the block.
Keep the category label, DNS status and last-checked date in an expandable detail view for parents who want them and for your own support team. And never present the absence of a match as a guarantee of safety; a null result means no confirmed match today.
Buy a monthly plan for live lookups, or talk to us about a daily feed subscription if you want the whole database on-device. Either way you can have a working phishing verdict in your family product this week.
