Reports

Every page is named as its entry in the menu. The tile Online services of the dashboard shows the services of Warda on Internet as the box sees them: the collective base (its real state: off, on and working, last exchange failed…; see Collective base), the server of the updates, and the subscription, each with the age of its last check ("checked 3 minutes ago"). The results of the checks (task probes) are kept across restarts, so the tile shows at once after a restart instead of "checking…" for 90 seconds; the state of the collective base is read without its counts. Since 0.6.9 each protocol of the encrypted DNS served to the devices has its own line on the tile — DNS over TLS (DoT), DNS over HTTPS (DoH), DNS over QUIC (DoQ) — with its state (Answering, Not answering with the error under it, or not used), the age of its last check and a link to Network → DNS services: one protocol may fail while the others answer (its port taken by another program, its listener stopped). These checks are made by the box against itself (see Encrypted DNS for the devices): a firewall between the devices and the box is not seen by them.

The Health of the box card shows the processor, memory, temperature and storage, and since 0.6.9 the last hour of the box:

• Load: a chart of the last hour of the load average over 1, 5 and 15 minutes (1 min, 5 min, 15 min), with the values now, above the gauge of the processor (it replaces the line of the three figures under it);
• Network, after the storage: what the network card receives and sends now (Received, Sent, per second), the chart of the last hour, and the name of the card with its totals since it started ("eth0 · since it started: 12.3 GB received, 4.5 GB sent"). The card is the one of the default route (IPv4, else IPv6), else the busiest one (a card of the machine first), never the loopback: on a Raspberry Pi, a virtual machine or in Docker with network_mode: host, the card of the machine. In a Docker container on a network of its own (a bridge), Warda only sees its virtual card, so only its own traffic: the block then says "Virtual card (a container on its own network, or a tunnel): only the traffic that goes through it is counted." The block shows once the card was read twice (10 seconds after the start).

Since 0.7.0 each bar of the card takes the colour of its use, in whole percents (70.9 % is 70): green up to 70 %, orange from 71 to 85 %, red from 86 to 99 %, black at 100 % (ui/src/lib/usage.js). The memory and the storage show their percentage beside their size ("1.6 GB / 7.8 GB · 20 %"); the temperature is measured against 85 °C (its bar is full at 85 °C and coloured on the same thresholds). The charts of the load and of the network sit in a frame, and the four figures of the card Protection are centred in their cells.

Since 0.7.1 each figure of the card Protection has its icon before it (ui/src/components/Icon.svelte): a magnifier for the queries, a shield with a cross for those blocked, a laptop and a phone for the active devices, a light bulb for the suggestions waiting.

The history is a point every 10 seconds (the load and the bytes per second received and sent since the point before), the last hour kept in memory. Up to 0.7.9 nothing was written to the disk and a restart started it again; from 0.7.10 it is written to machine-history.json every 5 minutes and when Warda stops, and read again at the start (a stop without warning loses 5 minutes at most). GET /api/v1/system/history?since=<Unix time> (every account that reads the dashboard, as GET /api/v1/system) gives step_seconds (10), interface and points (t in Unix seconds, load of three values, rx, tx in bytes per second), the oldest first, after since (0 or absent: the whole hour; not a number: 400): the dashboard asks for the hour once, then for the new points only, every 5 seconds with the gauges. GET /api/v1/system gives machine.net (absent until the card is read twice, or without a card): interface, physical (false for a virtual card), rx_rate, tx_rate (bytes per second) and rx_bytes, tx_bytes (since the card started).

The Services of the box card shows the state of the services: DNS filtering (upstream servers down), encryption of the upstream servers (how many over DNS over HTTPS, over TLS, in clear), encrypted DNS for the devices (the protocols served of those chosen), DHCP server (off, running, paused because another server answers, failed), local names, updates (automatic or manual) and backups. Under them, the line Base list: the entries of the lists loaded and the date of the last check; from 0.7.11, for the lists of Warda, the entries blocked, the names of the source lists they cover and the day the list was built (see Lists).

The menu Reports groups its pages by theme: Activity (query log, queries, domains, devices, trends), Family (Internet, time spent, summary of the week), Security, and Company (Company reports, Warda Business, business.reports: see Company reports). On a phone the menu lists them under the same titles.

