Whera uses the Messaging Layer Security (MLS) protocol (RFC 9420) for group key management in Enhanced Privacy mode — the same IETF standard being adopted for next-generation secure messaging. Location data is encrypted with XChaCha20-Poly1305, which provides authenticated encryption with 192-bit nonces to eliminate nonce-reuse risks. All network communication uses TLS 1.3 (RFC 8446) with FIPS 140-validated cryptographic modules. Keys are stored in the iOS Secure Enclave or Android Keystore and never leave your device.

Yes. Every connection between the Whera app and our backend requires TLS 1.3 (RFC 8446) — the latest and most secure version of the Transport Layer Security protocol. Older TLS versions (1.2, 1.1, 1.0) and unencrypted HTTP connections are rejected outright. All API cryptographic operations use FIPS 140-validated modules. Only two cipher suites are permitted: TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384. This applies to all traffic: location updates, authentication, push notification payloads, and API calls. There is no scenario in which your data travels unencrypted between your device and our servers. HSTS is preloaded with a 2-year max-age to prevent downgrade attacks. TLS 1.3 also provides forward secrecy by design, meaning that even if a key were somehow compromised in the future, previously recorded traffic could not be decrypted. This is the transport-level encryption that protects all users regardless of which privacy mode their group uses — it's the baseline, not an option.

Yes. Whera's infrastructure runs on AWS, which uses AWS-LC (AWS LibCrypto) — the first open-source cryptographic library to achieve FIPS 140-3 validation with post-quantum algorithms included. AWS-LC powers the TLS stack across the AWS services Whera relies on, including CloudFront, our API load balancers, and KMS. Beyond FIPS validation, AWS has deployed hybrid post-quantum key exchange on these services. This means TLS connections to Whera's infrastructure use a combination of classical elliptic-curve cryptography (ECDH) and ML-KEM (Module-Lattice-based Key-Encapsulation Mechanism), a NIST-standardized post-quantum algorithm. The hybrid approach means that even if one algorithm is eventually broken, the other still protects your data. This matters now, not just in the future. “Harvest now, decrypt later” is an active threat — adversaries can record encrypted traffic today and attempt to decrypt it once sufficiently powerful quantum computers exist. By using AWS's post-quantum TLS, your data in transit to Whera's servers is protected against both current and future cryptographic threats.

Forward secrecy (also called perfect forward secrecy) means that even if someone recorded all your encrypted traffic and later compromised a server's private key, they still could not decrypt those past sessions. Whera provides this at two independent layers. Layer 1: TLS 1.3 is mandatory on every connection, and TLS 1.3 requires forward secrecy by design — every session generates unique ephemeral keys that are discarded after use. This protects all users on all plans. Layer 2 (Enhanced Privacy mode only): MLS (RFC 9420) provides continuous application-layer forward secrecy, where keys advance with every operation using tree-based key ratcheting. Combined with post-compromise security, this means that after a compromised device is removed or rotates its keys, future location updates become secure again even if the attacker had full access to the device's prior key material. Whera's MLS implementation uses an HKE (Historical Key Epoch) dual-key schedule that enables decryption of historical location data within your tier's retention period while preserving forward secrecy beyond that window. Key rotation is triggered by member removal, device removal, security resets, and periodic rotation.

Yes. Whera's encryption is built on open, publicly audited standards and libraries — not proprietary cryptography. The MLS protocol is defined in RFC 9420, developed openly by the IETF, and implemented by well-tested public libraries. XChaCha20-Poly1305, our symmetric cipher, is a widely reviewed standard used across the industry. We deliberately chose established, battle-tested cryptographic primitives rather than inventing our own. Our implementation of these protocols is private today, but we may open-source it in the future.

Yes. The Whera mobile app pins against the SPKI (Subject Public Key Info) hash of the API certificate, with both primary and backup pins. This means the app will only communicate with servers presenting the expected certificate, preventing man-in-the-middle attacks even if a certificate authority is compromised or a malicious root certificate is installed on the device. Certificate pinning applies to all API connections from the mobile app. The web-based share link viewer uses standard TLS trust (browser certificate store) since it runs in a browser context where pinning is not practical.

Each Whera app installation generates a unique ECDSA P-256 keypair on first launch. The private key is stored in the Secure Enclave on iOS or StrongBox / TEE on Android. The private key is non-exportable and hardware-bound — it literally cannot be extracted from the device, even by the device owner or by Whera. Keys automatically rotate on reinstall, “sign out everywhere,” or password change. This hardware-backed key is what makes features like DPoP token binding possible: every API request from your device is cryptographically signed by a key that only your physical device possesses.

Every authenticated API request is individually signed by your device's hardware-backed private key using DPoP (Demonstrating Proof-of-Possession, RFC 9449). The signature covers the HTTP method, URL, timestamp, and a server-issued nonce that rotates on every response. This means a stolen access token is useless without the hardware-bound private key — it cannot be replayed from another device. Standard bearer tokens (what most apps use) can be intercepted and replayed freely. DPoP comes from the OAuth 2.0 world and is used by banks for high-security transactions. Additionally, if a refresh token is ever used twice (indicating potential theft — both the real user and an attacker tried to use it), Whera immediately revokes the entire session and requires re-authentication plus device re-attestation.

