SID3KICK — Privacy & Data Handling

SID3KICK is built local-first: everything it captures lives on your device by
default, and nothing leaves it unless you explicitly configure a cloud feature to make that
happen. This page explains exactly what’s stored, where it goes when you do turn on a cloud
feature, who (if anyone) can see it, and how to delete it.

This is a description of how the app behaves, not a legal document, and nothing here is legal
advice — see Consent and legality below in
particular.

Everything starts local

Every piece of data SID3KICK generates is created and stored in the app’s own private storage on your
device:

• Recordings — the raw audio, saved as WAV files.
• Transcripts — including speaker-attributed transcripts, if you’ve turned on speaker
  identification.
• Summaries, titles, and daily digests.
• Extracted to-dos and calendar-event suggestions.
• Cost/token logs — the running record of API usage and computed spend, if you use any cloud
  provider.
• Photos and video captured through the in-app camera.

None of this is sent anywhere by default. A fresh install with no cloud provider configured — using
on-device transcription and a local LLM like Ollama or LM Studio — never makes an outbound request
containing your audio, transcripts, or summaries at all.

Two things do still touch the network on such an install, and neither one is a provider you picked:
a one-time speech-model download on Android, and — only if you switch location tagging on — a
place-name lookup that sends the coordinates. Both are spelled out under
Network destinations you didn’t configure, because
“local-first” is worth nothing if the exceptions are left unwritten.

What leaves the device — and what doesn’t

Your captured content — audio, transcripts, summaries, photos, to-dos — leaves your device only
when you deliberately configure a cloud feature in Settings, and even then, egress is scoped to
exactly the provider you picked for that specific feature. SID3KICK doesn’t fan data out to multiple
services or route it through anything of its own. (One piece of personal data can leave without any
cloud feature configured: your coordinates, if you switch location tagging on — see
Network destinations you didn’t configure.)

You configure…	What’s sent	Where it goes
OpenAI cloud transcription	The recorded audio	OpenAI’s transcription API only
OpenAI or Anthropic as your LLM provider	The transcript/text being summarized or chatted over	That provider’s API only
A custom OpenAI-compatible endpoint	The transcript/text being summarized or chatted over	The endpoint you configured (could be a cloud host or your own server)
Ollama or LM Studio (local LLM)	The transcript/text being summarized or chatted over	Your own LAN — never the public internet
Cloud archive → Dropbox (Android)	The recording’s WAV file	Your own Dropbox App Folder
Cloud archive → Google Drive (Android)	The recording’s WAV file	Your own Google Drive, via a drive.file-scoped token
Google Tasks sync (Android)	Extracted to-do text	Your own Google Tasks account
Multi-device sync (Android)	A JSON snapshot of your transcripts, summaries, titles, to-dos, event suggestions, daily digests and location tags — see Multi-device sync	Your own Dropbox, Google Drive, or FTP server, whichever you picked

Platform note. Cloud archive, Google Tasks sync and multi-device sync are implemented on
Android only in this build. On iOS the same settings exist and store what you type, but the
switches are shown disabled with a note, and no upload of any kind takes place from an iPhone or
iPad.

On-device transcription and local LLMs (Ollama, LM Studio) mean exactly what they say: no audio and
no text leaves the device for those steps — both are processed entirely on your phone or on
hardware you personally control on your own LAN.

On Android there is a one-time download first. Vosk can’t transcribe without a language model
on disk, and models aren’t shipped inside the app — so Settings → Transcription lists the fourteen
languages with a Download button next to each, and tapping one fetches that model from
alphacephei.com (the Vosk project’s model zoo), 31–82 MB depending on the language and about
40 MB for English (US). Nothing downloads on its own; the app never fetches a model you didn’t ask
for, and never fetches one at launch. That request carries nothing of yours:
it’s a model coming down, not your audio going up. Once it has landed, Vosk transcription is
genuinely offline for good — including on a phone in airplane mode.

On iOS there is no download at all. Transcription uses Apple’s Speech framework with
requiresOnDeviceRecognition forced on, and the app refuses to transcribe rather than fall back to
Apple’s servers if iOS has no on-device model for that language. The models themselves belong to
iOS, not to SID3KICK — they arrive with the system’s own language downloads, which you manage in
iOS Settings.

