Should packages declare what survives offline?

As a Linux desktop maintainer, I’m increasingly frustrated by applications that install locally but quietly depend on a vendor account, remote API, telemetry service, or cloud-controlled feature. The package is on disk, but the useful part may not be under the user’s control.

Our existing package metadata describes software dependencies, while AppStream helps present applications to users; neither gives a clear standard for which functions work without internet access, login, telemetry, or third-party services. I’d like repositories to require an “offline capability” declaration: fully offline, offline core with optional online features, login required for some functions, or cloud-dependent core functionality.

That creates verification and maintenance work for projects and distributions, and “core function” can be subjective. Should this metadata be mandatory, community-maintained, or left to individual projects? Disagree, share Linux applications with hidden cloud dependencies, or suggest a better standard.

The useful version would need to be capability-level, not a single yes/no flag. A network permission only says the application can use the network; it doesn’t say whether that access is required for editing, syncing, activation, or telemetry. I’d want this attached to a release and tested where possible.

Mandatory sounds attractive, but stale declarations could be worse than missing ones. Services change and projects may not notice that an online check became essential. I’d prefer versioned metadata with a named attester, an update date, and a clear distinction between project-provided information and distribution verification.

This is valuable at the point of installation because users make a durability judgment, not just a dependency judgment. The trade-off is that a prominent warning may punish an otherwise useful optional sync service. The interface should show what is unavailable offline, rather than treating all network use as suspicious.

Flatpak permissions could provide useful evidence, but permission to reach the network is not proof that the network is necessary. A declaration should also say what data leaves the machine and whether disabling telemetry changes functionality. Otherwise we get a reassuring label that answers the wrong security question.

I’m not convinced repositories should certify this. “Core function” is a product decision, and a distribution-maintained label can quickly become an argument over whose definition wins. Make the field available and require projects to document it upstream; let users and distributions add warnings when the claim is contradicted.

Community annotations seem like the practical starting point, provided they retain provenance and release scope. “Works offline” should mean more than launching: can I open existing data, create new data, export it, and recover if the service disappears? Those are the tests I’d actually trust.