Whera makes it very difficult. Every location update receives a composite trust score and a verified flag. The score factors in device attestation level, DPoP validity, key storage type, behavioral signals, and GPS accuracy. A spoofed GPS position from a rooted phone running a mock location app gets flagged automatically. Beyond GPS validation, Whera runs behavioral anomaly detection — impossible travel detection (you can't be in Seattle and Tokyo 5 minutes apart), rapid geographic region switching, and IP anomaly checks. These are controls adapted from banking and fintech fraud prevention. Family group admins can view trust details in member settings, so if a teen is using a location spoofing app, it won't go unnoticed.

Yes. Whera uses platform-provided device attestation to verify that the app is running on a genuine, unmodified device. On iOS, this uses App Attest to confirm the app binary is authentic and the device has not been jailbroken. On Android, Play Integrity API verifies the app is a legitimate install from Google Play running on a device that passes integrity checks. Attestation isn't just checked at login — Whera verifies continuously: at first launch, through weekly re-attestation, and on-demand when suspicious behavior is detected. Devices are assigned a trust level (full, standard, reduced, or untrusted) that directly influences what the device can do.

Whera hashes passwords with Argon2id — the algorithm recommended by both OWASP and NIST, configured with 64MB memory cost. Argon2id is memory-hard, which makes GPU and ASIC brute-force attacks economically impractical. Older algorithms like bcrypt require only 4KB of memory per attempt — an attacker with a GPU can run millions of guesses in parallel. With Argon2id at 64MB per attempt, the same attacker runs out of memory after a handful.

Whera runs entirely on Amazon Web Services (AWS), which holds SOC 1/2/3, ISO 27001, ISO 27017, ISO 27018, and PCI-DSS Level 1 certifications. We build on that foundation with our own security architecture following Zero Trust principles (NIST SP 800-207): no implicit trust based on network location, mutual TLS for all internal service-to-service communication, and just-in-time privilege elevation with no persistent admin roles. FIDO2/WebAuthn is required for all privileged accounts — SMS-based MFA is prohibited for admin access. We also deploy monitored decoy accounts that trigger alerts if accessed — a deception-based defense common in sophisticated enterprise security.

Whera's security program is built against requirements drawn from SOC 2 Type II, ISO 27001/27002, ISO 27701 (privacy management), NIST Cybersecurity Framework 2.0, PCI-DSS, FIPS 140, GDPR, CCPA/CPRA, HIPAA, COPPA, and more. We've consolidated requirements from over 20 compliance frameworks into a unified set of controls that governs everything from encryption and access control to logging, vulnerability management, and incident response. These aren't retrofitted — they're built into the architecture from the first line of code.

Not yet — and we want to be transparent about that. We are building to SOC 2 Type II and ISO 27001 standards from day one, and our infrastructure already meets the technical requirements of both frameworks. Formal certification involves an independent audit over an observation period, which we're planning to complete after launch. In the meantime, our security controls, policies, and audit results are documented internally and available for review by enterprise customers under NDA.

Yes. We perform automated vulnerability scanning on every code change using static analysis (SAST), dependency scanning, and container image scanning. Critical findings block deployment — no exceptions. We also plan to conduct annual penetration testing by independent third-party security firms with a comprehensive scope covering our API, mobile applications, network services, and encryption implementation. Findings are triaged by severity with strict remediation timelines: critical vulnerabilities within 7 days, high within 30 days.

Whera maintains formal security policies covering information security management, access control, encryption, incident response, data classification, change management, and business continuity. Key commitments include: all data encrypted at rest with AES-256 and customer-managed keys, all network traffic encrypted over TLS 1.3 with no fallback to older protocols, least-privilege access with no shared accounts, multi-factor authentication required for all production access, centralized audit logging with 365-day retention, real-time monitoring and alerting. Our security principles start with “privacy by architecture” and “zero trust for user data” — meaning we design systems so that even we can't access what we don't need to.

We have a documented incident response process with severity-based response times. If a data breach occurs, we are committed to notifying affected users within 72 hours as required by GDPR, and without unreasonable delay under CCPA. We operate on an “assume breach” security philosophy — our systems are designed so that even if a component is compromised, the blast radius is limited. In Enhanced Privacy mode, a server breach would yield only encrypted data that we cannot decrypt.

Every vendor that touches user data is evaluated for security posture. Critical vendors like AWS and Stripe are required to hold SOC 2 or ISO 27001 certifications. We maintain data processing agreements with all sub-processors as required by GDPR, and we document exactly what data each vendor can access. Our mapping provider (Stadia Maps) receives no user data at all — only map tile requests. Payment details are handled entirely by Stripe, Apple, or Google. We never store card numbers or payment credentials on our own systems.

No. The Whera website does not use Google Analytics or any third-party tracking scripts. There are no pixel tags, no advertising trackers, and no behavioral profiling. The only cookies the site uses are strictly functional — a session cookie if you sign in and a language preference cookie — neither of which tracks your behavior or is shared with third parties. A privacy-first app demands a privacy-first website.

Our maps are powered by Stadia Maps and the open-source MapLibre SDK — a deliberate choice driven by privacy. Google Maps, Mapbox, and Apple Maps send user viewport data, search queries, and interaction patterns to their providers, building profiles about where you look and what you search for. Stadia Maps does the opposite: they don't collect user telemetry, don't use cookies, don't store request logs beyond 30 days, and their SDKs are fully open source. When you view a map in Whera, no personal data is sent to the map tile provider — it simply serves the images that make up the map. Your location data never touches Stadia Maps; it stays entirely within Whera's own infrastructure (or encrypted on your device in Enhanced Privacy mode). Using a privacy-respecting mapping provider is part of the same principle that runs through every decision we make: if we're asking you to trust us with your location, every part of the stack should earn that trust.