Is My Grow Journal Data Safe From Hackers (or the App Company Itself)?
There are two separate threats hiding in that question — an outside attacker who breaches a server, and the company that runs it deciding (or being compelled) to look at your data. GrowScope's grow-diary encryption is designed to make both of those the same non-event: neither one has a key that works.
A server breach exposes ciphertext, not your diary
Because encryption happens on your device before anything is sent, what actually sits on GrowScope's server is already-encrypted bytes for your diary content. If a server were ever breached, an attacker who got that data would get unreadable ciphertext, not a readable grow journal — there's no key stored alongside it that would let them decrypt it, because the key never leaves your device in usable form to begin with.
The company itself can't read it either — and can't be made to
This is the part that separates a real privacy design from a privacy policy: GrowScope isn't choosing not to look, it structurally cannot. There is no support-team 'view user data' button that works on an encrypted diary, and no key sitting in a database that a legal request could compel someone to hand over, because no such key exists anywhere except derived, momentarily, on your own device when you unlock it.
What this doesn't protect against
Encryption isn't a universal shield, and it's worth being precise about that. It doesn't protect you from someone who has your unlocked device or your written-down recovery phrase — the security lives in the key, and whoever holds the key has the same access you do. And it deliberately doesn't extend to AI features: when you run one (photo diagnosis, the fertilizer advisor, card art), the specific data that action needs is decrypted on your device and sent, once, through GrowScope's server to a third-party model provider (Anthropic Claude, or Google Gemini via OpenRouter) to generate the response, then not kept — a disclosed, opt-in exception scoped to the one action you triggered, not a silent gap in the encryption claim. A fully on-device AI was weighed and turned down for these specific features because the tasks they do (fertilizer-dose math, trichome/pest image reading) are exactly where small local models are weakest.
Why 'zero-knowledge' isn't just a buzzword here
The term for this design is zero-knowledge encryption — the server holds and processes data it has zero ability to read. It's a specific, verifiable architecture (client-side encryption, a key derived from a phrase only you ever see, nothing usable stored server-side), not a synonym for 'trust us.' The trade-off is real too: a design that gives a company zero knowledge of your data also gives that company zero ability to recover it for you if you lose your own key — see the companion article on the recovery-phrase trade-off for that half of the picture.
How GrowScope helps
Every account is covered by this by default — there's nothing to configure. Anyone who wants the exact mechanism (the specific encryption and key-derivation methods used, and how individual records are separated so one exposed key doesn't expose everything) can read the full technical write-up in the Encryption documentation rather than taking this summary on faith.
Key takeaway
Because encryption happens on-device before data is sent, both a server breach and a request to the company itself hit the same wall: only unreadable ciphertext exists on the server, and no usable key exists anywhere except momentarily on your own unlocked device.