SECURITY & PRIVACY

We cannot read your messages even if we wanted to, because the keys never leave your device and no data touches our servers.

SecurityNet Threat Model

SecurityNet is designed to protect the confidentiality of message and file contents against interception, inspection, logging, moderation, or analysis by service providers, intermediaries, or third parties.

All communication is encrypted end-to-end and travels directly between participating devices, making message contents cryptographically opaque to network inspection.

Please note: SecurityNet cannot conceal the existence of network connections or protect against compromised endpoints, malware on user devices, or global traffic analysis by network operators.

View our statement on Regional Availability and Compliance.

Key Security Features

SecurityNet is engineered to protect your data and privacy. Here’s a quick overview of the key features that make SecurityNet one of the most secure communication platforms:

End-to-End Encryption: All messages and files are encrypted from the moment they leave your device, ensuring only the sender and recipient can read them — not even SecurityNet.
No Metadata Tracking: SecurityNet does not track activity or store communication metadata.
No Backdoors: SecurityNet contains no backdoors and does not provide special access mechanisms.
Encrypted Private Tunnel: Each connection uses a direct peer-to-peer encrypted tunnel wrapped in TLS 1.3.
Strong Authentication: Optional two-factor authentication (2FA) provides additional login security.
Secure, Private Access: Each SecurityNet ID is encrypted and not linked to personal identity.

End-to-End Encryption

One-time-use encryption key for every session
Never reused
Never stored
Never visible to any server
Destroyed after each connection
Wrapped inside TLS 1.3

World-class protection
Hides metadata
Hides DNS lookups (via built-in DoH)
To ISPs and censors, it looks like ordinary encrypted web traffic — there are no readable contents, no protocol markers, and nothing to inspect.

Only the sender and the recipient can decrypt anything. No one in between — not even SecurityNet.

Metadata Protection

SecurityNet is designed to minimise and compartmentalise metadata exposure.

Not stored centrally:

File contents
Message contents
Per-file delivery keys
Contact lists
Communication history
Connection logs
Session encryption keys

Stored in encrypted form (for licensing & identity control only):

Your SecurityNet ID (AES-encrypted at rest)
License entitlement information

No plaintext identifiers are stored.

No communication metadata is retained after session termination.

The connection mediator is designed not to retain communication activity after a connection has been established.

Our Policy — No Logs, No Metadata

SecurityNet never collects or stores metadata on any server.
No message logs, timestamps, or IP records are ever stored centrally — your activity remains private between peers.

For your convenience, SecurityNet keeps a local log on your own computer showing your connections and delivered files. This log is fully private, never transmitted, and can be deleted at any time.

Note: Your Internet Service Provider (ISP) or VPN may still see limited technical details, such as SecurityNet's IP address, connection times, or total data volume. This is standard for all Internet traffic and lies outside SecurityNet’s control.

In general Internet usage, a VPN may reduce the visibility of connection details to an Internet Service Provider by routing traffic through an encrypted intermediary. This is a general characteristic of VPN technology and operates independently of SecurityNet.

Your privacy within the SecurityNet network is designed to be fully contained — no external systems or servers store who you connected with or what you shared.

Click here for more info...

Network Visibility & Traffic Analysis:

An ISP can see that encrypted traffic is occurring and the destination IP address being contacted, but cannot see message content, identities, files, or encryption keys.

What is NOT visible:

Message content
Files or file contents
User identities
Contact lists
Encryption keys
Application-layer metadata

Encrypted sessions are wrapped in standard TLS (HTTPS), making SecurityNet traffic functionally indistinguishable from normal secure web traffic.

An ISP can see:

That encrypted data is being transmitted
The destination IP address
Session timing and data volume

But not:

Who you are communicating with (at the application level)
What is being sent
The contents of any messages or files
The meaning of the traffic

Optional Network Privacy Layer

SecurityNet protects message content, not network routing visibility.

If additional network-level privacy is required, users may choose to use a VPN or anonymising network as part of their general Internet configuration.

This can:

Reduce visibility of destination IP addresses from the local ISP
Mask the user’s public IP address
Add an additional network privacy layer

However, this shifts routing trust to the VPN provider and does not replace endpoint security.

Infrastructure & Server Model

SecurityNet’s architecture separates software ownership, website hosting, and mediator infrastructure.

SecurityNet is operated by a UK-registered company.
The public website is hosted in the United Kingdom. This website holds the Licensing and Payments functions as well as background operational functionality.
The VPS infrastructure used for session discovery and encrypted key exchange is hosted in Iceland.
The SecurityNet application itself is hosted on user PCs (or macOS devices).

The Connection Mediator:

