CipherDrive™ may encrypt selected metadata such as filenames before storing it. Whether a particular filename is protected can depend on the active client version, feature support, migration state, and object type.
If filename encryption is enabled for a given object, Ackaia is not expected to see the plaintext filename after client-side encryption.
A typical encrypted filename payload can include:
a protocol version;
an IV;
ciphertext;
an authentication tag.
A cloud drive still needs some operational metadata to function. Ackaia may need to know information such as:
whether an object is a file or folder;
how much encrypted storage it uses;
where it belongs in a folder hierarchy;
whether it is shared;
which account owns it;
relevant timestamps or object identifiers.
For that reason, CipherDrive does not claim that all metadata is always hidden.
Operational metadata can reveal facts about activity even when content is encrypted. File sizes, timing, folder relationships, object types, sharing state, and transfer activity can still provide contextual information.
CipherDrive's design goal is to minimize unnecessary plaintext exposure and document what remains visible.
Even where filename encryption is supported, it is good security practice not to rely on a filename as the only place where sensitive context is protected. Metadata protection can vary by client, feature, migration state, or future compatibility requirements.
Selected folder metadata may also be protected where supported, but the same limitation applies: structural relationships and other operational metadata may remain visible because the service needs them to represent the drive hierarchy.
Best mental model: file content receives the strongest zero-knowledge boundary; metadata protection is additional and selective rather than universal.