Why UnoLock is not fully open-source (FOSS)

UnoLock’s security model depends on a hosted, active server component to enforce protections that cannot be achieved with purely client-side or self-hosted software. This is a threat-model-driven design decision: the enforcement layer exists to keep large-scale brute-force and abuse attacks impractical, and to make access-control guarantees consistent over time.

Hosted enforcement is part of the security model

Eliminating large-scale online guessing and enumeration attacks requires a server that can enforce constraints across sessions, devices, and regions. In particular, a hosted enforcement layer can:

• Enforce rate limits and throttling
• Detect abuse patterns across sessions
• Apply lockouts and progressive delays
• Coordinate cryptographic access controls
• Maintain invariant guarantees across time and geography

Why this cannot be optional

If the full server implementation were freely deployable by anyone, those protections would be optional or trivially weakened. An attacker could simply run a modified server that disables safeguards, removes throttles, or alters enforcement logic—making brute-force and enumeration attacks practical again.

That would undermine one of UnoLock’s core guarantees: that access controls are enforced consistently, not merely suggested by client code.

Open source vs. verifiable security

Not being fully FOSS does not mean UnoLock asks for blind trust. Instead, UnoLock emphasizes verifiability over forkability:

• Client-side cryptography is inspectable
• Threat models are published (see Threat Model)
• Security architecture is documented (see Technical Details)
• Deploy-time transparency artifacts are published (see Transparency)
• Users can verify the shipped client against production (see Client Source Access)
• Cryptographic protocols are standard and peer-reviewed

Users do not need to trust UnoLock’s intentions—they can verify UnoLock’s behavior. What is intentionally restricted is the ability to re-deploy or alter the enforcement layer in ways that would weaken security guarantees.

Why this tradeoff exists

Pure FOSS works well for:

• Offline tools
• Libraries
• Local encryption utilities
• Protocol specifications

It breaks down for systems where:

• Online access control matters
• Abuse resistance is part of the threat model
• Security depends on coordinated enforcement
• Guarantees span time, devices, and regions

A helpful analogy (Signal)

A useful comparison is Signal: while Signal publishes open-source client and server components, the security and abuse-resistance properties people associate with “using Signal” depend on a coordinated, operated service that enforces policy at scale. Running a modified or separate server can be educational, but it does not give you the same network, the same protections, or the same guarantees your contacts rely on.

UnoLock’s restriction is motivated by the same underlying reality: when abuse resistance and invariant enforcement are part of the security model, the critical question is not only “can the code be forked?” but “are protections enforced consistently for the system you and others actually use?”

UnoLock falls squarely into the second category. Making the server fully forkable would not increase user safety—it would reduce it.

What UnoLock commits to instead

• No hidden cryptography
• No proprietary crypto primitives
• No security through obscurity
• No undisclosed data collection
• No server-side access to user data or keys

The server exists to enforce constraints, not to see content. That distinction is central to the design.

Bottom line

This is not an ideological stance against FOSS. It is a threat-model-driven design decision. And importantly: the architecture already supports this explanation. This is not a retrofitted justification—it’s documentation of the actual security model.