Each report of the menu is marked free (green dot), with a subscription (star) or with Warda Business (diamond, see Plans). The free ones are those below and the report of each child; the hours of Internet, the time spent, the trends, the security report, the alerts and the collective base come with a subscription to the collective service of Warda (Administration → Subscription, GET /api/v1/subscription). Until it opens, Warda is in beta: every function, those of the subscription and of Warda Business included, is open to every installation. Since 0.6.8 no page of Warda Business is empty: each one works (beta).

Plans#

One product, three plans (internal/admin/subscription.go; a plan gives every function of those below it):

GET /api/v1/subscription lists each function with its plan, and soon for those announced, not in this version yet: the HTTPS inspection (inspection, both paid plans: only for the devices chosen, never without the knowledge of the people concerned, never for banks, health or personal messages). The menu Business (administrators, each page marked with the diamond, all beta) holds: Security center (business.center, see Security center), Users of the directory (business.identity: Active Directory and LDAP, from 0.8.2 Microsoft Entra ID, Google Workspace and the sign-in of their people, see Users of the directory), Roles and groups (the groups of accounts and the catalogue of roles, business.roles, see Roles), Device policies (business.devices, see Device policies), AI services (business.ai, see AI services), Data loss prevention (business.dlp, by the names asked, see Data loss prevention), Unblock requests (business.unblock, see Unblock requests), SIEM export and audit (business.siem, below), Sites (business.sites, see Sites) and High availability (business.ha, see High availability); the reports of the company (business.reports) are in the menu Reports. The Guest Wi-Fi of 0.6.7 (business.guests) is removed: the box does not share a Wi-Fi, in Docker even less, and it has no place in Warda. Its page, its API (/api/v1/business/guests), the profile Guests with its column on Protections and the hiding of the local names from the guests are gone; the upgrade to 0.6.8 deletes its settings (and the services blocked and the safe search of that profile), and a backup made before does not bring them back. The ordinary group of devices Guests (the devices of visitors, protected as adults by default) stays. Administration → Subscription shows the three plans side by side, their prices and what is coming; Warda Business opens with the subscriptions (contact: [email protected]). From 0.8.5 the box activates nothing itself: at the bottom of each plan a link opens the sign-up page of the customer area, https://account.warda-dns.com/signup, in another tab — Create my customer area (Free), Subscribe (Subscription, the main button), Sign up (Warda Business, which keeps Contact us by mail beside it) — and the page says "Every plan is taken in the customer area of Warda (account.warda-dns.com), which opens in a new tab. Then link this box to your account in Administration > Customer area." The button Subscribe of before, which did nothing, is gone. From 0.7.5 the plan of the installation is the one of the statement of the customer area while it is valid, else free; the beta keeps everything open whatever the plan. From 0.8.0 a Subscription covers one box: a second box of the same account gets the free plan unless the customer moves the plan to it (Warda Business: every box of the account, each counted as a site; a pair of high availability is of Warda Business, and only during the beta is the other box of a pair covered by a Subscription too). A backup restored on another box does not bring the plan with it (see Backups and Customer area).

After the beta: the plan checked by the box itself (from 0.8.5, function plans-checked of the catalogue; internal/httpapi/plans.go). During the beta every function stays open to everyone and nothing below applies; once the subscriptions open (or when the plan of a box lapses):

• The pages of a function the plan does not include are left out of the menus, not shown locked (inPlan, ui/src/lib/plan.js), and so are the modules of the dashboard tied to one (the sensitive categories and the collective base). On Household → People, the switch Internet paused and the hours of a child show only when the plan includes the hours of Internet.

• Every route of a paid function answers 402 ("… comes with a plan this box does not have") before the service is asked, whatever the page shows, declared in one table (routeFeatures): the hours of Internet, the modes (the pause of a person), the time given, the limits by category and the school holidays (schedule); time spent, trends, security report, the summary of the week kept and sent and the test of the mail server, alerts and alerts of the monitored categories with their decisions (reports.*, alerts); the collective base; the protection outside the home; and every page of Warda Business (company baseline rules, security center, AI services, company reports, device policies, directory and its sign-in, data loss prevention, unblock requests and the automatic unblock, SIEM export, high availability, sites, groups of accounts, the logo). The service checks most of them again. The watch of the known breaches keeps its own checks (the test of a password stays free).