Video is never sent to AI

Video you record in-app is never uploaded to any AI provider, full stop. When a video recording
finishes, SID3KICK extracts just its audio track and runs that through whatever transcription engine
you’ve configured — the same as any other recording. The original .mp4 file stays on the device
as a local attachment; it is not read by, or transmitted to, any transcription or LLM provider
under any configuration.

Location tagging is off by default

SID3KICK can tag each recording with where you were. It doesn’t, unless you ask it to — the setting
ships as Off, and while it’s off the app takes no location fix, stores no coordinates, and
requests no location permission.

Turn it on in Settings → Location and you pick the granularity:

• Off (default) — no location data of any kind.
• Country only (low power) — the cheapest available last-known fix, no GPS wake-up. Coordinates
  are blurred to roughly a kilometre before they’re stored, and what you mostly see is the place
  name.
• Precise (map) — a fresh fix per recording, stored exactly, so the map pin lands where you
  were.

Either way the tag is stored locally, on the recording, and it never reaches a server of ours —
there isn’t one. Two consequences of turning it on are worth knowing about:

• Turning it on means the place name can reach your AI provider. The tag is fed to the
  summarizer as context, so if you’ve configured a cloud LLM, the place label travels inside the
  text you were already sending it.
• Resolving coordinates into a place name is a network lookup. See below.

Network destinations you didn’t configure

Every destination in the egress table further up is one you chose. There are a few SID3KICK reaches
without being told to, and it would be dishonest to describe the app as talking only to services
you configured. Here they are, all of them:

What	When	What’s sent	Where
Reverse geocoding — turning coordinates into a place name	Only with location tagging on, once per tagged recording	The coordinates of the fix, before any blurring — the ~1 km rounding in Country-only mode is applied to what gets stored, not to what the lookup receives. (On iOS, Country-only also asks CoreLocation for a kilometre-accuracy fix in the first place, so the fix itself is coarser; on Android it’s the full-precision last-known fix.)	The operating system’s geocoder: Google’s on Android (android.location.Geocoder), Apple’s on iOS (CLGeocoder)
Vosk model download	Android only, once per language, and only when you tap Download for it in Settings	Nothing of yours — a plain model download	alphacephei.com
Map tiles	Android only, when you open the map view of geo-tagged recordings	The tile coordinates for the area you’re looking at, which implies the area you’re looking at	OpenStreetMap’s tile servers (via osmdroid; no API key, no Play Services)
Subscription checks	Always, at launch	Nothing of yours — the app asks the store whether a subscription is active	Google Play Billing on Android, StoreKit on iOS

None of these carries your audio, transcripts, summaries, photos, or to-dos. The one that carries
personal data is the geocoder, which is exactly why location tagging defaults to Off: leave it off
and that lookup never happens. Note also that the OS geocoder is the platform’s, not ours — the
lookup is governed by Google’s or Apple’s privacy policy, not by this document, and we receive
nothing back from it beyond the place name.

API keys and tokens

Every credential you enter — OpenAI/Anthropic API keys, Dropbox access token, Google Drive OAuth
token, Google Tasks OAuth token, FTP username and password — is stored in the app’s own private
storage: Android’s Preferences DataStore, and on iOS a settings.json file inside the app’s
sandboxed Application Support directory. Both are readable only by SID3KICK itself (on Android,
not by any other app without root). SID3KICK does not use the iOS Keychain, so on iOS your
credentials are covered by the device backup rules described under
Backups below rather than by Keychain’s separate protections.

• Keys and tokens are never written to logs, in this build or any other.
• They only ever travel to the one provider they belong to. Cloud provider traffic — OpenAI,
  Anthropic, Dropbox, Google Drive, Google Tasks — is always HTTPS. There are two deliberate
  exceptions, both of them your own infrastructure and both of them your choice:
