Privacy

Neither RideSentinel Lite nor RideSentinel Pro asks you to create an account. What the app reads off your screen — fares, pickup and trip distances, neighbourhoods, rider details — is processed on your phone and written to a database on that phone. It is not uploaded, not to us and not to anyone else, with three exceptions, each of which you have to choose yourself: live traffic and driver-network demand sharing in Pro, both described below, and, only if you join the optional driver network, a daily count of how many offers the app read (see the Driver network section). Uninstalling the app deletes it. Earnings, shifts and odometer readings you log stay on the phone in the same way, and are only shared when you export them yourself: a CSV or PDF you send, or a Pro backup you upload.

The accessibility service binds only to the driver apps RideSentinel supports — Uber, Lyft, Bolt, inDrive, FREENOW, Grab and DiDi. It does not read your other apps, your messages or your keyboard. When the text of an offer card can be read, the apps read that text. When it cannot, the app takes a screenshot of the card, reads it on your phone and discards the image immediately: it is never saved and never sent anywhere. RideSentinel Lite only reads: it never taps, swipes or acts in another app. It keeps only the numbers it read and its verdict on your phone.

Apart from live traffic, road reports and the driver network’s daily count, which each have their own section, there are exactly three ways ride data can leave your phone, and all three are switched off until you switch them on yourself: the AI advisor and backups, described in the next section, and driver-network demand sharing in Pro, which is off by default and described in its own section below. If you leave all of these alone, nothing about your rides ever reaches a network.

The version of RideSentinel Lite on Google Play sends nothing to us unless you turn on error reports in Settings or send one by hand (see Crash and error reports). It has no account, no upgrade offer and no driver network: the optional driver-network account is offered only by the apps you download from our website.

AI advisor (Pro). It runs one of two ways, depending on your licence. With Pro Subscription it runs on our servers and needs no key: Pro sends the request to our server, which passes it to Google’s Gemini API on our own key and hands back the answer. Our server keeps a count of your requests per day, never the request or the answer. You can switch to your own Gemini key instead, and Pro Lifetime always uses your own key: the request then goes straight from your phone to Google and never through our servers. Either way, the request is a summary of your logged offers — fare, pickup and trip distance, effective $/hour and $/km, the dropoff postal area, and what you decided — sent when you ask for a review. If you also turn on auto-tune (off by default), Pro sends a similar summary by itself on a schedule, weekly unless you change it: how your accepted rides compared with what they actually paid, with the fare, pickup distance and dropoff postal area of the weak ones. It never sends full addresses, rider names or live offers. Nothing is sent until you run a review or turn auto-tune on.

Backups. If you turn on backup upload, Pro sends a zip of your local database to our server. That zip contains your ride data in readable form. It is stored on our server with owner-only file permissions, the twenty most recent backups per driver are kept, and older ones are replaced. Since Pro 4.47 the zip also holds the times of each ride it contains: accepted, at the pickup, trip started and ended, or cancelled, and your answers to unconfirmed rides. These times carry no places, and your online and offline times stay on the phone. Backup upload is off by default and requires you to configure it.

Uber data import. The “Download your data” archive you import from Uber is parsed on your phone and stays there.

If you link a Tesla, our broker exchanges the OAuth code with Tesla and holds the refresh token server-side, encrypted. The app receives battery level, range, odometer and the outside temperature the car reports, nothing else. Permission to send climate commands is asked only if you switch on an automation, in a separate step. RideSentinel uses it only for that automation and never sends lock, charging or driving commands. Unlinking discards the token.

Weather. When this automation runs as you go online and your car is not already awake, your phone asks Open-Meteo (open-meteo.com) for the outside temperature. It sends a location rounded to about 10 km (0.1 degree), only when this automation runs, straight from the phone: our server is not involved. Open-Meteo handles the request under its own terms.

Schedules. When you set a schedule, your phone sends an approximate area (rounded to about 10 km) so our server can check the weather at the scheduled time; it is deleted when you remove your schedules. Our server then asks Open-Meteo for the temperature of that area, and wakes the car only if it will heat or cool it. It keeps the last 20 scheduled runs (time, what was done and the temperature seen), without the area, for up to 90 days. If your phone has not confirmed your schedules for 14 days, our server deletes them and the area. Disconnecting the car deletes the schedules, the area and these runs.