• What only ends, leaves or removes stays open, so that a plan that lapses never leaves the box held by something it can no longer change (routeUndo):

  Route	Why it stays open
  DELETE /api/v1/people/{id}/mode	ends the pause of a person
  DELETE /api/v1/roaming/devices/{id}	removes the address of a device outside the home
  GET /api/v1/business/ha	shows the pair, to leave it
  DELETE /api/v1/business/ha/pairing	cancels a pairing under way
  DELETE /api/v1/business/ha	leaves the pair
  GET /api/v1/business/sites	shows the organisation, to leave it
  DELETE /api/v1/business/sites/{id}	removes a site from the organisation
  DELETE /api/v1/business/sites	leaves the organisation
  DELETE /api/v1/account-groups/{id}	removes a group of accounts (they no longer count without the plan)
  PUT /api/v1/business/dlp	clears a policy of the data loss prevention (the service refuses to set one)
  PUT /api/v1/business/ai	clears a policy of the AI services (the same)
  GET /api/v1/mail	shows the mail server, to remove it
  PUT /api/v1/mail	removes the mail server (the service refuses to set one)

• When the plan lapses, the hours of Internet stop being applied, with the school holidays, the limits by category, the modes (cut, homework) and the time given: never applied without being editable. They are kept, and apply again within a minute when the plan comes back. The export to a SIEM stops sending, its settings kept; the collective base and the relay outside the home stop by themselves.

• The scheduled tasks of a function the plan does not have are hidden (see Scheduled tasks).

Tests check that each route declared exists, belongs to a function of a paid plan and is never both refused and open (TestRouteFeaturesDeclared), and that every paid route is refused on the free plan after the beta and open during it (TestPaidRoutesRefusedWithoutThePlan).

Company baseline rules (business.baseline, Warda Business, beta: open to every installation during the beta) are given once, by themselves, the first time the plan of the installation is Warda Business (checked a minute after the start, then every hour; never during the beta), or by an administrator from Protection → My rules, card Company baseline rules, button Give the baseline rules (GET /api/v1/business/baseline, POST /api/v1/business/baseline, administrators). They block, for the adults and for the devices given to nobody, the categories adult content, gambling, piracy, hate and terrorism, and VPN, proxies and encrypted DNS (Tor included), and block for everyone the mining pools with their subdomains, as ordinary personal rules with the origin business (shown "Company baseline rule"), removed one by one; a name that already has a rule keeps it. Up to 0.7.13 these were 18 names of their own; from 0.8.0 they are the shared list of the protection against the mining pools (baselineNames = threats.MiningPools, 63 names), which blocks them for every box and every plan anyway (see Threats in the names and the answers): the protection decides first, so a query is counted once, with the origin mining:<pool>, whether a baseline rule exists or not. The old list had nicehash.com (the whole site, which has a wallet); the new one has its stratum hosts instead. A box that already got the old rules keeps them (ordinary rules it can remove); Give them again adds the new names, which missing counts until then. The card says when they were given and how many of them are not in force now (applied and missing: the categories no longer blocked and the mining pools without any rule, removed since; a mining pool an administrator allowed is their decision and is not counted). Give them again blocks the categories again (also those allowed since) and adds back the removed pools; it is disabled when nothing is missing. Once subscriptions open, the button is offered only with Warda Business; otherwise the card shows the lock and a link to the plans. Each time is written to the administration log (business.baseline).

