Alera Privacy Policy
In this policy
1. About Alera
Rewe Labs develops and operates Alera, an Android emergency-safety application. Rewe Labs is an independent software-development brand. Alera is designed to communicate emergency information to trusted people selected by the user.
This policy explains how Alera and this website handle information. Alera is under development. Standard in-app SOS controls and the home-screen widget are not yet available, and Alera is not ready to rely on for emergencies.
2. Information Alera accesses and uses
- Your configuration: a recognizable emergency display name, optional own phone number, chosen trusted phone numbers and email addresses, the selected Gmail sender account address, authorization status, language and safety/retention settings. These direct communication and preserve the intended destinations for each incident.
- A selected contact: if you use the optional system contact picker, Alera reads only the phone number and display name you select. Manual entry remains available. The app does not request broad address-book access or upload your address book. Picker access is temporary; only an explicitly saved destination enters the protected configuration.
- Emergency and test information: available location coordinates, accuracy and capture time; microphone audio when enabled and permitted; emergency time and status; battery percentage and charging status; incident identifiers and delivery/retry results. These support alerts, evidence, recovery and local history.
- Google authorization: the selected sender identity and a short-lived token used to send through Gmail, as explained in section 5.
Alera uses this information for the disclosed safety and user-initiated test functions, local protection, delivery and recovery. The current version has no advertising, analytics or third-party crash-reporting service. Emergency data is not sold or used for advertising, behavioral profiling or AI model training. It does not read the SMS inbox or call logs, or collect camera/video evidence.
3. Location, including after a restart
During a real emergency or a location test you explicitly start, Alera may obtain location with the Android permissions you grant. It may use a sufficiently recent qualified location already available on the phone, request new fixes and send useful updates. Location can be approximate, earlier or unavailable. Last-known information carries its actual capture time; Alera does not present message arrival time as location capture time.
During an ongoing real emergency, location may continue while the app is not on screen. After a normal reboot, Alera may attempt to restore location-only operation for the same already ongoing emergency when Android allows recovery, required protected local state is accessible and location permissions and settings remain valid. Android 10 and later require a separate background-location grant for this automatic recovery path. Android 8–9 have no separate background-location grant.
This is not idle or passive tracking: background-location authority is limited to continuity of that ongoing emergency, not advertising, geofencing or background Test Mode tracking. A restart does not create a new emergency. No new location is collected for an incident after its accepted end. Microphone recording does not restart automatically after reboot. Android restrictions or unavailable state can prevent recovery.
4. Emergency microphone audio
If you enable audio evidence after the in-app disclosure and grant microphone permission, Alera may record during a real emergency with valid live emergency operation, or during an explicitly started audio test. Outside these states it does not listen in the background or maintain a secret rolling recording.
For an ongoing real emergency, audio may continue in the background without a fixed elapsed-time cutoff. It is captured in short segments, encrypted locally and queued for progressive Gmail sending. Android microphone/privacy controls, higher-priority microphone use, permission loss, runtime failure, unsafe storage, encryption failure or thermal/resource conditions can pause or stop capture. Recoverable conditions may allow the same incident’s audio to resume after the necessary checks; continuous or complete recording is not guaranteed.
Alera does not bypass Android privacy indicators or user/system stop controls, and is not a call-recording service. It does not collect caller identities or call logs to manage microphone availability. Reboot never automatically restarts audio; restoring microphone operation requires an eligible visible user interaction.
An authenticated, accepted emergency end stops new capture. Valid information captured before the end may still be saved or sent. Ending, marking safe or reporting a false alarm does not by itself delete evidence or recall alerts.
5. Google account access and Gmail sending
You explicitly select a Google account during setup. Google’s account-selection flow identifies the intended Gmail sender; Alera retains the selected account address as protected local configuration. The returned identity token is not retained by Alera. Gmail authorization is a separate step.
Alera requests only the Gmail sending scope, https://www.googleapis.com/auth/gmail.send, to send emergency and clearly labelled test email on your behalf. It does not request Gmail mailbox-reading, mailbox-modification or full-mail access. It does not read your inbox, received messages or existing sent mail.
Emergency email may contain your display name, optional own phone number, emergency date/time and status, available location/map link and coordinates, accuracy/capture time, battery/charging information and playable audio attachments. Google/Gmail processes these outgoing messages and the authorized sending request. The short-lived access token authorizes that request; it is not included in recipient messages.
Alera keeps access tokens transient in memory, does not persist access or refresh tokens, does not store your Google password and does not request a server authorization code or offline server access. Google’s authorization services may supply another short-lived token silently while a valid grant permits it. If explicit authorization is needed, email remains queued and Alera asks you to reconnect later; it does not automatically open consent during a real emergency.
Pending incident email stays bound to the sender selected for that incident. It is not silently moved to another Google account. You can revoke Alera’s access in your Google Account’s third-party connections settings. Revocation prevents further authorized Gmail sending until you reconnect; it does not erase already sent mail or local incident data.
Alera limits Google user-data use to the user-facing account selection and sending functions described here. It does not use Google user data for advertising, sale, unrelated profiling or training generalized AI models. Its use and transfer of information received from Google APIs is intended to comply with the Google API Services User Data Policy, including its Limited Use requirements. This statement is not a claim of Google verification or approval.
6. What leaves the device and who receives it
- SMS: your carrier and the trusted phone recipients process compact emergency/test messages, which may include emergency time/status and location coordinates. New location-bearing SMS uses a plain coordinate line without a map URL. Critical SMS is in English; later useful location/status updates may send further messages. One part is preferred, occasionally two; carrier charges may apply per part. SMS is not end-to-end encrypted.
- Gmail and email recipients: Google/Gmail and the email services/people you choose process emergency/test email and attachments. Alera uses BCC for trusted email destinations to avoid exposing their addresses to one another. The current message layout places the sender address in the To header and trusted destinations in BCC, so a sender copy may also be received. Outgoing audio is a normal playable .aac attachment, not Alera’s encrypted local file, and does not require an Alera key. App-controlled Gmail transmission uses HTTPS/TLS; this is not an end-to-end encryption guarantee.
- Device services: Android and Google services used for account authorization and location operate under their own controls and policies. Choosing to open a map link uses the recipient’s map service.
The current architecture has no developer-operated emergency-data backend. Rewe Labs does not receive or store a server copy of your emergency location, audio or messages through the app’s normal emergency channels. This does not mean all data stays on your phone: carriers, Google/Gmail, recipient mail providers and recipients necessarily handle transmitted information.
Choose recipients carefully and make sure they expect these messages. They may retain, forward or otherwise use received information. Their processing, and Google’s or carriers’ retention, is outside Alera’s local deletion control; this policy makes no promise about their storage periods.
7. Local storage and protection
Alera stores sensitive configuration, emergency location/audio and delivery content in app-private storage with authenticated AES-GCM encryption backed by Android Keystore keys. Minimal operational records, such as opaque incident/trigger identifiers, timestamps and delivery/error state, support recovery without including sensitive content in those records. Sensitive data and tokens are excluded from app diagnostic logs.
Emergency audio is not written to disk in plaintext or merely encoded form, including temporary send files. Capture, encoding and preparation of playable attachments use bounded memory or streaming. Only encrypted emergency audio is persisted locally. Sensitive emergency/configuration storage is configured to be excluded from automatic Android cloud backup and device-to-device transfer; this is not a cloud-backup feature or a guarantee about every device implementation.
Device authentication protects sensitive configuration, emergency ending and destructive actions. Encryption and these controls reduce risk but cannot guarantee absolute security, survival of device failure or access after loss of cryptographic keys.
8. Retention and local deletion
Each real incident records its own retention choices when it starts. Global changes apply to future incidents; changing an existing ended incident requires an explicit protected override. Automatic retention does not delete evidence while the real emergency is still ongoing.
Evidence with confirmed off-device send
The default is 7 days. Options are 1, 7 or 30 days, or keep until manual deletion. The clock starts at the later of the incident’s end and the first authoritative send success for that evidence. Gmail acceptance can count as send success for retention; it does not prove recipient delivery or reading.
Evidence without confirmed off-device send
The default is do not auto-delete. Options are no automatic deletion, or 7, 30 or 90 days after the incident ends. Queued, blocked, failed and uncertain sends are not treated as confirmed. Selecting a timed policy requires a warning and authentication because it may remove the only known copy. A missing trustworthy end time delays automatic deletion rather than starting a guessed timer.
Lightweight incident history
The default is 90 days after the reconciled incident end. Options are 30 days, 90 days, 1 year or keep until manual deletion. Lightweight history is not a hidden long-term copy of emergency audio or sensitive location/profile content.
Eligible automatic cleanup follows the authorized incident policy and may wait for Android execution and active sending to settle. Manual deletion of real evidence or an incident requires fresh Android device authentication and confirmation. Deletion retires affected remaining local delivery work; an active or uncertain send may already have reached a provider. Minimal deletion/recovery records may remain where needed to prevent deleted work from being replayed.
Local deletion cannot reliably erase or recall information already sent to Google/Gmail, carriers, recipient providers or people. Logical removal from app-controlled storage does not promise physical overwrite of flash memory. No-auto-delete does not protect against uninstall, clear-storage actions, device loss/failure or key loss. Saved configuration remains until you change/remove it or remove app data; old incident snapshots keep their original destinations until incident data is deleted under the applicable rules.
9. Your choices
You can review Android permissions, microphone/location privacy controls, background reliability, destinations and the connected sender in setup/settings. Declining or revoking a capability can reduce protection. Protected configuration changes are unavailable during an ongoing real emergency. Your existing incident’s sender and destinations are not silently replaced by later settings.
You may end an emergency through the protected flow, change eligible retention settings or delete local evidence/incidents through their authenticated controls. These are separate actions. Revoking Google access, disconnecting for future incidents, ending an incident or uninstalling does not recall external messages. Tests require explicit initiation and send clearly labelled real test messages to enabled destinations.
10. Practical and security limits
Alera cannot guarantee rescue, uninterrupted operation, complete evidence, delivery, reading or exact location. Android/device-maker rules, permission changes, network/carrier/provider availability, quotas, battery exhaustion, storage, temperature, force-stop and shutdown can prevent work. Nothing runs while the phone is powered off. System indicators or notifications can reveal activity; invisible recording is not promised.
This static website has no account login, forms, analytics, tracking scripts or browser-storage preferences, and its code sets no cookies. It receives no app incident/location/audio uploads. The public website uses Cloudflare Pages for hosting and delivery. Cloudflare may process technical request information, including IP addresses, requested pages, request times and browser/device information, to deliver the site, operate its infrastructure and protect against abuse. Service and security information may be available to Rewe Labs through Cloudflare’s dashboard. This website-request processing is separate from Alera’s emergency-data handling; Cloudflare hosting is not an emergency-data backend. Cloudflare’s processing is described at https://www.cloudflare.com/privacypolicy/. This policy does not promise a specific Cloudflare log-retention period.
11. Privacy contact
For privacy questions or requests about Alera or this website, contact Rewe Labs at [email protected].
If you contact us by email, we receive your email address and the information you choose to include so we can respond. This correspondence is processed through Gmail and is separate from the app’s automatic emergency channels and local retention settings. Please avoid sending sensitive emergency information unless necessary for your request.
12. Updates to this policy
This policy is available at https://rewelabs.com/alera/privacy/. Future changes will update the date and explain material changes. New uses of Google user data require updated disclosure and consent before that new use.
This policy does not replace contextual in-app disclosures or Android/Google permission choices. The English and Arabic versions describe the same data practices.