Skip to main content

Security

An overview of how REITrack handles your data at rest, in transit and on-device.

Data in Transit​

Sync runs over HTTPS to REITrack Cloud. There is no way to point the app at another destination, so location data cannot be redirected to a third party.

TLS trust anchors​

REITrack's HTTPS chain validation accepts two trust sources, either of which is sufficient:

  1. System CAs that ship with Android - the normal public web (Let's Encrypt, DigiCert, etc.)
  2. In-app imported CA added via Settings -> Authentication & Headers -> Client Certificate (mTLS) -> Trusted Server CA. One slot, trusted only by REITrack.

User-installed device CAs (from Android Settings -> Encryption & credentials) are not honored, so malware or a coerced profile that plants a CA in the device store can't intercept REITrack's sync.

Mutual TLS (mTLS)​

Credentials at Rest​

Authentication credentials (Basic auth, Bearer tokens, custom headers) are stored using Android's EncryptedSharedPreferences with AES-256-GCM encryption. Credentials never leave the device except as HTTP headers sent to your configured endpoint.

Sensitive values (Authorization, Bearer, Token, API-Key) are automatically masked in log exports.

Location Data at Rest​

Location history is stored in a local SQLite database on the device. The database is not encrypted. This means someone with physical access to a rooted device could read the data.

The database is not accessible to other apps (standard Android sandboxing).

Encrypted Backups​

REITrack can produce a single password-encrypted archive of your full dataset (locations, settings, geofences, credentials) for off-device storage or device migration. See the Backup & Restore guide for the user-facing flow. The relevant security properties:

  • Cipher: AES-256-GCM, chunked at 1 MiB of plaintext per chunk. Each chunk's GCM tag binds the file header as additional authenticated data, so any flip in the header (KDF parameters, salt, nonce prefix) invalidates the very first tag.
  • Key derivation: Argon2id with 64 MiB memory, 3 iterations and 1 lane on standard devices; 32 MiB on devices flagged as low-RAM by Android. The salt is 32 bytes from SecureRandom, fresh per backup.
  • Password floor: 12 characters, with a strength meter that enforces ~50 bits of entropy (passwords with sequential runs or fewer than 4 distinct characters are capped).
  • No recovery: forgotten password means an unreadable file. There is no escrow, recovery code or developer override.
  • Credential handling: the credentials REITrack uses to authenticate with REITrack Cloud are extracted from EncryptedSharedPreferences and written as plaintext inside the encrypted container. They are protected by the backup password, not by the device's hardware-backed key. The blast radius is whatever those credentials can do in the cloud account they belong to, which Firestore rules scope to that one user's own data. On restore the credentials are re-wrapped under the destination device's key.
  • mTLS: the user-imported Trusted Server CA (public cert bytes) is included so a self-signed server stays reachable after restore. The mTLS client certificate is not backed up by design - the private key lives in the Android KeyChain (often hardware-backed) and cannot leave the source device. Re-import the .p12 on the destination device after restore.
  • Format independence: the on-disk format is FOSS (BouncyCastle, no Tink/Google dependency) and stays stable independently of the in-app EncryptedSharedPreferences implementation.

What REITrack Does Not Do​

  • No analytics, telemetry or crash reporting
  • No advertising SDKs or tracking pixels
  • No data shared with the developer or third parties
  • No personal identifiers, device IDs or advertising IDs collected

For the full privacy policy, see the Privacy Policy.