New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Option to turn off filename encryption and directory obfuscation/flattening #2595
Comments
I second this very much. :) |
This is the only thing stopping me from switching to this product! |
Migrating from flat to hierarchical structure (required for cleartext names) may be risky. So this might require us to publish a 2.0. |
Maybe it's possible to merge https://github.com/mozonyms/cryptomator, with adjustments if necessary? As far as I'm aware, the core feature of that fork is to provide a vault option that disables file name encrpytion. Not sure whether it also touches hierarchy, but I'd assume that. |
We know how to do that, that's not the issue. But we have to think about a lot of things. It's not just adding a simple checkbox and calling it a day. We have to think about API compatibility in our libraries, reducing complexity instead of adding it for security reasons, usability so that new and existing users aren't confused, making sure that the mobile apps follow along, third-party apps that are compatible with Cryptomator, updating our documentation and security architecture, and so on and so forth. |
I'll sign up to beta test it. |
I think it can be very useful too to have a menu on Mac like Boxcryptor where the user can right click on a file or folder an has the option "Show original file/folder in iCloud" so that the user will be navigated to the encrypted file in the iCloud. This is very useful if the folder or file is offloaded or I want to offload these files/folders to save storage on my device |
I'm also currently looking for an alternative to Boxcryptor and would love to use Cryptomator. However, I'm heavily relying on partial synchronization, because the data I'm storing in my cloud exceeds the disk space of my laptop by far. With Cryptomator not offering a way to keep the folder-structure and file-names intact, I'm unable to use the online-only feature of most cloud providers, because I simply don't know which parts to download and which not - and this in turn makes Cryptomator unusable for me right now. I would strongly be in favor of allowing users to disable filename encryption and folder obfuscation (maybe not as default), while accepting the security implications. |
While filename encryption and folder obsfucation is preferrable in general, with cloud services often having extensive versioning functionality, I personally would prefer cleartext filenames and directories. |
With Boxcryptor abandoning its existing clients this month, there must be many of us looking for alternatives - lack of unencrypted file/foldername and hierarchy is holding me back from embracing your tools |
Please don't expect the fulfillment of this feature request by the end of this month, just because an unaffiliated company gets acquired and ends its services abruptly. It's not realistic for Cryptomator to change its core design in such a short time. It's not our responsibility. We're doing the best that we can to improve our software, as we've done it for many years. We'll share our roadmap and vision of Cryptomator soon. We welcome feature requests but please manage your expectations. |
I understand now this is a contentious issue and will make my decisions accordingly - needless to say, you might be able to retain those disaffected boxcryptor customers with some guidance that would indicate support for this feature in the near term - these events are rare when many potential new customers are searching for alternatives at the same time. |
I second the feature request. I believe BoxCryptor was simply adding a .bc extension to the files/folders when filename encryption was turned off. Not only does this make sync notifications meaningful, it also improves usability of core cloud storage features, including file version history & the ability to restore deleted files. Both basic operations kind of require that you know what the filename is. I’d be more than happy to test. I would even be willing to pay for an official version that includes this feature. thanks and keep up the good work! |
I'm also migrating from Boxcryptor and this feature is also very critical to me. |
Yes, it's actually already implemented in #2592 and will be part of the 1.7.0 release, which is hopefully due soon. (Maybe a beta version will follow today or tomorrow, let's see.) |
Great. Thank you. Looking forward seeing it. |
I like obfuscation for certain vaults, but I would like to have a choice. Looking forward for the feature to see file/folder names in clear text. I understand it will require a lot of effort from you guys. I appreciate it and wish you to make it working smoothly. I am prepared to donate again once it will be available. I believe many of us will do the same. |
I agree, I am also willing to donate/pay for this feature |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
Keeping the filenames helps to control the synchronisation control over the cloud. If a sync issue happens, the obfuscated filename is no help. I used real names of files with Boxcryptor, and this feature helped me many times to sort out issues. Giving the user to decide whether to obfuscate the filename or not is the best way. The user can decide based on the risk if the filename is also very critical. The developer can still define the default value and give the link with more information to the user about this option. |
Is this being worked on still? Is there an expected ETA? |
+1 |
As a former Boxcryptor user, I switched to Veracrypt because of the lack of unencrypted folder names in Cryptomator. I would be very happy to switch to Cryptomator as soon as this feature is provided. I would also pay for it. |
What is your use case and how does VeraCrypt solve it? I don't understand how no folder names is better than encrypted folder names. |
does anybody know if |
Nobody ever said that this is being worked on. There is no ETA. |
Disappointing to hear, but thank you for at least updating us that there is no intention to implement this feature. |
I didn't say that, either. It's just not being worked on right now. As I've said, this feature would be appropriate for a future major release (something like Cryptomator 2 on Desktop). But there is no development activity for it at the moment. |
Aww, that's very bad news. :( |
Very disappointing news for me as well. Such important feature... and just thrown on a shelf... |
I understand the disappointment and I know where it comes from. Sorry for being so brief and harsh.
I may have set wrong expectations here. If you look into our vault format history, we try to rarely change it because we have to ensure compatibility not just with our apps but also with third parties. Every change means a lot of work for a lot of people (across many applications and platforms). We're not talking about some months but many months or even years.
I'm sorry for not fulfilling this promise. We're struggling with sharing a roadmap because it requires for our whole team to just stop working and then focus on writing something that everyone can look up by investigating our milestones and projects (this is only for the "main" repository and we have many more). We'll think of a better solution for sharing our roadmap that doesn't require us to write blog posts. And what did I mean by "vision"? Our goal is to standardize the vault format so that it becomes vendor-independent. We are collaborating with other well-known FOSS product owners that share this vision. And yes, making it an option to turn on/off filename encryption is obviously already part of this new format. There is a certain risk to this endeavor, but hopefully we can share some progress at some point. As you can see, it's hard for us to justify putting work in something like a vault format 9 if we'd have to throw it all away again, since we're already working on this "new" format. That's all I have to say for now. Hopefully, you understand the core design and principles of Cryptomator and also where Cryptomator might be heading in the future. |
I'd support this request :) |
I also hope to have this feature. |
Thank you so much for this project and your work. Without cryptomator, the world would be much less secure :-). I just want to add my use case to this feature. I would like to use OneDrive's partial synchronization feature. OneDrive will download files on demand by default, therefore needing an internet connection to access the files and introducing a delay before the file can be accessed. It is however possible to select files and folders that should always kept locally and in sync. I leverage this feature to save space, making sure to always have offline copies of files and to reduce synchronization noise. It is not feasible to split my containers accordingly, as what's synched changes over time and is different for all devices. |
You can test this app. This app has the option to encrypt file names or not. |
Keeping an eye out for this since I just moved off of Boxcryptor. |
I have a corporate licence for BoxCryptor until the beginning of 2025 and currently for some files folders I use filename encryption and for some not. Overall I find this feature crucial. At the moment there are 3 types of files stored on Nextcloud:
*Work files stored locally on computer are fully encrypted. Thank you all the Cryptomator team for working on a great application and service. Will be switching to Cryptomator Hub by the end of this year and continue doing tests meanwhile. |
If unencrypted file names are something you need, I would find another solution. Check the date of this original request and see the replies above. |
Please agree to the following
Summary
The vault structure doesn't represent the user's file and directory structure 1:1 due to security concerns. But the downsides affect the user's ability to handle backups and versioning and other potential cloud storage provider services with encrypted vaults efficiently. Users should be enable to find their own balance between security and usability.
Motivation
The architecture of Cryptomator includes file name encryption, and directory flattening/obfuscation.
There are some advantages to this like:
However this also introduces several usability issues and disadvantages like
For some users the disadvantages will outweigh the perceived added extra security layer.
Therefore there should be an option for users to turn off filename encryption and directory obfuscation, allowing them to work seamlessly with a vault directory directly, like they are used to on local filesystems.
Example implementation (as long as it existed): Boxcryptor
Considered Alternatives
It also should be noted, that obfuscation is generally not considered a good security mechanism, so while filename encryption might have some obvious use cases, it remains to be shown what type use cases/protection requirements directory obfuscation will solve.
Anything else?
Boxcryptor is an example where usability/UX was honoured very well and which might serve as a blueprint.
Eg on Mac it even allowed for an option to support Spotlight on decrypted virtual filesystem.
Due to its way to handle filename encryption on demand it even offered users the ability to obfuscate filenames as needed for single files/directories or for everything, providing a perfect balance for security needs vs usability.
Related to
#101 (comment) (but adds directory handling, too. Closed in favour of...:
#336 (comment) (but this one in it's current state is only targeting a very small subset of requests not handling the bigger picture as described here)
#236 (comment) (this is a request for handling versioning within Cryptomator itself. This request however allows users to use their versioning solution of choice and not enrich Cryptomator with features of other applications or to raise complexity)
The text was updated successfully, but these errors were encountered: