"Privacy-first" has become marketing wallpaper. Almost every app has a paragraph about it; almost none earn it. The pattern is familiar: a long list of third-party SDKs in the license screen, a privacy policy that turns out to be a sharing agreement, and a permissions list that asks for the moon and the sun "to improve your experience."
Drimin takes a different approach. Instead of claiming privacy, it makes privacy a property of the build — something the operating system enforces on our behalf, whether we change our minds or not. Here's how, in roughly the order it would matter if you were auditing the app yourself.
No INTERNET permission, full stop
Drimin's AndroidManifest.xml does not declare the
android.permission.INTERNET permission. This is the strongest possible
statement an Android app can make about its network behaviour. With the permission
absent, Android's sandbox refuses every outbound socket call, every HTTP request, every
WebSocket attempt — regardless of what the app's code is trying to do. There is no
"secret" telemetry channel; the OS would refuse it.
This is the kind of guarantee you can verify with two minutes and an unzip tool. Pull
the APK, open the manifest, search for INTERNET. If it isn't there, the
app cannot talk to the network. Drimin's isn't there.
Encrypted local storage
Every intake you log is written to a SQLite database that's encrypted with
SQLCipher. The encryption key is a
256-bit value generated on first launch and stored in
Android Keystore
through flutter_secure_storage. On devices with secure hardware, the key
is hardware-backed and cannot be exported from the secure element, even by a rooted
attacker.
That means three things in practice. First, if someone clones your phone's storage to a desktop and pokes at the raw database file, they see ciphertext. Second, if Android ever needs to restore your data to a new device, it can't — because the key is unique to the original device's keystore. Third, if you uninstall Drimin, the key is destroyed and the ciphertext becomes permanently undecryptable.
No backup, no transfer
Drimin's manifest sets android:allowBackup="false" and includes a custom
data_extraction_rules.xml that opts the app's data directory out of Google
cloud backup, device-to-device transfer, and adb backup. Combined with the keystore
binding above, this means there's no path by which your hydration data leaves the
device, even unintentionally.
No analytics, no crash reporting, no SDKs that phone home
Drimin contains zero analytics SDKs. No Firebase Analytics, no Crashlytics, no
Mixpanel, no Segment, no Sentry, no AppsFlyer. The list of runtime dependencies in
pubspec.yaml is small and intentional: a UI framework, a state-management
library, a router, a database, a notification scheduler, a few platform integrations.
None of them contact a network on Drimin's behalf at runtime. (Even if they tried,
see "No INTERNET permission, full stop," above.)
One notification channel per sound
This is an obscure but important detail. Android caches the sound configured on a
notification channel forever; changing it requires a new channel. Most apps create one
channel called "Reminders" and never update it, which is why changing reminder sounds
in many apps silently fails. Drimin creates a separate channel per ReminderSound
and routes notifications to the right one — so when you change the sound, it actually
changes.
Why is this a privacy story? Because it's the same principle: the OS is the source of truth, not the app. We work with the platform's enforcement rather than around it.
Permissions, minimised
The full list of Drimin's runtime permissions:
POST_NOTIFICATIONS— only if you turn on reminders.RECEIVE_BOOT_COMPLETED— so reminders survive reboots.VIBRATE— only if you turn on reminder vibration.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS— to deep-link the user to the OS settings screen where they can opt the app in. We never request it without you tapping a button labelled "Battery optimization."SCHEDULE_EXACT_ALARM/USE_EXACT_ALARM— to fire reminders at the minute you asked for, not "sometime in the next half hour."
No READ_CONTACTS. No ACCESS_FINE_LOCATION. No
READ_PHONE_STATE. No READ_EXTERNAL_STORAGE. No
FOREGROUND_SERVICE. Nothing that doesn't have a one-line justification in
the app.
Hide from recents
For people who hand their phone to others, or who use Drimin in shared workspaces,
there's a Settings toggle that applies FLAG_SECURE to the activity. With
it on, Android blanks the app preview in the recents switcher and blocks screenshots
and screen recordings of the app itself. It's a small touch with a real impact on
anyone who's ever winced when their boss saw a notification slide down.
What this doesn't mean
Privacy-first isn't perfection-first. A few honest disclaimers:
- Reminder delivery depends on Android. Aggressive OEM battery optimization can delay or drop scheduled work. We help you exempt the app, but the platform has the last word.
- The marketing website (drimin.thevobot.in) is served by Firebase Hosting, which keeps standard server access logs for operations and security. The app itself never contacts the site, so the two are not joined.
- Google Play distributes the app and applies its own data-handling policies to the install transaction. We have no influence over those.
The point of all this
Most "privacy-respecting" apps are an exercise in trust. You trust the developer to configure their analytics SDK correctly. You trust them to not change their mind in a future release. You trust their backend to be secure.
Drimin tries to ask for as little trust as possible. The OS verifies that we can't send your data anywhere. The keystore verifies that we can't read your data without the device. The manifest is open to anyone who wants to look. Where trust is still required — the Play Store distribution, this website — we tell you exactly where it is.
That feels like the bare minimum a hydration app should be expected to do. And yet, in 2026, it's a differentiator.