SECURITY & PRIVACY

We cannot read your messages even if we wanted to. Message and file contents are encrypted end-to-end, and SecurityNet does not store copies on its 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.

Message and file contents are encrypted end-to-end between participating devices. Communication is direct device-to-device where possible, with SecurityNet's infrastructure assisting connection establishment when required.

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: Messages and files are encrypted on your device before transmission, ensuring only the intended participants can read them — not even SecurityNet.
No Metadata Tracking: SecurityNet does not use communication metadata for tracking, advertising, profiling, or analytics.
No Backdoors: SecurityNet contains no backdoors and does not provide special access mechanisms.
Encrypted Private Tunnel: Communication between participants is protected by an encrypted tunnel, with direct device-to-device connections used where possible.
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

SecurityNet protects message and file contents with end-to-end encryption between participating devices.

Communication content is:

Encrypted before transmission
Protected while travelling between devices
Decrypted only on the receiving device
Not stored as a readable copy on the mediator
Not accessible to SecurityNet

Encryption keys are:

Generated for the communication process
Not retained by the mediator
Not available to SecurityNet as a means of reading your communications

Network observers may still be able to see that encrypted traffic is taking place, together with ordinary network-level information such as IP addresses, timing and data volume.

SecurityNet protects the contents of your communication. Network-level privacy can be strengthened separately by using a VPN.

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 SecurityNet IDs are stored centrally.

The connection mediator does not intentionally create or retain application-level activity logs.

Our published Privacy Verification evidence documents the mediator's logging configuration and the checks used to verify this behaviour.

View our Privacy Verification evidence →

Our Policy — No Central Activity Logging

SecurityNet does not intentionally create or retain central application-level logs of your communication activity.

Messages and files are not stored on the connection mediator, and SecurityNet does not maintain a central history of who communicated with whom or what was exchanged.

For your convenience, SecurityNet maintains a local Activity Log on your own computer showing communication activity such as file transfers. This information remains under your control and is not transmitted to the mediator as a central activity record.

Network-level visibility is different. Your Internet Service Provider, VPN provider, or other network infrastructure may still observe ordinary connection information such as IP addresses, timing and data volume. This lies outside SecurityNet's application-level logging controls.

Our mediator configuration and logging controls are documented in our published Privacy Verification evidence.

View our Privacy Verification evidence →

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 use standard TLS (HTTPS), so the traffic appears as encrypted web traffic at the network layer.

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 from destination services
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 runs on users' own Windows or macOS computers.

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 intentionally create or retain application-level connection activity logs

Where a direct connection can be 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 a hosting provider were compelled to cooperate with authorities, the infrastructure is not designed to hold readable copies of message or file contents.

View our Privacy Verification evidence →

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

Your SecurityNet ID does not need to contain your real name, phone number, or other real-world 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 or centrally retain:

Files
Messages
Contact lists
Your metadata
Location data
Usage analytics
Communication data for advertising or profiling
Central communication activity logs

Data retained for identity, licensing and support includes:

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, proposals for client-side scanning demonstrate that protecting data in transit does not necessarily protect it from inspection on the device itself.

Client-side scanning can inspect messages or files before they are encrypted for transmission.
This can turn the endpoint itself into a potential inspection point.
End-to-end encryption therefore protects only one part of the communication path; endpoint behaviour matters too.
SecurityNet is designed without cloud message storage and without dependence on a mobile operating-system messaging ecosystem.

What is client-side scanning →

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

Why It Matters

Encryption protects content. Privacy also depends on what happens around that content.

SecurityNet is designed to reduce the amount of communication data exposed beyond the participating devices — by avoiding cloud message storage, central communication histories, and application-level activity logging on the mediator.

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 was designed around a simple principle: your private communications should remain under the control of the people participating in them — not become stored content on someone else's communication platform.

Private. Direct. Under Your Control.

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.