Export to a SIEM (business.siem, Warda Business, beta; Business → SIEM export and audit, internal/siem): Warda sends to the collector of the company (Wazuh, Graylog, Elastic, Splunk, Sentinel, QRadar…) the kinds of events chosen: alerts (the notices of the administrators: threats, spyware, leaks, look-alike names, bypasses, new devices, and from 0.8.0 the mining pools, the automatic blocks of the learning, the known breaches, the exposure on the Internet, the restricted mode of the objects and the devices on mobile data at home, from 0.8.2 the reputation of the domains; severity 2 to 8, each kind in the table of Alerts), the administration log, the channels of the data loss prevention told or blocked (dlp: device, name, channel as detail, action alert or block), the names blocked (device address, name, type, reason, origin) or every name asked. Each event is a line of syslog (RFC 5424, facility local0, APP-NAME warda, MSGID the kind), whose message is the event in JSON (time, kind, action, client, device, name, type, reason, origin, detail, actor, severity) or in CEF (CEF:0|Warda-DNS|Warda|<version>|<kind:action>|…, src, shost, dhost, act, suser, cs1 reason, cs2 origin, cs3 type, msg); over UDP (a datagram, 8 KB at most), TCP or TLS (a line each, RFC 6587; TLS 1.2 or later, the public authorities or the certificate of an authority of the company pasted in PEM). The events wait in a queue of 8192 that never slows the DNS: when the collector is late or unreachable, the oldest ones are dropped and counted; the connection is opened again after a failure, waiting 2 seconds to 2 minutes. GET /api/v1/business/siem gives the settings (enabled, address host:port, transport udp, tcp or tls, format json or cef, events, ca, host: the name of the box in the messages), status (connected, sent, dropped, last_error, last_sent) and kinds; PUT changes them (audit siem.on/off); POST /api/v1/business/siem/test sends an event of test (siem.test) on a connection of its own, with the settings given or those saved. The names asked say much about the people: the page reminds that the employees must be told, as the law requires.

Reports → Trends (GET /api/v1/reports/trends?period=week|month, subscription) compares the last 7 (or 30) complete days, to yesterday, with the ones before (whole days on both sides, so that they compare alike): the queries, the blocked ones and their share, the active devices; day by day against the same day before; what blocked (each list, category and service, the personal rules together); the devices whose habits changed (half more or half less, 50 queries at least, and the new ones); the names new in the period (never asked in the three periods before, as far as the journal goes) and those asked at least twice as much. The names need the journal of the period before: when it does not go back that far (30 days by default, so always for 30 days), they are left out and the page says why. The page prints as a summary to keep. From 0.8.5 its four figures get their half ring, and it lists the unusual days of each device, each with an alert (see Trends and unusual days).

Reports → Security (GET /api/v1/reports/security?period=week|month, subscription) counts, over the last 7 or 30 days up to now (today included, so that a threat of the morning shows at once; against the same number of days before), the threats stopped by kind — security (malware, phishing, scams, command and control), newly registered domains, bypass services, illegal content (counted, never named) — against the period before, day by day and by device (never the illegal content by device, nor the devices of the adults who did not agree to detailed reports: they are in the totals only); lists the names stopped with the list that knows them, how often, by how many devices and when last; and shows the devices that behave as infected ones over the last 24 hours: 20 threats stopped or more, 300 names that do not exist or more when they make 40 % of their queries, or 15 names made up by a program (a long label, few vowels or many digits, high entropy: the domain generation algorithms of malware), with a few of them as examples (not for the devices of the adults who did not agree to detailed reports). The same look runs every hour and leaves a notice for the administrators (Alerts). The counts come from the blocked queries kept by day, device and origin (400 days), the names from the journal; everything is computed on the box.

The page explains what it shows to someone who is not a specialist: under each kind of threat, what is normal ("A few a week is common… Many from one device: look at it" for the security threats, "Some are normal" for the new domains, "Expected at 0 at home" for the bypasses — a work VPN or a browser with its own encrypted DNS counts here —, "Expected at 0. Always blocked for everyone" for the illegal content); a legend under the chart by day ("Threats stopped that day", and what a day much higher than the others means); what the list of the devices means (a few is common, many or every day: check the device, see its queries, put it in quarantine while it is cleaned). Buttons lead to the action: See the devices, Open the alerts, Adjust the protections, Block the ways around the filter, and the quarantine of a device from its row.