Commands. Climate commands go to Tesla through our server only for an automation you switch on, sent from your phone when you go online or started by our server at a time you schedule: starting the climate at the car’s own temperature setting to heat or cool it, defog (only when heating), the driver’s seat heating and steering-wheel heating (only when heating, and only if you switch them on in the automation), and stopping them all after the time you chose. Our server signs them with RideSentinel’s Tesla key, which never leaves the server, and wakes the car only to start the climate.

What is kept. Our server logs each command’s kind and outcome only (for example “start ok”), never the car’s VIN, a token or a place. For seat and steering-wheel heating it also keeps a short-lived record of which heaters your car supports and which side the driver sits on, kept 7 days. Your phone keeps the last 20 runs, with the temperature seen and what was done.

If you connect a car that is not a Tesla, you sign in with your car maker’s account on a page run by Smartcar, not by us. Smartcar gives our server an identifier for your connection. When you pull a reading, our server asks Smartcar for your battery or fuel level, range and odometer, plus the make, model and year to label the car, and nothing else: no location, no commands. Your phone keeps only an encrypted session with our server. Disconnecting ends that session and removes your connection at Smartcar. Smartcar processes this data in the United States under its own privacy policy.

Live traffic is off unless you turn it on in Pro’s settings, and Pro asks you to confirm first. When it is on, for each offer Pro sends our server the pickup and dropoff addresses printed on the card, your approximate position (rounded to about 100 metres) and your licence key. Our server asks Google’s Routes API for the current driving time of each leg and returns only those times and distances to your phone. Our server keeps the addresses in memory for at most three minutes, so that the same card is not looked up twice, and never writes them to disk or logs. It counts lookups per licence per day to cap costs. Google processes the addresses and position under its own terms. Turning live traffic off stops all of this at once.

Speed-limit warnings are off unless you turn them on in Pro. While they are on, Pro asks our server for the speed-limit map tiles around you. Each request names only a map tile, a square of roughly two kilometres a side, never your position: it reveals the area you are driving in, not where you are within it. It carries your installation’s registration, as other app requests do. Our server builds each tile from OpenStreetMap data. In the regions we prebuild (currently Canada, the United Kingdom, Australia and the Gulf states: the United Arab Emirates, Saudi Arabia, Qatar, Kuwait, Bahrain and Oman), tiles are prebuilt on our server from OpenStreetMap extracts it downloads every week: they are refreshed weekly and considered current for fourteen days from the map data’s date. Elsewhere, at the edges of those regions, or when a prebuilt tile is out of date, the tile is fetched through the public Overpass service, as a fallback, naming the tile’s area and nothing about you, and considered current for seven days. It does not record which tiles an installation asked for; it only counts requests per installation, in memory, to limit the load. Your speed and the warnings stay on your phone. Turning the warnings off stops the requests. Map data © OpenStreetMap contributors, under the Open Database License.

What is sent. Demand sharing is off by default. It starts only if you turn it on in Pro, under Explore or in the settings, and Pro asks you to confirm first. While it is on, Pro sends our server a few coarse facts about each new offer, in small batches: the pickup postal area (only the first part of the postal code, the first three characters in Canada, never the address), the local hour, the product, the fare and the effective $/hour each in $5 bands, and the id of your city. The request carries your installation’s registration, as other app requests do. It never carries the address, the exact time, your position, rider details or your licence key.

What our server keeps. For each offer, the postal area, the product, the $/hour band, the city id and the time it arrived rounded to five minutes, with keyed fingerprints (HMACs, made with a key only our server holds) of your installation and of your network address (your IPv4 address, or the /64 block of an IPv6 address), never the raw values. The hour and the fare band are checked and then discarded. Records expire after three hours; the hourly counters that limit how much one installation or one network can send expire after two.

What is shown. Anyone can see a city’s busy areas, in Pro and through our public API. An area is shown only when at least five installations on five different networks shared offers there in the last two hours, and each installation counts once, however many offers it sent. Only banded figures are shown: the number of drivers as 5–9, 10–19 or 20+, the mix of products in tens of percent and a typical $/hour in $10 bands. Nothing shown identifies an installation, a driver or an offer.

