encryption at rest? #1001
|
hi, thanks for the awesome project! I'm wondering if this project has considered encryption-at-rest in some way. I guess it could be handled outside of the software itself? For example sync with folder, and have a different system that mounts / encrypts / decrypts that folder? (e.g. https://docs.syncthing.net/users/untrusted.html). Or if you can self-host in a trusted location, then a simple VPN also works. But it would definitely be simpler for users if (for example) the sync to Dropbox was encrypted (Enpass does the same). Thoughts? |
Replies: 6 comments 94 replies
|
Not built in today. The sync document is plain JSON and attachments are ordinary files, so what you get at rest is whatever the device, server, or provider gives you:
For today, your layering instinct is the supported answer: point File Sync at a folder on an encrypted filesystem or a gocryptfs/Cryptomator mount, so the app sees decrypted files while the disk stores ciphertext. Syncthing's untrusted-device mode also works for keeping an intermediate box ciphertext-only, with the caveats that trusted endpoints still hold plaintext and Syncthing itself labels the feature beta. On building client-side encryption in: it's a direction that fits Mindwtr's local-first model, and for the file-like backends (File Sync, WebDAV, Dropbox) it's architecturally workable — every client already downloads and merges the full document locally, and attachments would need the same treatment. The self-hosted cloud backend is harder, because its server currently merges concurrent writes itself; opaque ciphertext would mean moving that merge to clients or redesigning the stored format. And most of the real work is key management rather than the cipher: per-device passphrase setup, secure key storage on four platforms, migration of existing data, rotation, and honest behavior when the passphrase is lost. I wouldn't claim end-to-end encryption for anything here without an agreed design and an external review of it. So: not on the roadmap right now, and the encrypted-storage layering above is what I recommend and will document more explicitly. If someone wants to drive a design for an optional passphrase-encrypted format for the file-like backends, I'm open to that discussion — spec first, then implementation. |
|
On a related note, I was looking for a way to encrypt the Mindwtr sync files before they reach a public WebDAV server and thought of the following:
This should in theory work, except for the fact that documentation seems to recommend WebDAV over File Sync: WebDAV supports "per-item merge", File Sync only supports file-level sync? I'm confused as to how this differs, seeing as the complete That said, it would probably only be beneficial compared to Syncthing if this were to save battery drain compared to using e.g. BasicSync, which is unlikely considering the extra encryption operations. The issues I have with Syncthing that keeps me from using it is that it sometimes simply won't find the other device (via relay) and I need to restart it a few times and that there's a significant delay between Mindwtr's sync and Syncthing's. |
|
A local folder — that kills my flaky-target theory, so something in the verification itself refuses the switch and I want to see what. If you're up for one more attempt: enable Settings → Sync → Diagnostics → Debug logging on desktop, try the folder change + Sync now once, and attach the log file whose path appears under the toggle. The failure is recorded there with the real error, which the toast currently swallows (next release shows it directly). On the path visibility — both done with 2bde752: hovering an attachment shows its full path, and the open error now reads "File does not exist or cannot be accessed: ". And the portable point is a real gap, not just a display problem: attachments imported into the profile get an absolute path, so relocating a portable install strands every reference even though the files moved along with it. Tracking that as #1038 — it needs the open/preview/sync paths to resolve profile attachments against the current profile location rather than the recorded absolute path, so it's a design fix rather than a quick one. |
|
Sure. It also includes the problems with an attachment, even though I fixed the attachment link. Directory is Syncthing, but Syncthing was not running. As for the attachment:
|
|
That log nailed it — thank you. The failure is ours, and it's now fixed.
Fixed in 36f9988: the verification sync now grants access to the candidate folder before it runs, so the attachments check operates on the folder you actually picked. Your Syncthing folder change should save on the first "Sync now" in the next release. Edit — the attachment-link behavior is root-caused too, and you were right on both counts. Adding a local file through "Add link" was recorded internally as a file attachment, not a pointer — the add itself copies nothing, but sync then treats it like an app-owned file: it uploads a copy into the sync folder's Links you added before the fix keep their old file-attachment identity (cutting their sync off retroactively would strand the copies other devices already reference) — opening one with the pencil and re-saving it converts it to a true pointer. The portable absolute-path side landed as well (25cbb8d): attachments the app does hold a copy of now resolve against the profile's current location when the recorded path goes stale, so a moved portable install opens them instead of "File does not exist or cannot be accessed." |
I just rebuilt. There is no pencil button for previously added attachment links. |
|
Right — the pencil only rendered on attachments already typed as links, and the pre-fix ones are typed as files, so the conversion path I described did not exist yet. Add a fix dd1bb29: file attachments pointing outside the managed folder now show Edit, and re-saving one turns it into a clean pointer (the leftover synced-copy bookkeeping is dropped too). Rebuild and the pencil should be there. |
Encryption at restFront-end
Back-end
|
|
I am running the automatic review and architecture improvement workflow and preparing for the next RC release. |
|
Happy to see that there is still versioning for |
|
By design on WebDAV: the document is PUT straight to its own path, so Nextcloud versions every upload as a new revision of the same file. The write-to-.tmp-then-rename routine is the local-filesystem discipline for File Sync, where a crash mid-write would otherwise leave a torn file on disk — over WebDAV each PUT is atomic on the server side, so there is nothing to rename and nothing for versioning to lose. |
|
I just updated to rc.2 and this shows: So two errors, which one is it? Or both? It's a simple up-to-date Nextcloud instance. Also, on Android (before updating to rc.2), I never saw the sync "dot" turn from orange to green, even after a successful sync. |
|
@ltguillaume They are two views of the same compatibility error. I fixed the Nextcloud check in c8ca670 and am tracking confirmation in #1056. Please try the next release and let me know if it still appears. The Android orange dot is separate; please let me know if RC.2 still leaves it orange after a successful sync. |
|
@Kidlike v1.2.5 is out now, which has encryption for sync. Since I'm pretty much the only one who has tested this "in the field" so far, could you maybe chime in? |
|
I will test v1.2.5 later today or tomorrow. Thanks for all the effort! I hope it works 🤞 |
|
I managed to set everything up with a file backed sync, and Syncthing between a Fedora linux using Appimage and Android (from play store), both in v1.2.5. Things seem to sync! The setup on Android was a bit finicky. On the first try, launching the app I clicked setup sync, added the (already synced) folder from Syncthing, and then the app thought I was setting a new encryption password (asked for it with 2 input fields). Setting the encryption password that way failed. Then the encryption password input form changed and looked more like asking for the correct thing with a single input field for the existing password. This time the sync config worked and was saved. |
|
Yeah, I had this with an earlier build, too, so it clearly isn't fixed just yet. So, right after setting up the sync back-end the Encryption section isn't correctly updated to reflect that the user needs to enter an existing password. I take it you did correctly get a pop-up that the sync location is encrypted? |
|
yes I did get that popup |
|
Great to hear v1.2.5 syncs for you, thanks for testing it. The finicky first attempt is a real bug, and ltguillaume is right that it was still present: the Encryption section read its state once when the screen opened, so the app only learned the folder was already encrypted during that first sync attempt, after the section had already offered to set a new passphrase. Fixed with a305722: as soon as a sync or connection test finds encrypted data, the section switches to asking for the existing passphrase, on both desktop and Android. It will be in the next release. |
|
On Android, I found Mindwtr to be very heavy already when actively used (foreground), but now that WebDAV sync is set up (as opposed to file sync, which doesn't do anything in the background), I see it take up such a substantial chunk of the battery drain that I don't know if it's even worth using it. I know Android's battery usage stats are all relative and therefore not easy to read, but if a background sync I don't need (the method as it's for file sync would suffice for me) takes up anywhere between 2-20% at any given 24h time span, I'd rather not use it. I don't think I can safely set |
|
One more, and it explains why scheduled sync never seemed to run at all from a closed app: e8ebd37. Two things were wrong on that path. When Android woke the closed app for the job, the task library cancelled the very worker that woke it and queued a fresh one 15 minutes out, so the sync was cut off before it finished, every time. And the release build stripped the class that loads the app in the background, so in a shipped build the job failed at startup and then sat for 10 minutes. Both are fixed; on the emulator a scheduled run onto a dead app now finishes in about four seconds. Same test as before applies: background time on the battery screen, and the "Mobile background sync started" and "finished" lines in the log. |
|
Woah, I just wanted to post this:
Which was the case late afternoon. And for one last double-check I reopened the battery stats and... all battery stats of the entire day were just gone. That's creepy. And for now, I don't have any evidence it'll show stats for the new day either. Edit: the stats just came back after 2 hours or so, really strange. And yes, all 2 hour blocks now show "less than a minute" for Mindwtr's background use. |
|
Thanks, that is the result I was hoping for. Under a minute per two-hour block is the job waking, checking the server, and going back to sleep. I am marking the background sync work on this thread as confirmed. The day of missing stats is Android's doing. The battery screen reads the system's battery-stats store. Android resets that store on its own schedule and rebuilds the chart in two-hour steps, which fits it reappearing after about two hours. An app cannot read or write that store, so nothing in Mindwtr can clear it. |
|
I didn't mean it like Mindwtr had anything to do with it, I just meant that I couldn't check the data again right before wanting to post the results here. (And perhaps Claude could give some insight into this strange Android behavior of disappearing then reappearing stats, because a regular search didn't turn up anything.) |
|
Understood, I read it as a heads-up. What I know about that screen: Since Android 12 the Settings app draws the Battery usage screen. Settings runs an hourly job that copies the framework's battery counters into its own small database, and it builds the 24-hour chart from those copies, two hours per bar. The per-app list under the chart is the difference between two copies. Two things make it go blank. First, a reset of the framework's counters: Android clears its "since last charge" battery stats when the phone reaches a full charge, and a reboot or a clock change does the same. Settings then measures every earlier copy against a baseline that no longer exists, drops the bars it cannot compute, and starts again from the next two copies, which takes about two hours. Second, Settings itself: the hourly job is an ordinary scheduled job, so Doze can delay it, and the screen also shows nothing while its data load is still running or right after the Settings process was killed and its cache is cold. In that case the history comes back as soon as the job runs again. You can tell the two apart by what returned. The whole day back means Settings had the copies all along and only failed to render them. Only new bars means the counters were reset. Either way it is the Settings app's bookkeeping. The framework's per-app numbers behind it are what |
|
We still don’t have enough beta testers, which means issues are making their way into stable releases. I’m completely tied up right now fixing problems related to the new encryption feature and trying to keep the stable release reliable. |
Not built in today. The sync document is plain JSON and attachments are ordinary files, so what you get at rest is whatever the device, server, or provider gives you: