Security

Security, with honest boundaries.

ronova.dev uses practical protections, but it does not pretend that the public web can offer perfect secrecy.

Support messages are encrypted in the browser before storage so the message body and optional contact field do not need to remain readable on the server.

Community messages use browser-native encryption with device keys kept locally. Before creating or joining a room, the browser checks its E2EE and local key-storage path; a missing hard prerequisite blocks the action, while an unavailable persistence grant requires explicit confirmation. Direct requests can address a Ronova ID or its virtual address, but recipient approval is required before room, device, or ciphertext access. v1 does not claim forward secrecy, key transparency, cloud recovery, multi-device history recovery, or protection from a compromised client.

Private pages are protected at request time behind access codes and scoped sessions. They are not shipped as unlocked content inside the public frontend bundle.

No public-contact or private-access flow should be treated as an absolute guarantee. Share access codes carefully, keep your own local records when needed, and assume that basic network metadata can still exist.