The Reports menu (administrators only) shows, for the last 24 hours, 7 or 30 days: the types of queries (A, AAAA, HTTPS, TXT, SRV, CNAME…), the answers served from the cache, the blocks by reason (lists, rules of the administrators, categories…, from 0.8.0 restricted, "Restricted mode (objects)", and mining, the mining pools, from 0.8.2 reputation, "Reputation of the domains"), an activity map by day and hour, the top 15 allowed and blocked domains, the top 15 devices with their allowed and blocked queries, the devices silent for more than 7 days, the countries of the sites visited and the upstream servers (protocol, country, answers, errors, mean time since the start). The top allowed domains and the countries leave out the devices of the adults who did not agree to detailed reports, and those of the groups their account made; the countries are counted per device from 0.5.4 on (the days counted before stay for the whole network). Everything is computed on the box and nothing is sent anywhere. Making a report reads the whole journal of the period, long on a small box: once a report of the period exists, GET /api/v1/reports?period=24h|7d|30d answers it at once, and when it is older than 5 minutes a newer one is made in the background (one at a time) while the answer says "refreshing": true; the pages Queries, Domains, Devices and Internet then show the report they have with "A newer one is being computed." next to its time, and ask again every 3 seconds until the new one comes. Only the first report of a period after a start makes the page wait. The types of queries, the reasons of blocking and the upstream servers are drawn as rings whose legend hides or shows a part; the tops give the share of each name. The Activity by hour of Queries (the queries of the period by day of the week and hour) colours each cell by its share of the busiest hour of the period, since 0.7.1: green for the quiet hours, through orange, to red for the busiest (ui/src/lib/heat.js, mixed from the colours of the theme, light or dark); an hour without any query stays empty, and the help under the chart says so (before, the darker the cell, the more queries).

What is drawn how. The reasons of blocking and the types of queries are bars (each with its count and its share: of the queries blocked, of all the queries), as the tops; only the upstream servers are a ring whose legend hides or shows a part. (Up to 0.8.4 this page said the types and the reasons were rings: they were bars.)

Half rings (from 0.8.5, function report-rings; ui/src/components/HalfDonut.svelte, ui/src/lib/halfdonut.js). Each of the four figures at the top of a report gets a half ring, a share of the period shown, drawn by hand in SVG with its colours as classes (nothing breaks the Content-Security-Policy, which allows no inline style), with a text for screen readers:

Types of queries by device (from 0.8.5, function report-device-types). Reports → Devices gives, under the top 15 devices, the types of queries of each (A, AAAA, HTTPS…, the 5 most frequent, the others together as Others), as a bar split by type, over the period of the page, from the journal of the queries (so 30 days at most by default). The same privacy as the names visited: never for the device of an adult who did not agree to detailed reports, nor of a group their account made ("Not shown: a device of an adult who did not agree to detailed reports."; private), and only from the day a device was given to its person. GET /api/v1/reports gives, for each device of top_clients, types [{type, count}] and private.

Map of the countries (from 0.8.5, function report-world-map; ui/src/components/WorldMap.svelte, ui/src/lib/worldmap.js). Reports → Internet draws the whole world (Antarctica left out) and colours the 15 countries of the list in five steps (a scale of logarithms, the first and the fifteenth country being far apart, with their legend "from …"); the other countries stay blank. A country too small to be seen (under 30 square pixels of the map, an island, a city state) also gets a dot at its centre. Each coloured country has its name (in the language of the interface) and count as a tooltip, and the map a text for screen readers. It follows the width of the page and the dark theme. The map is Natural Earth (public domain) through the TopoJSON of the npm package world-atlas 2.0.2 (ISC licence, Copyright 2013-2019 Michael Bostock), projected (Equal Earth) and simplified once by ui/scripts/worldmap.mjs into ui/src/assets/worldmap.json (61 kB), run by hand, never by the build (the codes of the countries come from i18n-iso-countries, MIT, used by the script only). It is served by the box and loaded with the page that shows it only, never fetched from elsewhere; its licence is served beside it (assets/worldmap.LICENSE.txt) and named in NOTICE. "Map: Natural Earth" under the map; "The map could not be loaded." when it fails.

The Learning card of the dashboard disappears once the first week of observation is over (see Learning); the Collective base card gives the state of the exchanges (see Collective base); with Warda Business, the administrators who change the rules see the Unblock requests waiting (see Unblock requests). The Network live card of the dashboard (in the module of the protection, for the accounts that read the reports) shows the 7 last names asked, refreshed every 3 seconds (the new ones slide in; not while the tab is hidden), each with its time, its device and person, and its verdict, blocked ones with what blocked them; it says when it was last updated, and Pause stops it to read. Its 7 lines are fixed (not a setting). Its counter "n queries in the last minute" counts among the 100 last names it reads, so it stops at 100 on a busy network; while the whole network is paused it says so. Without any query yet it says how to set Warda as the DNS server of the box.

