cryptomator
Finder tags stripped when moved in iOS
Basic Info
- I'm running Cryptomator 1.1.5 (360) on iPhone 6S+ iOS 9.3.2
- Desktop Cryptomator 1.1.3 on OS X 10.11.5
Description
- Add a colour tag / label to a file in OS X finder
- Move that file in Cryptomator iOS
- When file re-syncs to the desktop, the finder tags are stripped.
I'd guess any other extended attributes are also lost. If Cryptomator is using WebDAV, the iOS app may be ignoring the ._ files that the Finder uses for xattr.
That's quite an interesting find! Thanks for reporting! Basically, what should be done: Look for a ._ file and move it alongside the actual file. I'm thinking about possible unwanted side effects, but I hope it's safe to implement such algorithm.
It probably relates to how WebDAV is handled in OS X. If the switch to FUSE is made, extended attributes handling will need to be examined.
Extended attributes are possible with fuse but currently not planned for the first release.
If we support extended attributes we will have to discuss how to store them on the encrypted drive. Passing them through unencrypted is not an option in my opinion because information about the file may leak this way. In addition programms could use an extended attribute itself to store information that is sensitive.
Right now extended attributes are likely stored in ._ files which can be encrypted like any other.
Moving to FUSE without also bringing along at least the current level of Finder tags etc. supported by WebDAV could be a potential metadata loss situation for macOS users. A decision like that should be taken carefully and users should be heavily warned.
Ideally xattr support could be written along with the FUSE transition so that no metadata is lost and there is no functionality regression.
On Friday, 15 July 2016, Markus Kreusch [email protected] wrote:
Extended attributes are possible with fuse but currently not planned for the first release.
If we support extended attributes we will have to discuss how to store them on the encrypted drive. Passing them through unencrypted is not an option in my opinion because information about the file may leak this way. In addition programms could use an extended attribute itself to store information that is sensitive.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/cryptomator/cryptomator-ios/issues/57#issuecomment-233064127, or mute the thread https://github.com/notifications/unsubscribe-auth/AD85x0swOD7FAq7yq4XtzaUpx4sCjHp9ks5qV_AIgaJpZM4JNrBg .
Good point.
Didn't think about the implications of finder using ._ files for xattrs right now when using WebDAV. So "accidentially" we support xattrs on macOS now which never was intended (on linux and windows I think we do not, but will have to check if similar mechanisms exist there).
Encrypting xattr names and values themselves is not possible because the underlying file system used for the encrypted files (which may be a webdav share as well) or cloud provider must support xattrs in this case and we can not rely on that.
In general we could, as done by macOS, store xattrs of an encrypted file in a second encrypted file with a name pattern or similar. This introduces additional problems regarding sync conflicts (when two encrypted files which thogether represent the full state of the unencrypted file are placed in a cloud drive then sync conflicts could cause a "partial conflict" of the file leading to missing xattrs for a conflicting file). But as macOS seems to place xattrs in a second file at the moment and we never hat such problem this does not seem to be common. Maybe we can just ignore this but should at least think about it. Will think about this when implementing the FUSE filesystem and see what we can do.