Facilitates connection setup between authorised devices
Assists in encrypted session key exchange
Does not store messages or files
Does not retain encryption keys
Does not maintain central message history
Does not log IP addresses or session metadata

Once a session is established, encrypted communication flows directly between participating devices.

SecurityNet’s confidentiality model does not rely on trusting server infrastructure or hosting jurisdiction. Message contents remain protected through end-to-end encryption, and session keys are not stored server-side.

Even if any hosting provider were compelled to cooperate with authorities, encrypted message contents would remain cryptographically inaccessible.

Your SecurityNet ID

Your SecurityNet ID is your private address inside the system — chosen by you.

Must be unique (like an email address)
Stored only in encrypted form
One ID per device (for multi-user licenses)
Not tied to personal identity
Only shared with people you choose to communicate with

SecurityNet never stores your real name, phone, or personal identity.

Optional 2FA for the Desktop App

SecurityNet includes built-in Two-Factor Authentication for the desktop app.

Automatically generates a QR code
Works with Google/Microsoft Authenticator
Protects the desktop login itself
Stored locally (never uploaded)
No SMS, no email codes
Even if someone steals your laptop, the app remains locked

This protects your local device, not your cloud account — because we don’t use the cloud.

What We Do NOT Collect

SecurityNet does not collect:

Files
Messages
IP addresses
Your metadata
Device identifiers
Location data
Usage analytics
Server-side logs

The only data stored is:

Encrypted SecurityNet ID
License record (for purchase/support only)

Why "End-to-End Encrypted" is no longer enough

For years, “end-to-end encryption” has been presented as the gold standard for private communication.

Today, however, new regulatory approaches are shifting surveillance from the network to the device itself — especially on mobile platforms — through what is known as client-side scanning, undermining what that promise really means.

Modern “secure” messengers can be compelled to scan messages before encryption.
This turns your own device into a surveillance point.
True privacy requires that no central platform can be forced to perform such scanning.
SecurityNet is designed, by architecture, with no cloud, no central service, and no mobile OS dependency.

What is client-side scanning →

Why this matters — How to protect against client-side scanning →

Why It Matters

Most tools encrypt messages.
SecurityNet encrypts everything — the messages, the tunnel, the metadata, the DNS, and the very existence of your communication.

Whether you're:

coordinating sensitive business projects
sharing confidential documents
communicating privately inside restrictive jurisdictions
protecting family conversations
working in environments hostile to privacy

SecurityNet keeps your data private — from everyone.

Only sender and recipient ever see anything.
Not even us. Never us!

Why “end-to-end encrypted” is no longer enough

What is “client-side scanning”?
Client-side scanning means that messages, images, or files are examined on your own device before they are encrypted and sent.
Instead of trying to break encryption in transit, the software is required to look at the content in plain form first, using government-approved detection systems. Only after this inspection does encryption take place.
The result is that encryption still exists, but it no longer protects what the scanner decides to inspect or report. The surveillance happens upstream of the cryptography, inside the application itself.
Why cloud and mobile platforms make this enforceable.
Modern messaging platforms are typically:
- Centrally operated
- Cloud-dependent
- Distributed through controlled app stores
- Automatically updated
- Running on locked-down mobile operating systems
This creates a single point of legal and technical control. Governments can compel the platform provider or the OS vendor to modify the software, and those changes can be silently deployed to millions of devices.
When the operating system and the application update mechanism are both outside the user’s control, client-side scanning can be introduced universally and enforced by design.
Why peer-to-peer and desktop architectures make this far harder.
In a true peer-to-peer system:
There is no central service relaying or processing content
There is no cloud key authority
There is no mandatory update channel
There is no platform operator through which all traffic flows

On desktop systems, users also retain control over:
What software runs
What versions are installed
What network connections are permitted
Whether updates are accepted at all
Without a central control plane and without a locked execution environment, there is no practical way to impose a universal scanning layer across all endpoints.
How SecurityNet keeps the trust boundary at the user.
SecurityNet is architected so that:
- Encryption and decryption occur entirely on the user’s own machines
- Keys are generated and stored locally
- Communication takes place over direct, peer-to-peer encrypted tunnels
- No central service ever sees plaintext or controls the session
- No cloud infrastructure is required for message content
- No mobile operating system mediates or inspects the data path
This means the point of trust remains where it belongs:
with the communicating parties themselves.
There is no central platform that can be compelled to insert inspection logic at scale, and no cloud or mobile control layer through which such surveillance can be silently enforced.
A fundamental limit.
No application can protect privacy on an operating system that has itself become a surveillance platform.
SecurityNet’s design ensures that there is no central service, mobile control layer, or mandatory update infrastructure through which such surveillance can be universally imposed.

Protection Against Client-Side Scanning