The Sensitive categories card (module sensitive) gathers the alerts of the monitored categories of the last 7 days, by person and category ("Social networks · Léa · 3 alerts"), with a link to Protection settings. It is fed only when all of these hold: a device given to a person whose profile is child or teenager (or shared with one); a category set to Monitor for that profile (by default: piracy and social networks for a child, violence and drugs for a teenager; every other category is allowed or blocked); and nothing else blocked the name first (a list, a rule, a service, the hours). An alert is written once an hour at most per device and name. Adults are never monitored, so on a network without a minor the card stays empty ("No alert over the last 7 days."). The alerts come with the subscription: after the beta, without it, the card says "The alerts of the monitored categories come with the subscription." with a link to Subscription (before, it stayed on "Loading…"), and the module is hidden from the dashboard.

The Exposure on the Internet card (module exposure, from 0.8.5) shows the last check of the exposure (its time, or "No check yet.") and the findings active by severity (Nothing exposed when none), with a link to the page Exposure on the Internet. It is among the modules of a new dashboard (and of a dashboard never customized); a dashboard customized before adds it with Customize. It shows to the roles that read the network. The protection and the figures of the day follow the box every 10 seconds (GET /api/v1/summary?activity=0: the summary without the activity of each device, so that the dashboard no longer reads the journal of the day every 10 seconds; without the parameter the summary is whole, as for warda status). The date at the top of the dashboard has a clock next to it (the hour and minutes of the browser, in the format of the language, refreshed each minute), the figures of the card Protection are laid out in a grid of two by two, and the calls of the dashboard are made in parallel, those that may fail (time zone, network check) without holding the others. For the administrators, small badges under the state of the protection name the options of the DNS services turned on: DNSSEC validated by Warda (beta) or required from the upstream servers, the encrypted DNS served with its protocols (DoT, DoH, DoQ), the limit of queries per second, and an answer to the blocked names other than the null address (NXDOMAIN, REFUSED; from 0.8.3 Block page on, from 0.8.4 the default). Each leads to Network → DNS services; an option off shows nothing. The ? of the header (and the footer, and the account menu) opens this documentation in another tab, in the language of the interface. Administration → Activity log refreshes by itself every 10 seconds (a switch, remembered) or by hand. It is read from the box a page at a time; the search by words and the filter by who apply to the whole log, not to the page shown. GET /api/v1/audit/page?offset=&limit=&q=&actor= (reports read; limit 1 to 200, 50 otherwise) gives entries, total, offset, limit and actors (every author of the log, for the filter); GET /api/v1/audit still gives the last entries.

Pages of the long lists (0.6.9). Every long list of the interface is shown by pages, with the same pager (above and under the query log and the activity log): the count ("Lines 1–50 of 1,234"), Lines per page (10, 25, 50, 75 or 100; 50 until the viewer chooses), First page, Previous, "Page 1 of 25", Next and Last page. The pager shows only for a list of more than 10 lines. The number of lines chosen is remembered per list on the browser (localStorage, key warda.pageSize.<list>; a browser that keeps nothing gets 50), and another number keeps the first line shown on the page. A list that shrinks (lines removed, a filter) shows its last page instead of a page gone. The lists: Scheduled tasks, Devices, My rules, Alerts (each group of alerts), Query log, Security (report: its two lists, devices and names), Look-alike names, Time spent (by day, by site), Network analysis (the checks of the network, the machines), Local DNS (the names of the network), Unblock requests (waiting, history), Access to Warda and Activity log. The query log and the activity log are read from the box a page at a time (GET /api/v1/queries/page, GET /api/v1/audit/page); the other lists are read whole, as before, and cut into pages in the browser.

The activity chart of the dashboard counts the last 24 hours by steps of 10 minutes of the clock of the box (from the counts by minute, kept 2 days), the other periods by hour or day. A click on a bar, or the arrow keys, chooses it: its window is detailed under the chart with the answered and blocked queries and, for an administrator, a link opens the query log on that window (and on the device or person chosen).