• Self-hosted LLM endpoints on your LAN or loopback, where SID3KICK’s network configuration
  permits plaintext http:// so a local Ollama/LM Studio server works without you setting up
  TLS. That allowance is scoped to local network destinations only (on Android via
  res/xml/network_security_config.xml, on iOS via ATS’s NSAllowsLocalNetworking, which
  exempts loopback, .local and private ranges and nothing else).
• Multi-device sync pointed at an FTP server, which is plain RFC 959 FTP with no TLS: the
  snapshot and the FTP password travel in the clear. If that server is outside your own
  network, so does everything in the snapshot. Pick Dropbox or Google Drive, or an FTP host you
  reach over a VPN, if that matters to you.

OAuth access tokens (Google Drive, Google Tasks) expire periodically by design — when they do,
sync/archive simply stops until you paste a fresh one. SID3KICK doesn’t have a refresh-token flow; you
control exactly when a new token is issued, by generating and pasting it yourself.

Backups (Android vs iOS)

The two platforms behave differently here, and it would be misleading to describe only the
stricter one.

Android — excluded. The app declares android:allowBackup="false". In practice, this means
your recordings, transcripts, summaries, and every stored API key or token are excluded from
Android’s automatic cloud backup (Auto Backup for Apps / Google’s device backup). Restoring a new
phone from an Android backup will not bring your SID3KICK history along with it — that’s expected,
and it’s a deliberate choice to keep sensitive local content and credentials from ending up in a
backup channel outside the app’s control.

iOS — included, like any other app. SID3KICK does not mark its files as excluded from backup,
so your recordings (in the app’s Documents folder), your database and your stored API keys (in
Application Support) are part of the app’s normal iCloud Backup / encrypted local backup, exactly
as they would be for any app that doesn’t opt out. Apple encrypts iCloud Backup, and you can turn
SID3KICK off individually under iOS Settings → your name → iCloud → Manage Storage → Backups if you
would rather it wasn’t included.

Also on iOS: your recordings are visible in the Files app. The app sets
UIFileSharingEnabled, which deliberately exposes its Recordings folder under On My iPhone/iPad →
SID3KICK so you can copy your own audio off the device without a cable or an export feature. That
folder is reachable by you and by anything you grant access to it in Files — it is not hidden
inside the sandbox the way the database and settings are.

Consent and legality (recording other people)

Passive (“Life Assist”) mode — Android only in this build; the iOS switch is disabled and captures
nothing — records continuously, screen off or on, which means it can capture other people’s voices
without them separately opting in each time. This is worth being deliberate about, not just a
feature to flip on.

• The app shows a first-run consent notice during onboarding, in plain language, that you have
  to actively check off before continuing.
• Recording-consent law varies by jurisdiction: some places require every participant’s consent
  (“two-party” or “all-party” consent), others require only the person doing the recording to
  consent (“one-party”). These rules differ by country, and within countries like the US, by state.
• You are responsible for recording lawfully wherever you are and whoever you’re with. SID3KICK
  doesn’t determine or enforce what’s legal in your location — it can’t know where you are or who’s
  in the room. Nothing in this document, or in the app’s onboarding text, constitutes legal advice;
  if you’re unsure whether a use case is lawful where you are, consult local law or a lawyer rather
  than relying on the app’s behavior as guidance.

Cloud archive goes to your own account

Android only in this build. If you turn on cloud archive, uploaded recordings go to an account
you control — SID3KICK has no shared or developer-owned storage in the loop:

• Dropbox: files are written into a /Sidekick/ folder inside the App Folder Dropbox scopes to
  SID3KICK within your own account, one rec_<id>_<timestamp>.wav per archived recording. An App
  Folder token cannot see the rest of your Dropbox.
• Google Drive: SID3KICK authenticates with a token scoped to drive.file, the narrowest Drive
  scope Google offers — it grants access only to files the app itself created, not your whole
  Drive. Files are named Sidekick_rec_<id>_<timestamp>.wav. SID3KICK cannot see, list, or touch
  any other file in your Google Drive.

Only the audio is archived. Photos, video and the text of your transcripts and summaries are not
part of cloud archive.

Multi-device sync (Android)

Android only in this build. Off by default. Turn on Settings → Multi-device sync and your
devices keep each other up to date by passing a file through storage you own — there is no
account, no server of ours, and your devices never talk to each other directly.

