Appearance
Security & encryption
AuroraDocs combines local-first storage, AuroraCloud account security, role-based workspace access, and optional per-workspace end-to-end encryption.
End-To-End Encryption
E2EE is enabled per workspace from Settings → Data and encryption. When enabled, supported workspace content is encrypted on the device before it is synced. AuroraCloud stores encrypted payloads and encrypted key material, not readable workspace content.
Current unlock behavior is password-derived:
- your AuroraCloud login password is the normal unlock root for encrypted workspaces
- setup gives you a one-time recovery phrase
- if the password path fails, the unlock screen points you at the recovery-phrase path
- if both are lost, Aurora cannot recover encrypted workspace content for you
WARNING
Keep the recovery phrase outside AuroraDocs. It is the way back if your normal password-derived unlock path fails.
Locked Workspaces
When an encrypted workspace is locked:
- page content and protected metadata stay unavailable
- readable Markdown/HTML export is blocked
- hosted AI, server retrieval, and MCP cannot read locked content
- local folder watchers are restricted so encrypted files are not auto-imported or overwritten in the background
Unlocking happens on the device. The unlocked plaintext is available to the app session so you can read, edit, export, or intentionally send selected context to a BYOK provider.
Backups And Exports
AuroraBak backups (.aurorabak and .aurorabak-bundle) preserve encrypted workspace content as encrypted data. They are restore formats, not readable plaintext exports.
Readable exports such as Markdown or HTML are different. Aurora can create them only after the encrypted workspace is unlocked, and it warns because the downloaded files are plaintext outside Aurora's encryption boundary.
Multi-Member E2EE
Encrypted shared workspaces use per-member wrapped workspace keys so collaborators can be granted access without storing plaintext content on the server. Members still need valid workspace membership and an unlock path on their device.
Authentication
AuroraCloud account security includes:
- bcrypt password hashing
- short-lived access tokens and refresh tokens
- refresh-token replay detection
- strict JWT algorithm handling
- server-side session revocation
- optional authenticator-app TOTP or email OTP when policy allows it
- required MFA for elevated/admin roles
- recent security activity history
- suspicious-login alerts for new device profiles and broad new network areas
OAuth sign-in buttons for Apple, GitHub, Google, or Microsoft can appear when the AuroraCloud API host is configured for them. OAuth sign-in is separate from invite-code signup and encrypted-workspace unlock rules.
Workspace Access
Workspace roles are enforced by AuroraCloud:
| Role | Read | Edit | Manage members | Delete workspace |
|---|---|---|---|---|
| Owner | yes | yes | yes | yes |
| Editor | yes | yes | no | no |
| Viewer | yes | no | no | no |
Direct object shares, guest links, and published pages have their own access rules. Password-protected links require the visitor to enter the link password before content is shown.
Desktop Secret Storage
Desktop provider keys and similar device-only secrets are session-only unless you explicitly enable secure storage. When secure storage is enabled, Aurora stores them in the OS keychain: Keychain Access on macOS, Credential Manager on Windows, or Secret Service/libsecret on Linux.
Aurora does not silently downgrade desktop secrets into plaintext files if the keychain is unavailable.
Data Residency
AuroraCloud production is hosted on EU infrastructure. Files use private object storage and are delivered through AuroraCloud-controlled access paths.
Reporting A Vulnerability
Email contact@auroradocs.eu with the details. Please avoid public disclosure until there has been time to respond.