Critique of a 'Privacy Focused' App's Flawed Logic
Description
A two-part meme format. The top section contains three lines of green text, styled after 4chan's greentext stories: '>"privacy focused app"', '>looks inside', '>no sync, only local data without encryption'. The bottom section features a popular reaction image of a cat with white and grey fur, shot with a wide-angle lens held very close to its face, causing a distorted, intense stare directly at the viewer. A small watermark for 'imgflip.com' is visible in the bottom-left corner. The meme satirizes applications that claim to prioritize user privacy but implement it in a simplistic and insecure manner. Instead of using robust end-to-end encryption for data synchronization, the app simply avoids syncing altogether and stores user data locally in plaintext. This approach is a lazy shortcut that provides a false sense of security, as the data is vulnerable if the device is ever lost, stolen, or accessed by unauthorized individuals. The cat's confrontational gaze represents the silent, judgmental reaction of a tech-savvy user or developer who sees through this poor security practice masquerading as a privacy feature
Comments
35Comment deleted
That app's privacy model is just localhost with a 'please_dont_steal_this.json' policy file
Sure, the app doesn’t phone home - but any intern with adb shell can read your diary faster than DBeaver on a mis-indexed table
Ah yes, the classic 'privacy-focused' app that treats encryption like optional DLC - because nothing says 'we value your privacy' quite like storing your data in plaintext next to your browser's autocomplete history. At least they're transparent about it... once you decompile the APK and check the SQLite schema
Ah yes, the classic 'privacy-focused' app that stores your data locally without encryption - because nothing says 'we respect your privacy' quite like leaving your sensitive information in plaintext for any malware, forensics tool, or curious sysadmin to read. It's like putting a 'Private - Do Not Enter' sign on a doorway with no door. At least with cloud sync, the data breach happens on someone else's infrastructure
Local-only without encryption: trusting filesystem perms more than proper crypto since forever
Calling local plaintext "privacy" is like calling a shell script "orchestration" - the only key management is "don’t lose your phone."
Marketing calls it ‘privacy‑first’; the security review calls it ‘no backend plus a plaintext SQLite file’ - aka E2C: easy‑to‑copy
Short story of how I lost over a year's worth of Joplin notes on mobile (by default notes are NOT exported to a local backup and the app does NOT retain its data in phone backups) Comment deleted
appropriate app name Comment deleted
Imagine not having a backup and a backup of that backup smh 🙄 Comment deleted
if you need privacy, local data is obvious choice. if you cant trust your local environment, well, you f*cked and encryption does not make any sense there. Comment deleted
with whom? Comment deleted
well, not always. it makes sense to have password on your "homework" folder if your younger sibling has access to your pc, for instance. but for security, yes, encryption for local-only files is usually bullshit Comment deleted
Not really if you use TPM Comment deleted
Then its a mitigation in case of infection Comment deleted
If your home PC is stolen with all your "local" data in plaintext, it may become a trouble well beyond simply restoring your data from backup on a new computer. Comment deleted
Issue is they didn't add sync because they didn't have the budget. Not because its a privacy focused company. In the next update they will mandate cloud storage. 99% of outcomes Comment deleted
Otherwise your statement would suggest ASLR is bullshit too Comment deleted
Lmfao Comment deleted
source? Comment deleted
https://youtu.be/wTl4vEednkQ?si=UnwOvIqBfR6MnS4f TPM is security theater Comment deleted
Isn't this why on CPU TPM2 is better? Comment deleted
Idk if 2 fixes these problems, I just know that on my machines I only trust LUKS encryption with a long password and encrypted boot partition Comment deleted
why encrypted boot partition? Comment deleted
Mostly "why not" Comment deleted
fair Comment deleted
Why yes? Assuming you enter password at the bootloader stage it does not really protect anything. Bootloader can be tampered as much as the kernel images. And it gives you much fewer options on verifying integrity of the system, using hardware tokens, etc. Comment deleted
isn't this what privacy focused means? Comment deleted
No, this means "We dont yet have the money to track you, but we promise in the next update" but right now we need to pump up users with promises we wont keep in the future Comment deleted
Trust Comment deleted
me Comment deleted
> export available only in proprietary format Comment deleted
just store your data in good old floppy disk. Youngsters dont even know how to use them Comment deleted
At that point you may want to have minimal kernel+initrd that verifies signatures on the actual boot images and uses kexec to load them. I think Heads does that. Comment deleted
For that I prefer to put the LUKS header on removable device. Can't guess passwords when the key information is gone. Comment deleted