Each device writes a single JSON snapshot of its own rows to SidekickSync/<deviceId>.json on the
remote you chose, then reads the other devices’ snapshots back and merges them, newest edit per row
winning. What that snapshot contains:

• Sent: recording titles, transcripts (including speaker-attributed ones), summaries, statuses
  and timestamps; to-dos; event suggestions (title, description, location, times); daily digests;
  and, if location tagging is on, each recording’s coordinates, accuracy, country code and place
  label.
• Not sent: the audio itself, photos, and video. Those stay on the device that captured them.
  A synced row can carry a reference to a cloud-archived WAV so another device knows where to
  find it, but sync never moves media.
• Where: your own Dropbox App Folder, your own Google Drive (drive.file scope), or an FTP
  server you run. Dropbox and Drive are HTTPS; FTP is not encrypted — see
  API keys and tokens.

This is the one feature that puts the full text of your recordings into cloud storage even when
your AI provider is entirely local, so it is worth turning on deliberately rather than by habit.

Deletes do not sync. A recording, to-do or event you delete on one device is removed only from
that device. Because a snapshot lists living rows and has no way to say “this one is gone”, the
next merge re-creates the deleted row from a peer’s copy — a transcript reappears, without its
audio. Until deletion markers ship on both platforms, treat delete as local-only whenever sync is
on, and see Deleting your data for how to clear a row everywhere.

Calendar access

SID3KICK extracts event suggestions from your recordings and can add them to your calendar when you
confirm. It never reads what’s already in your calendar, and it never sends calendar data anywhere.

• iOS 17 and newer: the app asks for write-only calendar access
  (requestWriteOnlyAccessToEvents, declared as
  NSCalendarsWriteOnlyAccessUsageDescription), the narrowest calendar permission iOS offers —
  under it the app is technically incapable of reading your events.
• iOS 16: Apple hadn’t split the permission yet, so the only grant available is the combined
  one and that’s what the prompt asks for. The app’s behaviour is identical either way: it inserts
  events and never issues a read.
• Android: Android has no write-only calendar permission, so the app holds both
  READ_CALENDAR and WRITE_CALENDAR. The read permission is used for exactly one thing: listing
  the calendars on the device so it can pick a writable one to insert into. No event is ever read,
  stored, or transmitted.

Calendar access is never demanded. On Android it’s offered as an optional grant on the onboarding
permissions step, and otherwise asked for at the moment you first tap to add an extracted event to
your calendar. Declining costs you nothing but that button.

Reaching an AI server on your own network

If you point SID3KICK at Ollama, LM Studio, or an OpenAI-compatible endpoint running on another
machine on your network, both operating systems now require an explicit grant before the app may
speak to a LAN address at all:

