Privacy & Governance by Design
Purpose of This Document
This document explains how our technical architecture functions as a governance model at EXTRA SAFE, and why this matters in an environment where encryption alone no longer guarantees meaningful privacy.
Our goal is to describe structural facts about our system: how we design identity, keys, data flow, and retention, and what we intentionally do not possess as a result.
This document explains how EXTRA SAFE’s architecture shapes governance and privacy in practice. It is intended for readers who want to understand how the system is designed to limit platform power, rather than rely on policy or promises.
1. Privacy Risks Are Increasingly About Platform Power
Historically, privacy in communication systems focused on protecting message content through encryption.
Today, many of the most significant risks persist even in encrypted environments. These risks arise from platform-level authority, including the ability to:
define or verify user identities
collect and retain metadata
accumulate long-term behavioral records
centralize encryption key control
modify data handling practices over time
Governance, in this context, refers to who can technically do what, regardless of stated policies or intentions. We designed EXTRA SAFE to address this layer of risk directly.
2. Identity Without Personal Identification
We do not require users to provide personal identifiers to communicate on EXTRA SAFE.
Specifically, our app does not collect:
phone numbers
email addresses
device IDs
identity verification or account recovery tied to real-world identity
Instead, our users operate via locally generated cryptographic identities, similar in structure to key pairs used in the Ethereum network. These identities are created on the user's device and are not registered, verified, or linked to a real person by our platform.
As a result:
1.We do not maintain an identity database
2.Our platform cannot associate activity with a real-world individual
3.Identity exists only as a cryptographic capability, not as an attributed profile
Anonymity is therefore not an optional feature, but a direct consequence of how we define participation in our system.
3. Local Key Generation and User-Controlled Cryptography
Encryption keys in EXTRA SAFE are generated and stored exclusively on user devices.
Our platform:
does not generate private keys
does not store or escrow encryption keys
cannot decrypt message content
cannot impersonate users or sign actions on their behalf
This design removes our platform from the trust boundary of private communication. Control over cryptographic material, and therefore over identity and authorship, remains with the user at all times.
From a governance perspective, this limits our authority not by policy, but by cryptographic impossibility.
4. Device-to-Device Communication Architecture
We use a device-to-device (peer-to-peer) communication model for calls and in-call messaging at EXTRA SAFE.
Communication flows directly between participating devices rather than being routed through centralized servers for storage or processing. Our role is limited to coordination and connection establishment, not message custody.
This architecture ensures that:
there is no central location where conversations accumulate
communication content is not stored in transit
retrospective access to conversation histories is structurally prevented
By avoiding centralized aggregation points, our system reduces exposure to surveillance, misuse, and mass data compromise.
5. Absence of Long-Term Data Accumulation
We do not treat communication data as a persistent resource at EXTRA SAFE.
Chats are deleted by default based on user-defined timers. Once expired, our platform does not retain communication data. There is no long-term storage of:
message histories
call records
social graphs
Because data does not accumulate over time, it cannot later be repurposed for monetization or secondary use. There is no historical dataset whose sensitivity increases as it grows.
This is a structural characteristic of our system, not a configurable policy.
6. Privacy Enforced by Design Constraints, Not Policies
Many platforms rely on internal rules, compliance programs, or contractual commitments to limit data use.
We reduce reliance on such mechanisms at EXTRA SAFE by designing systems in which meaningful personal data is neither required nor retained. Privacy outcomes are determined primarily by our architectural constraints:
minimal identity surface
local key ownership
peer-to-peer communication
automatic data erasure
As a result, privacy does not depend on continued organizational restraint, future leadership decisions, or evolving business incentives.
7. How Technical Constraints Align Platform and User Interests
Because we cannot access or exploit user communication data at EXTRA SAFE, our platform has no structural incentive to expand data collection or extend retention.
There is no technical pathway for behavioral profiling, targeted advertising, or secondary data monetization. This aligns our operational incentives with user privacy by default, rather than by promise.
In governance terms, reducing capability reduces temptation.
8. Considerations Regarding GDPR and Regulatory Scope
We designed EXTRA SAFE so that:
no personal data is required to use our service
our platform does not act as a traditional data controller for communication content
This architectural approach raises legitimate questions about how specific regulatory frameworks, including GDPR, apply to systems that intentionally avoid collecting or processing personal data.
Rather than asserting definitive legal conclusions, we engage with data protection officers and privacy experts to review and evaluate these implications. Our approach is factual, transparent, and open to external scrutiny.
What we can state without qualification is that minimizing data collection reduces regulatory exposure and compliance complexity.
9. Governance as an Outcome of Architecture
At EXTRA SAFE, governance is not implemented through oversight layers or enforcement mechanisms. It emerges from our system design.
By limiting identity attribution, removing key custody, avoiding centralized storage, and preventing long-term data accumulation, we constrain our own control. These constraints apply consistently, regardless of context or intent.
Privacy, in our model, is not a feature, it is a condition enforced by our system's structure.
Final Provisions
This document reflects the current architectural design of EXTRA SAFE at the time of publication.
As our system evolves, we commit to:
maintaining architectural privacy constraints as a core principle
avoiding the silent expansion of platform authority
engaging with independent experts to review governance implications
Privacy by design is not a static claim but an ongoing responsibility for us. Governance, when embedded in architecture, remains enforceable even as technologies, regulations, and organizations change.