Define a Centralized Model for Encrypted File and Folder Actions

[alperozturk96]

Issue

End-to-end encrypted (E2E) files and folders require different handling rules compared to regular files and folders. Certain actions that are available for normal content (e.g., client integrations, Office integrations) may not be compatible with encrypted files or folders.

Currently, applications do not have a centralized way to determine which actions are allowed or restricted for encrypted files and folders. This creates inconsistencies across current and future applications, as each app may implement its own logic and validation rules.

This may cause issues in web or client applications, such as displaying actions that are not valid or supported for E2E encrypted content.

How can we centralize this?

@tobiasKaminsky @susnux CC

Screenshots

Folder actions	File actions

[susnux]

Currently its the applications task to check this in their enabled callback.
Like

{
  // rest of action
  enabled({ context }) {
    // other logic
    if (context.attributes['e2ee-is-encrypted']) {
      return false
    }
  },
  // ...
}

Most actions should work fine as we have transparent encryption around WebDAV APIs.
But when applications require backend access to the files - like office - then it will not work.

But it seems we now have adjust most applications to handle this correctly, just office and AI assistant seems to be missing.

---

Just Monday we internally already started some discussion about whether it makes sense to allow some kind of allow-list approach instead of deny-list (enabled defaults to allow except some condition is not met, while for e2ee it seems a default deny would be more helpful).