Connectivity is already around us
There is already a lot of connectivity around us. The harder problem is deciding which networks should be allowed to carry traffic, under what conditions, and with how much authority.
Homes, libraries, universities, businesses, public institutions, community projects and commercial hotspot systems all contribute pieces of a networked environment that is often underused by mobile devices. Phones still tend to treat cellular as the dependable default and Wi-Fi as a binary choice: either trusted enough to join, or ignored.
I think that model is too coarse.
The more useful question is not simply whether a network is trusted. It is what that network actually needs permission to do.
The distinction between connectivity and trust
A public network should not become trusted just because its SSID looks familiar. Network names can be copied. Gateways change. Captive portals appear. Security settings drift. Infrastructure can be replaced while retaining the same visible label.
At the same time, an unfamiliar network does not have to become fully trusted in order to be useful.
It may only need enough authority to carry encrypted packets between the device and an authenticated secure endpoint. That is a much narrower capability than allowing unrestricted local-network access, direct DNS, peer discovery or direct application traffic.
This is the central idea behind Frequency SafetyProtocol: usefulness should not automatically grant trust.
Three connectivity states instead of one trust switch
The first public prototype is being designed around three explicit connectivity states.
Trusted Wi-Fi
A known, user-approved network with sufficient evidence. Normal functionality is available according to the user's policy.
Protected Public Wi-Fi
An untrusted network is permitted to provide transport, but traffic is constrained to a protected path. The design direction includes authenticated encrypted transport, protected DNS, restricted local-network access and fail-closed behaviour when the required protection is unavailable.
Cellular Fallback
Cellular remains available when no acceptable Wi-Fi path exists. The objective is not to eliminate cellular networks; it is to use them when they are actually needed rather than by default.
A vision for secure access to legitimate free data
When people say “free data,” the important boundary is legitimacy. This project is not about bypassing carrier billing, defeating SIM authentication, accessing private networks without authorization or evading captive-portal terms.
The opportunity is to make better use of connectivity that is already intentionally offered: public Wi-Fi, libraries, universities, municipal and community networks, participating businesses, institutional networks, Passpoint-style roaming environments, user-approved hotspots and other lawful shared infrastructure.
If a device can safely move between those resources, a relatively small cellular allowance can become much more useful. Paid mobile data fills the gaps rather than carrying every byte.
The world is the infrastructure
The public version of Frequency SafetyProtocol is intended to use existing standards and existing free or shared resources rather than inventing another network.
That means using Android's supported network-management interfaces, public Wi-Fi infrastructure, secure tunnelling standards, protected DNS, local caching, efficient compression, Passpoint-compatible networks where available, and open protocols that can be independently inspected.
The design principle is simple: use the world's existing connectivity more intelligently instead of trying to recreate the Internet.
Security has to be the default, not an upgrade
The security model assumes that an unknown network is hostile transport until evidence supports something stronger.
Protected Public mode is therefore deliberately narrow. The network should be able to carry the protected packets we authorize and little else. If a protected tunnel is required and cannot be established, the intended result is no connection rather than an invisible downgrade to an unsafe path.
A familiar SSID is not sufficient proof. Previous success is not permanent authorization. If current observations contradict the evidence that justified a previous decision, authority should be reduced or withdrawn.
Connection success is not the same as trust. Tunnel establishment is not the same as endpoint authenticity. A security decision should preserve those distinctions.
Privacy without turning connectivity into surveillance
A system that remembers networks can easily become a location-history system. That is exactly the kind of accidental authority I want to prevent.
The intended design is local-first: minimal permissions, no telemetry by default, no centralized movement history, bounded local evidence, explicit retention controls and no cloud account requirement for the basic connectivity engine.
Where the platform permits it, the system can also reduce linkability through rotating identifiers and privacy-preserving network behaviour. But the public project should be precise about the claim: this can improve privacy and reduce tracking; it should not pretend to provide absolute anonymity against every network operator, destination, operating system or upstream provider.
Fast and lightweight instead of constantly scanning
Security software can become its own resource problem if it continuously scans, probes and analyzes everything around it.
Frequency SafetyProtocol is intended to take the opposite approach. The normal decision path should be deterministic, event-driven and small. Cached local observations should be reused when they remain valid. Active probes should be bounded. Evidence history should be capped. No on-device language model is required to decide whether a connection is permitted.
The goal is negligible idle CPU use, low battery impact, bounded memory and fast transitions between known states.
Compression should save bandwidth, not waste CPU
Compression is useful only when it actually reduces transferred data at an acceptable resource cost.
Already-compressed media, archives and encrypted payloads should generally pass through rather than being recompressed. Text, structured metadata, repetitive synchronization traffic and local receipts can benefit from lightweight compression or compact binary encoding. Repeated state can use deltas rather than retransmitting a complete representation. Reusable public assets can be cached locally where appropriate.
The optimization target is therefore not “compress everything.” It is move fewer bytes while doing less work.
A public implementation without publishing proprietary Frequency internals
I plan to create a public repository for this work, but it will not be a copy of the proprietary Frequency implementation.
The public project will recreate the connectivity-safety principles through a clean, independent architecture using public standards, Android APIs and open components. Frequency Core can remain behind its own boundary while the public project exposes simple, inspectable contracts for observations, policy decisions, effective network authority, drift and receipts.
That separation matters. The objective is to make the safety model open enough to inspect, test and improve without turning proprietary internal work into a dependency for people who simply want a secure connectivity tool.
Frequency as the assurance layer
The reason I am connecting this project to Frequency is not branding. The architecture maps naturally onto a recurring Frequency principle: authority should be specific to the action actually required.
A candidate network can be observed. Evidence can be collected. A policy decision can grant a narrow capability. The resulting connection can be observed again. If the network drifts away from the state that justified the decision, the authority can change. A receipt can record what was requested, what was permitted, what became effectively reachable and what was actually observed.
The public implementation can keep that contract simple:
Candidate
↓
Observation
↓
Policy Decision
↓
Effective Network Authority
↓
Connection
↓
Result / Drift
↓
ReceiptThat is enough to make the connectivity decision explainable without exposing the machinery behind the broader Frequency system.
What the first Android prototype should prove
The first stage is not automatic switching across every available network. It is proving the boundaries.
The prototype should demonstrate that an open or public network cannot become Trusted from its name alone; that contradictory observations downgrade authority; that Protected Public mode refuses unsafe fallback when its secure transport is unavailable; that the app does not require broad LAN discovery; that the basic decision engine works without telemetry or cloud inference; and that retained evidence can be cleared by the user.
Only after those properties survive testing should automatic switching become a promoted capability.
The larger vision
The long-term idea is broader than saving money on a phone plan.
Connectivity is increasingly treated as if access and trust must arrive together. They do not.
A network can be useful without being trusted. A device can accept transport without granting broad local authority. Shared infrastructure can be consumed without turning the user into a telemetry source. A small amount of paid cellular service can coexist with large amounts of legitimate free connectivity. Security and efficiency can reinforce each other instead of being treated as competing features.
Frequency SafetyProtocol is an attempt to make those boundaries explicit, enforceable and verifiable.
The vision is simple: more connectivity, less unnecessary cost, less unnecessary trust, and fewer reasons for people to trade privacy or security for access.