Hi! Thanks for building NotelyVoice, it's a lovely app and I enjoyed reading through the code.
I'm an MS student at the University of Denver, and my capstone is a measurement study of how open-source Android apps ship on-device models. Going through NotelyVoice I noticed one thing on the model-download path that I think is worth tightening up. Nothing alarming, this isn't an exploit report, just a heads-up.
Here's what I saw: the Whisper models (ggml-base.bin, ggml-small.bin, and the Hindi ggml-base-hi.bin) get pulled from Hugging Face via resolve/main URLs in shared/src/commonMain/kotlin/com/module/notelycompose/modelDownloader/ModelSelection.kt. TranscriptionModel doesn't carry a hash and the downloader doesn't verify anything, so the download isn't pinned to a fixed revision, and the file isn't checked against a known hash before it loads. (The Hindi option also comes from an individual account, khidrew/whisper-base-hindi-ggml.)
Why I'd bother with it: resolve/main is a moving target. If what's behind those URLs ever changes, say a compromised account, a repo transfer, or someone on an unencrypted network hop, the app would quietly load the swapped model with no version change to notice.
A couple of ways to shore it up, roughly in order of payoff:
Pin to an immutable revision: reference the specific commit hash in the Hugging Face URL instead of resolve/main.
Ship each model's expected SHA-256 in the app and check the download against it before loading, so a changed file gets rejected. For what it's worth, another Whisper app (Mindwtr) pulls the identical ggml-base.bin and ggml-small.bin from the same ggerganov/whisper.cpp repo and pins each file's SHA-256, rejecting a mismatch, so this is known to work for exactly these files.
Longer term, versioned and attributable model references are the cleaner path.
Happy to go into more detail or help out if any of it's useful. Thanks again for the app!
Hi! Thanks for building NotelyVoice, it's a lovely app and I enjoyed reading through the code.
I'm an MS student at the University of Denver, and my capstone is a measurement study of how open-source Android apps ship on-device models. Going through NotelyVoice I noticed one thing on the model-download path that I think is worth tightening up. Nothing alarming, this isn't an exploit report, just a heads-up.
Here's what I saw: the Whisper models (ggml-base.bin, ggml-small.bin, and the Hindi ggml-base-hi.bin) get pulled from Hugging Face via resolve/main URLs in shared/src/commonMain/kotlin/com/module/notelycompose/modelDownloader/ModelSelection.kt. TranscriptionModel doesn't carry a hash and the downloader doesn't verify anything, so the download isn't pinned to a fixed revision, and the file isn't checked against a known hash before it loads. (The Hindi option also comes from an individual account, khidrew/whisper-base-hindi-ggml.)
Why I'd bother with it: resolve/main is a moving target. If what's behind those URLs ever changes, say a compromised account, a repo transfer, or someone on an unencrypted network hop, the app would quietly load the swapped model with no version change to notice.
A couple of ways to shore it up, roughly in order of payoff:
Pin to an immutable revision: reference the specific commit hash in the Hugging Face URL instead of resolve/main.
Ship each model's expected SHA-256 in the app and check the download against it before loading, so a changed file gets rejected. For what it's worth, another Whisper app (Mindwtr) pulls the identical ggml-base.bin and ggml-small.bin from the same ggerganov/whisper.cpp repo and pins each file's SHA-256, rejecting a mismatch, so this is known to work for exactly these files.
Longer term, versioned and attributable model references are the cleaner path.
Happy to go into more detail or help out if any of it's useful. Thanks again for the app!