PATROLGRID · E2EE INTERNAL TESTING

Team messages are encrypted for invited devices

This notice applies to the separate PatrolGrid E2EE beta service, not the original, non-encrypted PatrolGrid service. Their teams, invitations and history are separate: older data is not automatically migrated or retrospectively encrypted. Opening the encrypted app does not silently create or join a team. Area Search is a separate app, not a PatrolGrid feature.

End-to-end encrypted team content

Team names, shared locations, speeds, directions, shared pins and recent trails are encrypted on participating devices using Messaging Layer Security (MLS). Invited devices decrypt that content. The separate UK-hosted PostgreSQL relay stores and forwards encrypted messages; it does not hold the team's content-decryption keys.

No participant account is required. A chosen display name is not a verified identity. Protect invitations and admit only people you trust: encryption cannot prevent an invited participant from copying or sharing what they see.

No invisible administrator view

The encrypted service's admin dashboard has no silent session viewing or joining function. Its protected dashboard shows resources and aggregate connection counts, not decrypted team maps, names or pins. The separate legacy support view does not provide access to encrypted sessions.

What the service can still see

E2EE does not hide all metadata. The relay needs device public keys and identifiers, team membership and roles, membership changes, connection information, timestamps and encrypted message sizes to run and protect the service. HTTPS also protects traffic in transit. These are separate protections: TLS alone is not team E2EE.

Maps and navigation are outside team E2EE

Maps, road-name lookup, street search and directions involve provider requests. Providers can receive connection information and relevant map areas or route coordinates. Where PatrolGrid's own routing endpoint is used, our server and route engine can read the origin and destination. These requests are not encrypted as team messages. Coverage, geocoded addresses and road matching remain estimates.

The browser console loads geographic map tiles automatically for a live team unless you turn them off. OpenStreetMap receives your IP address and viewed map area. No invitation, team key or tracking credential is sent to that tile provider. Turning tiles off clears the console's in-memory map cache; ordinary browser HTTP caching may remain. Map display does not enable team location sharing.

Location and paired Watch choices

Device location sharing needs a separate choice and operating-system permission. Locked-screen tracking needs its own opt-in and the appropriate iOS location permission. Leaving a team stops future sharing; it cannot erase information already seen or copied by another participant.

The experimental paired Watch companion receives decrypted team map information from the iPhone through the operating system's paired-device connection, not MLS private keys. Watch sharing is a separate opt-in. Required visibility, pairing, connection and team-binding checks can stop forwarding; stopping cannot recall information already delivered or copied. Current map snapshots expire within fifteen seconds. Navigation is handled by the iPhone and requires its GPS and routing permission. Physical background/locked delivery remains subject to beta acceptance testing.

Team and device retention

Teams expire twelve hours after creation or may be ended sooner. Ending or expiry removes active encrypted delivery history. Recent delivery history is also bounded by age, event count and size while a team is active: it is not a permanent route archive. Remaining team, membership and admission metadata is normally removed during scheduled maintenance twenty-four hours after scheduled expiry, not immediately when a team is ended early. Downtime or delayed maintenance can extend removal.

Device credentials last twenty-four hours. Expired device records remain while referenced by retained team or admission records. Device withdrawal acknowledgements are retained for at least twenty-four hours and longer where those references or protected recovery requirements remain.

Your local data and deletion choices

In Settings, “Withdraw this device from all teams…” revokes the saved device's service access, ends teams it created and removes its access to other teams. This does not automatically erase protected local device keys or encrypted recovery records. The separate “Forget local ended-team data…” action, when available, removes that team's local recovery state. Neither action recalls information already delivered or immediately removes backups.

Contact admin@patrolgrid.net about retained service metadata. We will explain records needed for recovery or existing team references and the backup replacement limits below. Never send private keys, credentials, invitations or other people's locations.

Encrypted recovery backups

The E2EE beta now takes a transaction-consistent logical database backup nightly at 02:00 UTC. It separately seals the database and required private runtime inputs with authenticated archive encryption. Team message content remains end-to-end encrypted inside those backups. Archive encryption is an additional protection, not a replacement for team E2EE.

We retain the seven most recent successful daily recovery copies as they become available. A failed run does not replace a good copy. The last acknowledged off-host copy may be kept longer during failures, and the initial qualification copy is retained until deliberately retired. Deletion from the active service therefore does not immediately remove backup data.

Encrypted copies are saved automatically to a private folder on the separate cPanel web host, outside website folders. Before export the VPS authenticates both archive seals and signs their exact hashes. cPanel verifies the signature and every copied file before acknowledging the copy. It holds no backup decryption key and cannot open the archive.

The copy and health check runs every fifteen minutes without requiring the operator's Mac. Failures and backups older than thirty hours are reported by the cPanel host by email. Network, hosting, scheduling or mail failures can delay copying or notification; this is not an always-available or guaranteed-Inbox alert service.

The archive recovery key remains separately protected in the operator's Mac login Keychain, with cloud synchronisation disabled. The Mac is not needed to create, copy or monitor backups, but its key is needed for a restore if the server key is lost. Existing private Mac recovery-test copies remain; their automatic copy job is disabled. Loss of both key copies can prevent archive recovery.

The separate whole-server backup arrangement remains unchanged: one successfully verified weekly archive is replaced only after a new backup succeeds. Failures can extend retention. Team content remains encrypted, but that older whole-server archive is not separately archive-encrypted.

Recovery has security and availability limits

An old backup cannot prove which devices were revoked or withdrew later. Restored data is isolated by default. Without trusted latest security history and new serving authority, restored team access is refused rather than silently revived. A failure may therefore require a longer outage or fresh team setup; verification of a backup does not promise automatic resumption. Loss of a device's protected keys can prevent recovery of its content. Loss of both the server key and the separate Mac/login Keychain can prevent opening the archive. Logical deletion is not forensic erasure.

Questions and feedback

Contact admin@patrolgrid.net. Include your build, device and reproduction steps, never secrets or other people's precise locations. PatrolGrid is a test product, not an emergency service. Stop somewhere safe before using its controls.