Events on the activity chart (0.7.0). Above the bars, the chart marks what happened at its time: an alert (diamond), an update installed (triangle), a restart of Warda (disc) and a start of the box (square); from 0.8.5 also the lists updated (a triangle upside down: the downloads that brought a list that changed, lists.updated in the administration log, those within 10 minutes of each other as one mark naming them, 12 at most: "Lists updated: Base list, Social networks") and the alerts of the monitored categories (a hexagon: "Monitored category: Social networks · Léa", which opens Alerts; for the roles that read the reports, with the alerts unlocked, in the scope chosen). A restart of Warda less than 10 minutes after an update or a start of the box is that update or that start, shown once. Each mark has a tooltip ("Alert: Security · Console-Dylan", "Update to Warda 0.7.0", "Warda restarted", "The box started") and a text for screen readers ("3 events on the chart"); the bar chosen lists the events of its window under the chart, and an alert links to Alerts. The marks show for every period of the chart but the real time. The alerts are those of the scope chosen (the whole network, a person, a device), and show only to the accounts that read the reports, with the alerts unlocked (subscription; open to all during the beta). GET /api/v1/activity/events?period=<24h|week|last_week|month|last_month|15m|1h>&scope=<all|person:ID|device:ID> (every account that reads the dashboard) gives {from, to, events}, each event {time, kind, alert?, device?, version?, reason?, lists?, category?, person?} with kind alert, update, restart or boot, and from 0.8.5 lists (with lists: base, a category, or other) and category (with category, device and person), the oldest first; for 24h the window is that of the chart (steps of 10 minutes of the clock of the box). period=live answers 400. The update is the last one installed by the updater (its state file), the start of the box comes from its uptime. Up to 0.7.9 the restart of Warda came from the start of the service, the last one only, and none was kept in the database; from 0.7.10 every start of the period is read in the administration log, with its reason (see Restarts).

People and groups in colour (0.7.0). Each card of Household → People and Groups has a soft colour of its own (8 tints of the charter, ui/src/lib/tint.js), taken from the identifier of the person or of the group: always the same, in the light and the dark theme.

Shaded rows (0.7.0). In the list of Devices, one row out of two is lightly shaded, to follow a row across the page more easily, for everyone and for people with low vision; the colours come from the charter.

Adults without detailed reports are counted everywhere. A person who did not agree to detailed reports still counts in every total and chart: the queries of the dashboard, the chart of the last 24 hours, the counts of each device, the totals of the reports. Only the names they visit are left out (top domains, query log, examples). A test of each release checks it (internal/admin/privacy_test.go).

Trends and unusual days#

Reports → Trends (subscription, see Plans for what it compares). From 0.8.5 (function trends-unusual-days of the catalogue; internal/admin/anomaly.go) it also finds the unusual days of each device: a day on which a device asked far more, or far fewer, queries than it usually does on that day of the week.

• The habits of a device: its own counts of the same weekday over the last 8 weeks (from the counts by day of each device, kept 400 days), the days with queries only. Their median, and their spread: the median absolute deviation as a standard deviation (× 1.4826), never less than 15 % of the median nor than the noise of a count (√median), so that a device of steady habits is not flagged for a few queries more. A day of holidays or a single odd day moves neither much.
• An unusual day is both at least twice the median (or at most a third of it) and at least 4 spreads away from it, with at least 200 queries that day (more) or usually (fewer): a device that asks ten names a day has no habits to break.
• Warm-up: nothing is computed before a device has three such weekdays with queries (three weeks): a new device has no habits yet. A day without any query is never one: the silent devices tell those.
• Counts only: no name is read; computed on the box, with the privacy of the other counts of the trends.

The page lists the unusual days of the period (the 50 most recent first: the device and its person, the day, "1,234 queries, usually about 310 on a Tuesday", Far more than usual or Far fewer than usual) and marks them with a diamond under the chart by day; "No unusual day in this period. A device needs three weeks of habits before its days are compared." otherwise. GET /api/v1/reports/trends gives known_devices and anomalies [{day, device_id, label, person, direction high or low, queries, baseline, score}].

The alert. Every hour (task Unusual days, reports.anomalies, 15 minutes after the start, then hourly), the last 3 complete days are checked and each unusual day raises one alert, trends.anomaly (group Security, SIEM severity 3, detail day|high|queries|usual): "PC-Léa made 1,234 queries on Tuesday 6 October, far more than usual (about 310 on that day of the week): a new program, an update, or a device that no longer behaves as before. To check." or, fewer, "… little used that day, or it may be asking another DNS." with See the trends. Once per device and day (an unusual day is told once, so it cannot be kept under watch: it is accepted, the device kept as it is, or refused, the device put in quarantine), at most 20 a run (a box back after weeks off does not flood its administrators). It needs the trends and the alerts (subscription, open during the beta); without them the task is skipped, and hidden after the beta.