Client-side scanning refers to software that scans data on a user's device for malicious content or surveillance. This can present a significant privacy challenge, especially when implementing privacy-focused solutions like SecurityNet.

Detection and Mitigation on Windows

1. Detecting Client-Side Scanning

Anti-Spyware Tools: Tools like Malwarebytes or Spybot Search & Destroy can detect spyware or surveillance software.
Process Monitoring: Use tools like Process Explorer to monitor running processes and identify suspicious activity.
Network Traffic Analysis: Software like Wireshark can identify unexpected data being intercepted or sent to unknown locations.

2. Eliminating Client-Side Scanning

Sandboxing: Tools like Sandboxie isolate apps to prevent scanning or surveillance from affecting the system.
Encrypted Communication: Encrypting communication data (even locally) can prevent scanning tools from analyzing it.
System Hardening: Regularly update security settings, use firewalls, and limit admin access to protect against scanning software.
Blocking Surveillance Tools: Use Host Intrusion Prevention Systems (HIPS) and behavioral detection to block unwanted surveillance tools.

3. Additional Measures

User Education: Regular audits of installed software, use of tools like Autoruns, and disabling Windows telemetry can limit exposure.
Virtual Machines: Running sensitive tasks in a VM isolates them from potential surveillance or scanning on the host system.

Detection and Mitigation on macOS

1. Detecting Client-Side Scanning on macOS

Activity Monitor: Just like Windows’ Task Manager, macOS has Activity Monitor, which allows users to see running processes. Users can monitor for any unfamiliar or suspicious processes that might be scanning or intercepting data. If you’re running Wine64, it’s important to monitor the Wine processes as well, as malware could try to inject itself into Wine applications.
Little Snitch: Little Snitch is a macOS application that monitors network traffic. It can be configured to alert users when unknown apps or processes try to send data to external servers, which is useful for detecting unexpected surveillance or data scanning behavior.
Network Traffic Analysis: Like on Windows, using tools like Wireshark or tcpdump can help analyze network traffic. If your app's data is being sent to unexpected locations or intercepted, these tools can help spot it.
EtreCheck: This is a diagnostic tool for macOS that checks for common issues like malware, performance bottlenecks, or privacy concerns. It won't specifically scan for "client-side scanning" but could flag suspicious processes or software running on the system.

2. Mitigating Client-Side Scanning on macOS

Sandboxing: macOS has a built-in App Sandbox that restricts what apps can do. This is useful for preventing apps from accessing sensitive parts of the system or scanning files without permission. However, Wine64 doesn't inherently utilize macOS's sandboxing features, so this might require some additional configuration or wrappers to limit Wine's permissions.
Encrypted Communication: Encrypting communication on the client-side remains one of the best defenses against client-side scanning. If data is encrypted, it cannot easily be scanned or intercepted. Make sure all data transmitted via SecurityNet (whether on macOS or Windows) is securely encrypted end-to-end.
Security Updates: macOS is known for its regular security patches, so make sure the system is updated to the latest version. While not a direct defense against client-side scanning, keeping the OS up to date ensures that known vulnerabilities are patched.
Anti-Malware Solutions for macOS: While there are fewer targeted malware threats on macOS than on Windows, there are still some options for detection. Products like Malwarebytes for Mac or Intego Mac Internet Security can help detect malware and surveillance software on the system.
Privileged Access Management: Wine64 allows Windows apps to run on macOS, but it's essential to ensure that the Wine process itself doesn't gain unnecessary system-level privileges. Limiting the permissions that Wine or your app has on macOS can help reduce the risk of client-side scanning tools gaining unauthorized access.

3. Configuring Wine64 for Privacy

Since you're using Wine64 to run SecurityNet on macOS, here are a few specific tips to help prevent potential client-side scanning:

Limit Wine’s Network Access: When running Wine64, you can configure its network settings to restrict which resources it can access. By default, Wine allows full access to the network, but you can lock it down using macOS’s firewall settings or Wine’s internal configuration.
Control Permissions via macOS Security: macOS allows you to control app permissions through the System Preferences > Security & Privacy settings. While Wine64 doesn’t directly integrate with macOS's security settings, you can limit access to certain system resources (like the camera, microphone, or file system) to prevent potential scanning tools from accessing sensitive information.

Please note: SecurityNet does require access to the file system so you can see the SecurityNet folders and your data.

4. Virtual Machines on macOS

Running SecurityNet in a virtual machine (VM) on macOS can isolate it from the main system, adding another layer of protection. If you configure a VM with macOS, it can be locked down to prevent scanning software from running. You can use Parallels Desktop or VirtualBox to create an isolated environment for Windows applications, which could also help mitigate client-side scanning.