Switching it off. Turning sharing off stops all sending at once and empties the queue on your phone, so offers that were waiting are never sent. What was already sent expires on our server within three hours.

Pro can show a report button over Uber for accidents, traffic, construction, closures, speed checks and wrong directions. Each report is saved on your phone and repeated in Uber’s own report panel. Reports you make with Uber’s own button are saved on your phone too.

Only if you choose Share do reports leave your phone: the report type, the place rounded to about 10 metres, the time, your speed and heading, and a code for your install that we cannot turn back into it. Reports older than about a day are never sent. Never your name, rides, fares or riders. We use them to warn drivers about trouble on the road. They are deleted after 30 days, and you can delete any of yours from My reports at any time. Turning Share off stops all sending at once.

The apps record crashes, freezes and errors so they can be fixed. By default those reports stay on your phone: nothing is sent until you open Error reports in the app’s settings, read what is stored, and choose to send it. You can delete them there too. You can instead switch to automatic sending in the same place; the reports already stored are sent when you do, and the app tells you so before you confirm. Feature diagnostics — reports of a feature that failed quietly rather than crashing — are kept with the others on your phone; with automatic sending they are included only if you also turn that switch on.

A report is scrubbed on your phone before it is stored or sent: money amounts, distances, street addresses, postal codes, coordinates, email addresses, phone numbers and rider names are replaced with [redacted], in every language the apps support. What is left is the error type, the stack trace, your app version, your Android version, your phone model and maker, and a random install ID.

Reports you send yourself reach our own server first. With automatic sending, reports go to our server and also straight from your phone to Sentry, our error-tracking provider, scrubbed on the phone as described above; Sentry’s library attaches a random identifier of its own to what it sends. Anything our server forwards to Sentry is scrubbed a second time on the way out, and your install identifier is replaced with an unsalted SHA-256 hash of it, truncated. The raw install identifier does not reach Sentry.

Our own copy of the reports is kept for thirty days and then deleted automatically. That copy does hold the raw install identifier. Your IP address is not stored with it; it is used only to rate-limit the endpoint in memory.

A licence record. Your licence key, the plan you bought, its status and term, the date it was created, your email address if the payment gave us one, the Stripe customer and subscription references, which features the plan unlocks, the install identifiers you have activated it on (up to three devices), your referral code with a count of referrals, and which version of the home page you saw, if you bought through it (see The home-page experiment). Licence records are encrypted at rest and kept for ten years, which is a storage limit, not a licence term.

A free trial. If you start a free trial, the app sends a one-way code made from an identifier Android gives this app (not your phone number, IMEI or serial) so a phone can start a trial only once; we keep only a further one-way code of it. The trial itself is a licence record like the one above, for that one installation, ending after seven days. The code is kept for two years. When a trial starts, your network address, as a keyed one-way code, is counted for three days to limit trials per network.

Download counters. A number per day and per build — Pro or Lite — of links issued and files served. No licence key, no install identifier, no IP address. Kept for ninety days.

An app registration. When an app first talks to us it registers this installation and we store a random install ID for it, which app it is, its version, your phone model and maker, when it registered, when it last called, and a hash of the secret it uses — never the secret itself. It lets us cut off a single installation that misbehaves. It is not tied to your name, and deleting the app and reinstalling makes a new one. We keep this record while the installation is in use, for example to send error reports, and delete it when you ask (see Delete your RideSentinel data).

AI request counts. Only for subscriptions using the AI advisor on our servers: a number per licence per day, for the daily limit, kept for three days. Never the content of a request or its answer.

Error reports. As described above: thirty days.

Driver-network demand. Only if you turned demand sharing on in Pro: the coarse facts of each offer and keyed fingerprints of your installation and network, as described in Driver-network demand. Kept for three hours.

Feedback and tips. The notes, feature requests, bug reports and tips you send, as described in Feedback, feature requests, bug reports and tips. Kept for up to three years, or until the team deletes them.

Backups. Only if you turned them on: the twenty most recent uploads per driver, kept until you replace or delete them.

