MD TECH
Under the interface
What looks simple on the surface often is not. This is how the layers behind Privio fit together.
OVERVIEW
A request, followed from your device to the internet.
When an app asks for a website, an ad or a file, that request travels through several systems before anything comes back. Privio sits in that path. It resolves names, applies policy, carries traffic through an encrypted tunnel and relies on the network beneath it, in a deliberate order.
Choose a layer below to see where it sits and what it does. Green packets pass through. The amber packet is stopped by policy before it reaches the internet.
Every connection begins with a question: what is the address for this name? DNS resolution is the earliest point at which a system can decide whether a request should proceed. Checking names here lets trackers, ads and known malicious domains be refused before any connection is made, which is efficient and keeps unwanted traffic off the device entirely.
The policy engine applies the rules: which domains are allowed, which are blocked, which apps may connect and which profiles apply to which devices. Keeping policy in one place means family controls, app blocking and business rules behave consistently, and changes take effect everywhere at once.
A tunnel carries traffic between the device and the protection layer inside an encrypted channel, so what travels over a shared or untrusted network cannot be read or altered along the way. The tunnel is also what lets filtering apply no matter which network the device joins.
Underneath everything is ordinary connectivity: mobile data, Wi-Fi, routers and carriers. Our systems have to stay fast on good networks and recover on poor ones, because protection that makes the connection worse is protection people switch off.
Simplified conceptual flow, shown to explain how the layers relate. Real traffic paths vary by device and network.
ENGINEERING PRINCIPLES
How we make technical decisions.
Start from the system
We begin with how networks and devices actually behave, and design features from there instead of from a marketing list.
Fail safely
When something goes wrong, the system should fall back to a safe, predictable state instead of silently dropping protection.
Keep the fast path fast
Protection should add as little delay as possible, because anything that slows people down gets switched off.
Make behavior explainable
If a request is blocked, the system should be able to say why. Decisions that cannot be explained cannot be trusted.
Collect only what is needed
Data a product does not need is data it should not hold. We design to keep that set small.
Respect the device
Phones have limited battery, memory and background time. Protection has to fit inside those limits.
CONSTRAINTS WE DESIGN FOR
The real world is messy.
Good infrastructure is judged on bad days: weak signal, switching between Wi-Fi and mobile data, low battery, older phones and congested networks. We design for those conditions first, so that protection keeps working when conditions are least friendly.