Executive Summary

XOPOZ is a GPS team tracking application that implements end-to-end encryption for location data with a zero-knowledge server architecture. This brief provides a transparent assessment of what XOPOZ protects against, what it does not protect against, and how to configure it for maximum security in sensitive operational environments.

Key Security Properties: GPS coordinates are encrypted on-device before any transmission. The server stores only encrypted data and does not possess decryption keys. There is zero dependency on Google infrastructure. Data deletion uses forensic-resistant byte overwriting.

Threat Model: What XOPOZ Protects

Threat Scenario	Protection Level	Mechanism
Server database breach	PROTECTED	Server stores only AES-128 encrypted blobs. No keys on server.
Network traffic interception	PROTECTED	HTTPS transport + payload already encrypted before transmission.
Google infrastructure surveillance	PROTECTED	Zero Google dependencies. No Play Services, Analytics, or Firebase.
Cross-team data leakage	PROTECTED	Independent 16-byte keys per team. Complete cryptographic isolation.
File system forensics after deletion	PROTECTED	0xFF byte overwrite before file unlink. Database overwrite with fake data.
Server-side location data selling	PROTECTED	Architecturally impossible. Server has no access to plaintext coordinates.
Cloud backup exposure	PROTECTED	Android backup explicitly disabled for all data domains.
Government subpoena of server data	PROTECTED	Encrypted blobs only. Compliant with subpoena but reveals no locations.

Threat Model: What XOPOZ Does NOT Protect

Transparency Notice: The following threats are explicitly out of scope. This is by design. No application can protect against all threat vectors. Understanding limitations is essential for operational security planning.

Threat Scenario	Protection Level	Explanation
Physical access to unlocked device	NOT PROTECTED	If attacker has the unlocked phone, they can see decrypted data through the app.
Malicious team member	NOT PROTECTED	Any team member with the key can decrypt all team positions. Vet your team.
Device compromise (malware/root)	NOT PROTECTED	Advanced malware with root access could intercept data in the app's memory.
Replay of encrypted payloads	NOT PROTECTED	Accepted: only possible by already-authenticated actors. Grants no additional access.
Historical data on compromised device	NOT PROTECTED	If a device with cached data is seized before deletion, cached data is accessible.

Operational Recommendation: If operating in high-risk environments, minimize the data retention period (Settings: 1 day), disable local save when not needed, and enable device encryption at the Android OS level. Consider using XOPOZ on a dedicated device that can be wiped if necessary.

Practical Security Scenarios

Scenario: Your organization's server is breached by a state actor

Result: Attacker obtains encrypted blobs. Without team keys (which are only on member devices), location data is unrecoverable. AES-128 encryption makes brute force computationally infeasible.

Scenario: A journalist's phone is confiscated at a border checkpoint

Result: If the phone is locked and using Android encryption, data is protected by the device passcode. If the phone is unlocked, the attacker can access the XOPOZ app and see decrypted data. Mitigation: Use minimum data retention (1 day), use device wipe capabilities, keep phone locked.

Scenario: A team member's credentials are stolen via phishing

Result: The attacker can authenticate to the server as that user, but GPS positions on the server are encrypted. The attacker cannot decrypt them without the team key, which is stored only on team members' devices. The stolen credentials alone do not grant location visibility.

Scenario: Network traffic is intercepted in a country with deep packet inspection

Result: HTTPS protects the transport layer. Even if HTTPS is broken through a government-issued CA certificate, the GPS payload is already encrypted with AES-128 before transmission. The attacker sees encrypted coordinates they cannot decrypt.

Scenario: An NGO needs to comply with a GDPR data subject access request

Result: XOPOZ implements all GDPR data subject rights. Data can be exported (GPX/CSV/JSON), modified, or permanently deleted with secure byte overwriting. No hidden backups exist. Android system backup is disabled.

Scenario: A device is wiped or the app is uninstalled

Result: The device's hardware-bound master key (Android Keystore) and the team keys it wraps are destroyed with the app. Without these keys, any encrypted data remaining on the server is unreadable to this device. The user account remains active for reinstallation, but the device must re-join each team via a fresh group ticket from an existing member.

No Google Infrastructure

A critical security property for many sensitive use cases is the absence of Google infrastructure in the data pipeline. XOPOZ achieves this completely:

GPS Positioning: Android native LocationManager API (not Google's Fused Location Provider)
Mapping: OpenStreetMap via OSMDroid library (or any custom tile server)
Push Notifications: Own polling architecture via WorkManager (not Firebase Cloud Messaging)
Authentication: Own JWT-based system with RSA-256 signing (not Google Sign-In)
Analytics: None. Zero telemetry to any third party.
Crash Reporting: None. Local logging only.
Advertising: None. No ad SDKs of any kind.

Compatibility: XOPOZ runs on GrapheneOS, CalyxOS, LineageOS, /e/OS, Huawei (HMS), and any Android 8.0+ device regardless of Google service availability.

Recommended Security Configuration

High-Security Profile (Journalists in Hostile Regions)

Set data retention to 1 day (Settings > Privacy)
Disable local save when not actively tracking
Enable Android device encryption (Settings > Security)
Use a strong PIN/password (not biometric alone)
Use XOPOZ on a dedicated device when possible
Share group tickets verbally, never via unencrypted messaging
Verify team members before sharing group tickets
Review and remove inactive team members regularly
If a device is compromised, recreate the team with a new key immediately

Standard Security Profile (NGO Field Teams)

Enable intraday tracking (working hours only)
Set data retention to 7 days
Ensure all team members understand the privacy controls
Export position data regularly for backup
Use push location permission to control sharing
Establish team protocol for device loss/theft (immediate team key rotation)

Key Technical Specifications

Component	Specification
GPS encryption	AES-128-ECB with 64-bit embedded IV, hardware-accelerated
Message encryption	AES-128-CBC with random IV, PKCS7 padding, CRC32 integrity
Master key	AES-256/GCM in Android Keystore (hardware-bound, non-extractable)
Team keys	16-byte AES, generated on-device, wrapped by master key, stored Base64 in private SharedPreferences. Exportable by design (shipped in group ticket for onboarding) — not hardware-bound
Team authentication	HMAC-SHA256 challenge-response (server verifies key possession, never sees the key)
Data deletion	0xFF byte overwrite + file unlink (forensic-resistant)
Android backup	Disabled for all domains (shared_prefs, database, files, cache, external)
Authentication	RSA-256 signed JWT with AES-CBC encrypted local storage
Server logging	GPS coordinates stripped to integers in all logs
Transport	HTTPS with certificate pinning

Open for Security Audit

XOPOZ welcomes independent security reviews from qualified cryptographers, digital security organizations, and human rights technology groups. We are transparent about our architecture and explicit about our threat model because we believe that trust in security tools must be earned through openness, not marketing claims.

For audit inquiries, responsible disclosure, or security questions:

tiri@tiritix.com

Xopoz

XOPOZ Security Brief