Access logs. One line per request to our server: the method, the path without its query, the status, the time taken, and your network address shortened to an IPv4 /24 or an IPv6 /48. Never request bodies, headers or query strings. Kept only in the server’s rotating log files (at most about 30 MB, oldest lines overwritten first), usually a few days, for security and debugging.

Purchases are handled by Stripe. We never see your card number. Stripe passes us your email address, the plan and a payment reference so we can issue and support your licence key. We also write your licence key into Stripe’s record of your purchase (the payment or the subscription, and your Stripe customer), so it can be found again if you lose it. The key is also placed in the payment description, which appears on the receipt Stripe emails you and on your invoices. Stripe processes that payment under its own privacy terms.

Every Pro licence carries a six-character referral code. Following a link that contains one stores the code in your browser for thirty days and sends it with your purchase, so the driver who shared it can be credited with the referral. The code is not a licence key and unlocks nothing. Nothing about the person who referred you is shown to you, and nothing about you is shown to them beyond a count and the plan and date. Clear your browser storage and the code is gone.

With your permission, this website uses Google Analytics and PostHog (US Cloud) to measure visits, campaign tags, selected link clicks, and two actions: starting a checkout (which plan, never payment details) and joining the iPhone waitlist (that it happened, never the address). Google Analytics may store cookies; PostHog uses an identifier held only in memory. Session recordings and automatic form capture are off. Only the home page, the Get the app page, Feedback, What’s new, Explore, Privacy and Terms are measured, each by its path and campaign tags only. The download and payment-result pages are excluded, and we never put email addresses, licence keys or payment references in our events. These providers receive network information such as your IP address when your browser connects. Declining stops them loading. While we compare four designs of the home page, the home page view and the clicks and actions above also record which version you were shown (A1, A2, B1 or B2), and only after you agree.

A separate optional choice enables the Meta pixel on the landing page for advertising measurement. Meta receives page views, contact-link clicks, page URLs and network and device information, and may use cookies to associate that with a Meta account. Automatic advanced matching is off; we send no email contents and no customer contact details. Declining stops the pixel loading.

Change or withdraw either choice through Privacy preferences in the footer; withdrawal stops future collection. Your language, theme, consent choices and any referral code are stored in your browser only, and never reach us. The Feedback page also keeps a random voter ID there, which is sent with your votes (see Feedback, feature requests, bug reports and tips). The download page also keeps the licence key it showed you after your purchase, with its plan, until you choose Forget on this browser; the key reaches us only when you use it on that page. Your browser also keeps which version of the home page you were assigned, under the key ridesentinel_landing_v2, so you see the same one on each visit, and the day your last visit was counted, under ridesentinel_landing_view, so a visit is counted at most once a day. Both carry a date, and either is ignored and replaced once it is more than 13 months old. The version reaches us only as The home-page experiment, below, describes.

The home-page experiment. We are comparing four designs of the home page (A1, A2, B1 and B2) to learn which one leads to purchases; your browser is given one at random. Two things are recorded for this, whatever you chose above. If you buy Pro, the version of the home page you saw is recorded with your purchase: in your licence record and in the Stripe checkout. And our server keeps an anonymous count of visits per version, per day: your browser sends the version once a day, and the server adds one to that day’s count. Neither uses a cookie. Neither identifies you: the version names a page design, not a person, and the count keeps only the version and the day, never your IP address, an identifier or your browser details. Your network address is used in memory only, to limit how often a visit can be counted, and is not written to our access logs.

What we collect. When you send a video to The Sentinels (sentinels.ridesentinel.app), we receive the video file exactly as you send it, what you tell us about the incident (what kind, when, where, your description), and, only if you fill them in, your name, email, phone number and address. We also record which version of the permission you agreed to and when, and a one-way fingerprint of your IP address that we use to limit abuse. You can leave every personal field empty and stay anonymous.

Why. To pass footage of dangerous driving to the police and other authorities, and to publish selected videos on our social media, such as TikTok, under the licence you give us when you send the video. Before publishing we may blur faces and licence plates.