• Android 17 and newer (ACCESS_LOCAL_NETWORK): Settings shows an “Allow local network access”
  prompt, and only when the base URL you typed actually points at a private, link-local or .local
  address. A loopback address (the shipped defaults, http://127.0.0.1:11434 and :1234) is the
  phone itself and is never gated, and a cloud provider is ordinary internet traffic — in both cases
  you are never asked. Older Android versions have no such permission.
• iOS (NSLocalNetworkUsageDescription): iOS shows its own local-network prompt the first time
  the app tries to reach your LAN.

This permission lets the app reach a machine you run. It does not let SID3KICK scan your network,
and nothing about your network is sent anywhere — the whole point of the feature is that your
transcripts go to your own hardware instead of a cloud provider.

What the developer receives: nothing

SID3KICK has no telemetry, no analytics SDK, and no crash-reporting backend of any kind. There is no
server operated by the app or its developer that any of your data — audio, transcripts, summaries,
usage stats, or anything else — is ever sent to.

Not one network destination SID3KICK talks to belongs to us. Nearly all of them are the ones you
explicitly configure in Settings: your chosen AI provider(s), your own cloud storage account, your
own LAN. The few you don’t configure are listed in full under
Network destinations you didn’t configure — a place-name
lookup, a speech-model download, map tiles, and the store’s subscription check. Between them they
carry a coordinate pair and a map viewport, and never your recordings, transcripts, or summaries.

Deleting your data

• Delete individual recordings in-app from the Recordings screen — this removes, from this
  device, the local audio file, every photo and video attached to it, and its transcript,
  summary, and extracted events/to-dos.
• Uninstalling the app removes all of its local data — recordings, transcripts, summaries,
  digests, cost logs, photos/video, and every stored API key or token. On Android that is the end
  of it, because nothing was backed up (see Backups above); on iOS, a
  device backup taken before you uninstalled still holds a copy until that backup is deleted or
  rotated.
• Copies you sent elsewhere are yours to delete. A delete inside SID3KICK is local: it does not
  reach out and remove anything you previously uploaded. Specifically —
• a recording archived to Dropbox or Google Drive stays in your Dropbox or Drive until you delete
  it there;
• a to-do pushed to Google Tasks stays in Google Tasks (the sync is one-way, push only);
• with multi-device sync on, the row is still present in the other devices’ snapshots and in your
  own SidekickSync folder, and the next merge will bring it back. To clear a row everywhere
  today: turn sync off on every device, delete the row on each of them, delete the
  SidekickSync folder on the remote, then turn sync back on. A proper deletion-marker mechanism
  is the fix, and is not in this build;
• a calendar event you confirmed is a real event in your calendar and is deleted from there.
  Nothing in this list is on a server of ours — every one of them is an account or a machine you
  control.
• Revoke provider access on the provider’s side whenever you want to be sure a key or token
  can’t be used again — OpenAI and Anthropic both let you revoke individual API keys from their
  dashboards, and Google/Dropbox let you revoke a connected app’s access from your account security
  settings. Deleting the token from SID3KICK’s Settings stops the app from using it, but revoking it
  with the provider is what actually invalidates the credential itself.
• Local audio auto-prune (Settings → Capture → Auto-prune analyzed audio) can automatically
  delete old, already-processed audio files after a set number of days, to keep local storage from
  growing without bound — see the
  Troubleshooting guide for exactly how that
  interacts with cloud archive.

Data flow at a glance

• Recording, on-device transcription + local LLM (Ollama/LM Studio): none of your data leaves
  the device. On Android, the chosen Vosk language model is downloaded once from alphacephei.com
  before this works offline; on iOS there’s no download.
• Recording, on-device transcription + cloud LLM (OpenAI/Anthropic/custom endpoint):
  transcript text goes to your chosen LLM provider only; the audio itself never leaves the device.
• Recording, cloud transcription (OpenAI): audio goes to OpenAI for transcription; the resulting
  transcript then goes to whichever LLM provider you’ve configured for summarization (which may
  also be OpenAI).
• Video capture: the .mp4 stays on the device, always. Only its extracted audio track follows
  the same transcription path as a regular recording.
• Photos: stored locally as attachments; never uploaded anywhere.
• Location tagging (off by default): the tag is stored locally on the recording. Resolving it
  into a place name sends the coordinates to the OS geocoder — Google’s on Android, Apple’s on iOS.
  The place name may then travel to your LLM provider as summarizer context.
• Second-brain chat / describe-and-recall search: relevant stored transcript/summary text is
  sent to whichever LLM provider you’ve configured, the same as summarization.
• Cloud archive (Android): the recording’s WAV file goes to your own Dropbox App Folder or your
  own Google Drive (drive.file scope), whichever you selected. Audio only — no photos, no video,
  no text.
• Google Tasks sync (Android): extracted to-do text goes to your own Google Tasks account,
  push-only.
• Multi-device sync (Android): a JSON snapshot of your transcripts, summaries, to-dos, event
  suggestions, digests and location tags goes to your own Dropbox, Google Drive or FTP server. No
  audio, photos or video. FTP is unencrypted.
• Calendar: an event you confirm is written to your device calendar. Nothing is read from it,
  and no calendar data leaves the device by way of SID3KICK.
• Cost/token logs, settings, API keys/tokens: stored locally only; never transmitted anywhere
  except that each key/token is used to authenticate requests to its own provider as described
  above.

---

SID3KICK — sid3kick.app · by codedatda.casa