Transparency
How ScotNet is run, what is shown publicly, what stays private, and where service-specific detail belongs.
ScotNet is a self-hosted collection of websites, network services, monitoring, weather data and security tooling. Transparency here means publishing enough information to understand service behaviour and important decisions without turning private infrastructure, credentials or raw security telemetry into public data.
One ScotNet, several services
The main site, ScotNet Monitor, local weather and history, Secure DNS, the DNSBL, BackToYou and private self-hosted applications are separate parts of the same wider ScotNet environment. Each service can have its own operational rules, but the public/private boundary follows the same principle: publish useful outcomes and explanations; keep sensitive implementation detail private.
Public by design
Service state
Friendly service names, confirmed public states, update times and confirmed incident/recovery summaries can be shown publicly.
Changes
Release versions, change history and the purpose of significant updates are documented so public behaviour is traceable.
Weather presentation
Useful current conditions, forecasts and bounded history can be presented without exposing provider credentials or private collection state.
Service-specific policy
Where a subsystem makes security or reputation decisions, its public policy and appropriate review or lookup routes remain available.
Private by design
Some detail is intentionally not public because publishing it would weaken security or expose data that visitors do not need.
- Passwords, API keys, webhook tokens, signing material and other credentials.
- Raw request bodies, mail content, complete security logs and unrestricted event feeds.
- Internal addresses, private ports, probe targets, topology and service-account configuration.
- Private monitor identifiers, raw probe errors, response bodies and low-level diagnostic evidence.
- Private databases, runtime state, backups and filesystem locations that do not need to be public.
A public dashboard is not made more transparent by exposing the machinery an attacker would most benefit from.
Monitoring and incidents
ScotNet Monitor provides the confirmed public health view used by the detailed monitor and concise status pages. Public presentation is deliberately smaller than the private operator view: visitors can see the service, state and confirmed timing, while raw targets, ports, response content and diagnostic detail remain private.
Security decisions are scoped
Security controls belong to the service they protect. ScotNet favours evidence-based, proportionate and reversible responses where that is practical, but a DNSBL listing rule is not a universal ScotNet policy. The DNSBL is one security subsystem with its own operational transparency, address lookup, return codes, evidence lifecycle and delisting process.
Data minimisation
ScotNet prefers server-rendered, bounded public views over downloadable copies of private state. Raw provider caches, complete monitor snapshots and private databases stay behind the public site. Public pages expose the information needed for the feature rather than publishing the source store itself.
Change control and recovery
Releases are versioned and validated before production acceptance. Updates should be narrow enough to understand, create rollback material before replacing live files, and avoid rewriting unrelated services. Operational fixes may advance one component without pretending every ScotNet component changed at the same time.
What transparency does not mean
Transparency is not a promise to publish secrets, raw attack evidence, a network map, private user data or instructions that make bypassing safeguards easier. Public status is an observed service-health view, not a service-level agreement or a guarantee that a system can never fail or be attacked.