Hi EX Trial User,
You’re right in that there’s a “window of opportunity” when a file placed in a synchronized folder may be synchronized before being encrypted, and subsequently deleted from the cloud.
The reason we’re not encrypting it immediately as it appears, is that we ran into a lot of usability issues when we did it that way, due to the way AxCrypt interacts (or actually does not interact) with the operating system.
A simple scenario to illustrate the point:
– You open Word, write something, and save it to the secured folder.
– AxCrypt immediately encrypts it. This means the file “My Stuff.docx” disappears and a new file “My Stuff-docx.axx” appears.
This causes Word to become really confused, because it thought it just saved to that file.
In the future, we may implement a variant of the Boxcryptor technology with a kernel mode driver and intercept the actual file system calls. However, that increases the complexity very much and causes loads of other potential issues which I think users of such implementations will attest to.
We have some other ideas on how to retain our user mode integration model, and still avoid the issue you are describing.
In actual practise, the transient existence of a plain text copy in the cloud is not often the real problem. Nevertheless, you are right that it may indeed appear there if the cloud storage synchronization agent is efficient and fast.