Who sees your details. Your name, email, phone and address are never published and are stored encrypted. We may give them to a police force or other authority that receives your video, so they can contact you as a witness. People with the share link see the video, what kind of incident it is, when and where it happened and your description, never who sent it.

Where it is stored. The original file is kept unchanged on our server, with its SHA-256 fingerprint, so that it can serve as evidence. A copy is stored with Cloudflare R2, which delivers playback for us as a processor.

Withdrawal and deletion. The private link you get after sending lets you withdraw the video at any time: the share link stops working and it comes off our public channels. Videos already published, or given to an authority, cannot be recalled from where they went. To have the original and your details deleted from our server, write to privacy@ridesentinel.app.

From the website. When you send a note from the Feedback page, we receive what kind it is (a feature request or a bug report), its title and details, the language of the page, and your email address only if you give one. We also store a one-way fingerprint of your network address (your IPv4 address, or the /64 block of an IPv6 address), made with a key only our server holds; the address itself is never stored. To count one vote per idea, the page keeps a random voter ID in your browser’s local storage and sends it with each vote; our server keeps only a keyed fingerprint of it. Your network address is also used, in memory only, to limit how often notes and votes can be sent.

From the app. A note sent from the app carries a keyed fingerprint of your installation’s registration (see What our server stores), the app version, the platform and your language, and never an email address. A bug report can carry a diagnostics attachment only if you tick it, and you can see exactly what it contains before you send it: codes, counts, times and log lines that passed an allow-list. It never contains text read from your screen or your notifications, and never your location. It is scrubbed like an error report, so rider names, numbers and addresses are removed. It stays on our own server, is not sent to Sentry, and is deleted after thirty days.

Tips. A tip is local advice for one city. It can be sent from the app only, never from the website, and carries what any note from the app carries, plus the id of the city it is for; it never carries an email address. Its title and its text become public, in the app and on the Explore page of this website, only after the team approves them; the team may edit them first, and email addresses, phone numbers and street addresses are removed from what is shown. Nothing public says who sent a tip, and public tips can be voted on like ideas.

What becomes public. Only feature requests and tips that the team approves are public. A feature request appears on the public ideas board only as a title and summary the team writes or edits, with its status, its vote count and the team’s reply; a tip appears as described above. Email addresses, phone numbers and street addresses are removed from all public text. For feature requests and bug reports, the details you wrote are never shown; your email address is never shown; and nothing public says who sent a note. Bug reports are never public.

How long we keep it. A note, tips included, is kept for up to three years, and the team can delete it sooner. Your email address is deleted as soon as the note is closed (done or declined) or merged into another one. The fingerprint that records your vote on an idea is kept as long as the idea; the per-network marker that limits votes is kept for two days.

Why. To decide what to build next, to fix what is broken and, if you gave an email address, to answer you. None of it is used for advertising, and none of it is sold.

Deletion. To have a note you sent deleted, write to privacy@ridesentinel.app with what it said and roughly when you sent it; if you gave an email address, write from that address.

What we keep. When you join the iPhone waitlist on the Get the app page, we store your email address, the language of the page and the date you signed up, with a random unsubscribe code. To spot a second sign-up we compare a keyed fingerprint of the address. We also record when you agreed and which version of this wording you saw. We do not store your network address: it is used in memory only, to limit how often sign-ups can be sent. If you allowed analytics, the fact that someone signed up is counted, never your address.

Why. To send you one email when the RideSentinel iPhone app launches. We use it for nothing else: no newsletter, no advertising.

Who sees it. Only the RideSentinel team. We never sell your address or share it for marketing. If we use an email service to send the launch email, it acts only on our instructions, as our processor.

How long we keep it. We delete the list once the launch email has gone out, or 24 months after you signed up, whichever comes first. You can unsubscribe or ask us to delete your address sooner.

Unsubscribing and deletion. The launch email carries an unsubscribe link: it opens a page where one button removes your address at once. You can also write to privacy@ridesentinel.app at any time, from the address you signed up with, and we will delete it.

What it is. RideSentinel works fully without an account. If you choose to join the driver network, you sign in with Google or with a link sent to your email. Google’s Firebase Authentication handles that sign-in for us as a processor and receives only your sign-in details, never your rides. The version of RideSentinel Lite on Google Play does not offer it: it has no account and no driver network.

