No Google Play. Syncthing + sdcard = secure?

I don’t have Google apps on in of my devices. The other one has MicroG. I love that I can buy a license direct form Cryptomator.

Just one thing I’ve noticed about Android 10 and 11:
permission to access the sdcard is all or nothing. Thus, to grant cryptomator and syncthing sdcard access, that would be mixing with any app that wants to read/wrote to the sdcard.

Would cryptomatorprotect against this cross sdcard security issue?

Hey and welcome to the Cryptomator Community :slightly_smiling_face:,

The answer to this question highly depend on the security issue you referring to. In general, scoped-storage was introduced to Android in order to be able to granularly determine which folders, for example, the torch app is allowed to access. The main aim is to prevent this app from analyzing data, for example, without any benefit for the user or without the user being aware of it.

Cryptomator acquires this permission, for example, for the auto image upload. If an image file is stored somewhere, this image can be captured and uploaded. Cryptomator only saves files to the SD card if they are explicitly exported and the SD card is selected as destination. Otherwise, no data will get into the SD card that could be used by other apps that have also been granted this permission.

If you don’t trust Cryptomator itself, and since your vault is in the local storage from Cryptomator’s point of view, you can revoke the internet permission of the Cryptomator app so that even if Cryptomator would do something with your data, it would not be able to send the results.
Also, the app is open source, so another option would be to study the source code: GitHub - cryptomator/android: Cryptomator for Android

Got it. I trust Cryptomator. I trust syncthing. I also trust a notes app called ObsidianMD that accesses shared storage. I’m happy to give all of them full shared storage access.

What I don’t trust is other apps that I install to test, keep for a while and then later uninstall.

Those other apps are the risk I need to protect against.

All files encrypted with Cryptomator are protected against these apps. In case the vault is on the SD card or the internal storage of the phone and these apps also have the storage permission, they could access the encrypted data and could try to decrypt files, but I wish those apps a lot of fun with that :joy:…as long as you have used a good password, it currently lasts for decades to “forever”, not to mention the electricity that would be required…

I appreciate your help. This is sounding better. I thought Cryptomator was just for keeping things private in the cloud. To be able to keep things private between apps as well would be fantastic. Seeing that data is encrypted at rest is great too.

One thing I don’t understand though:

How does Cryptomator give access access to the unencrypted data to one app but not another?

For example: How does Cryptomator pass the unencrypted data to a folder based app like ObsidianMD without allowing other apps access to those files?

Putting it another way:

Sorry to ask the same question so many times but I have to be sure before I buy and recommend it as a solution for ObsidianMD and similar apps.

That’s an interesting question. Let me explain a bit:

If you open a file using Cryptomator for Android with an external app like Keepass, we share a link to a temporary copy of this file using a ContentProvider with the selected app. Before we share the link, we downloaded, decrypted and saved this file as temporary file to the internal storage of Cryptomator for Android on which only Cryptomator for Android have access to (internal storage is part of Android’s sand-boxing model). After that, as already mentioned, we share the link to this file using the content provider to the user selected app and only to this app.
As soon as we return to Cryptomator, we revoke the permission of the external app to access the file. If the vault has not been locked in the meantime, we check whether the file has been changed. If so, we publish these changes back to the cloud.
As soon as possible we delete the temporary file in the internal storage and also revoke the permission of the external app to access the file when the vault gets locked.

Side note: What the external app does with the contents of the file while the app has access to it is beyond our control. You should only open files in apps you trust - but that should be obvious.

I bought Cryptomator but sadly the other app doesn’t support Cryptomator:

also, from:
"The two biggest roadblocks are:

Scoped storage performs many extra permission checks for every single file access, causing significant performance degradation when opening and using Obsidian.
Scoped storage does not provide a way to watch for external changes, which is critical when using Obsidian with a third-party synchronization tool.


I think I understand now. Document Provider needs to be supported by Cryptomator? But also there’s something that needs to happen at the ObsidianMD end as well, I think?

I’m confused by Cryptomator, cloud sync and this Android app: ObsidianMD. I’m not sure if Cryptomator can help prevent apps on Android from reading Obsidian’s files that are in shared storage?

Can’t post this link. You will have to copy and paste it: fr-make-obsidian-work-on-android-without-asking-for-storage-permissions/19360/7

[quote=“Andrew1, post:285, topic:471”]
Android has poor controls over what accesses the sdcard storage space and plenty of other apps need access to the sdcard

Android actually sandboxes app data nicely, see Android Security Blog: Application Sandbox :

> In Android 10 apps have a limited raw view of the filesystem, with no direct access to paths like /sdcard/DCIM. However, apps retain full raw access to their package-specific paths, as returned by any applicable methods, such as Context.getExternalFilesDir.

However my current recommendation would be to not keep sensitive data in Obsidian but use other tools for that (such as Bitwarden) and also be judicious in which apps you install.

Yes, if Obsidian is something like an sync client, they need continuous access to the vault content and need the document provider for this.

1 Like

From my view,

android’s cryptomator protect a vault that ALMOST only ctmt can read/write/access;

the files inside could not be touched by other apps except using ctmt to share to them;
in that way the file is copied away, and seldom the file could be write back to the ctmt vault.

the authors of ctmt claim it’s due to lacking of document provider and this feature got delayed again and again.

at this moment, i really don’t see any usefulness of ctmt.

however, honestly it’s because google wants to arm race /w other authors;
so mostly other solution providers also suck in this way.

all are BS

so mostly other solution providers also suck in this way.

Not true. Most other cloud storage providers implement this feature flawlessly. IceDrive, OneDrive, Dropbox, etc, etc, all implement a document provider so you can access the files and directories from other Apps and/or the OS.

Sadly, this software is useless because the Crypromator team has repeatedly promised, delayed, and failed to prioritize this essential feature for many years, and worse their recent posts suggests that their software architecture requires an major overhaul in order to implement it :fearful:. Moreover they do not provide full transparency by not providing a trial or full disclosure up front. So people have to find out the hard way (by paying for it and/or stumbling on posts like this one) that the Android app doesn’t work like the desktop version.

those you mentioned are UNencrypted.

so far i didn’t see one encrypted + full document provider.

the only one i hoped with, is the money bought up boxcryptor.

all hopes are gone.

however, this is common in android + foss world.

think it that way:

in desktop world, windows OR linux desktop do give you encryption + file access. (ctmt unstable at first, better now after winfsp)

Any news on this? Do you know an alternative app? I think Google added a full drive permission lately, so maybe that’s a workaround? Or not?

Quite possibly related: Android 11 (API level 30)'s Scoped Storage/MANAGE_EXTERNAL_STORAGE would seem to indicate no issue if the vault folder is located within Downloads. It may be somewhat untidy but it should be functional. The media permission seems better suited however.