Security
Security and known limits.
ronova.dev uses practical security controls. The notes below describe what they cover and where their limits remain.
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 Renkan 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.
Standard network metadata may still exist outside these controls. Share access codes only with their intended recipients, and keep a local copy when you need one.