What we keep. Your email, the display name and city you choose, and, once a day while you are signed in, how many Uber and Lyft offers the app read on each day: a date, an app name, a number and which of your phones sent it, never fares, addresses or riders. We also keep which drivers vouched for you and whom you vouched for.

Who sees it. Other drivers see only your display name, city, when you joined and your verification progress. Your email, your daily counts and who vouched for whom are seen by no other driver.

Deleting it. You can delete your account in the app at any time; that erases your email, profile and daily counts from our server and deletes your sign-in record at Firebase. Vouches you gave remain, without your name, so other drivers keep their status. If we revoke an account for misconduct, it is kept for review while it is revoked, and it can be restored. Once it is erased, only a one-way fingerprint of its email and sign-in identifier remains, with the date and our reason, not the email itself, so it cannot simply be opened again. Questions: privacy@ridesentinel.app.

The controller of this data is bidew.io, operating from Québec, Canada. There is no data protection officer and no designated representative in the European Union, the United Kingdom or Brazil. Privacy questions and data requests go to privacy@ridesentinel.app.

Performance of a contract. Your licence record, your install identifiers and your payment reference exist because you bought a licence and we have to make it work.

Consent. Website analytics, advertising measurement, sending error reports, the AI advisor, backups, driver-network demand sharing, linking a Tesla or another car, and the iPhone waitlist. Each is off until you turn it on, and you can turn any of them off again.

Legitimate interests. Download counters and access logs, so that the software can be kept working and abuse can be spotted.

Legal obligation. Payment and tax records that Stripe and we are required to keep.

Your choice. Driver-network data exists because you chose to join and because we need it to run the network.

Licence records: ten years. Free-trial codes: two years. Free-trial network counts: three days. Error reports: thirty days. Install registrations: while the installation is in use, and deleted when you ask. Road reports: thirty days. Driver-network demand: three hours. Download counters: ninety days. Backups: the twenty most recent per driver, until replaced or deleted. Browser-side preferences and referral codes: until you clear them, and thirty days for a referral code. Ride data on your phone: until you delete it or uninstall the app. Ask us to erase your licence record and we will, which ends your licence. Driver-network account data: while the account exists, and erased when you delete it, except the vouches you gave, which stay without your name. A revoked account is kept for review while it is revoked, and it can be restored; once it is erased, only the one-way fingerprint remains, with the date and our reason. Feedback notes and tips: up to three years, or until deleted, with the email address deleted when the note is closed or merged. iPhone waitlist: until the launch email or 24 months, whichever comes first.

Our server is in Canada. Google Firebase Authentication processes the sign-in of the optional driver network, and nothing else, as a processor. Sentry, Stripe, Smartcar, Google Analytics, PostHog and Meta process data in the United States, and Google processes AI advisor requests and live-traffic lookups on its own infrastructure. If you are in the European Economic Area, the United Kingdom or Brazil, using this software means your data is transferred outside your country. Canada holds a European Commission adequacy decision for commercial organisations; transfers onward to United States providers rest on those providers’ own transfer mechanisms, which we have not separately negotiated. This is one of the points to put to a lawyer before relying on it.

You can ask for a copy of what we hold about you, ask us to correct it, ask us to delete it, ask for it in a portable machine-readable form, object to our use of it, or withdraw a consent you gave. Depending on where you live these rights come from Québec’s Law 25, PIPEDA, the GDPR, the UK GDPR or Brazil’s LGPD; we apply the same process to everyone.

Email privacy@ridesentinel.app from the address you bought with, or quote your licence key. We answer within thirty days. We hold so little that most requests are answered in one message. Withdrawing consent does not undo what was already collected, and deleting your licence record ends the licence it represents. If you have a driver-network account, you can delete it yourself in the app, or write from the account’s email address and we erase it on request.

If you are not satisfied you can complain to your own supervisory authority: the Commission d’accès à l’information du Québec or the Office of the Privacy Commissioner of Canada, your national data protection authority in the EEA, the Information Commissioner’s Office in the United Kingdom, or the ANPD in Brazil.

Want your data erased? Delete your RideSentinel data