End-to-End Encryption and Communications Security Notice

A feature-specific explanation of what SYNC protects, what RABC can process and where protection has limits.

7.1 Meaning of message E2EE

For a supported E2EE message, the sender’s compatible app encrypts Content before transmission and the intended recipient device or devices decrypt it. RABC’s delivery systems handle encrypted envelopes and do not hold the private message plaintext in ordinary operation. E2EE is a technical protection, not a promise that a recipient, compromised device or external copy cannot reveal the Content.

Encryption protects transmission and storage only within the stated feature and supported security state. It does not prevent an intended recipient from reading, recording, photographing, copying, forwarding, exporting or reporting Content, and it cannot protect plaintext displayed on a compromised or unlocked endpoint.

7.2 CHAT

Supported direct CHAT messages, supported group messages and compatible media use message E2EE in supported app versions. RABC may process the verified phone Account, device and public-key material, group membership, routing, timestamps, delivery state and encrypted payload information required to operate the feature.

7.3 CONVERSE

Supported direct and group CONVERSE messages and compatible media use encrypted message envelopes in supported app versions. The verified email address is the CONVERSE identity and remains available to RABC for authentication, routing, safety and account administration. CHAT and CONVERSE security state and local data remain separated by Account channel.

7.4 Groups

Group E2EE protects supported message Content from routine server plaintext access, but group membership, roles, identifiers and delivery events may be processed. Every participant who can decrypt a group message can copy, report, screenshot or disclose it. Removing a member protects only future access as supported by the key and membership controls; it cannot erase copies already received.

7.5 Media and files

Compatible media and files sent in supported encrypted conversations may be encrypted before upload, with encrypted references delivered through the message protocol. Thumbnails, file type, size, delivery status and other limited technical data may still be processed. A copy saved to the device gallery, exported, opened in another app or backed up elsewhere is governed by the destination’s protection.

7.6 Direct calls

Direct one-to-one calls use encrypted WebRTC media transport. Call signalling and metadata are processed to connect the participants, and relay infrastructure may forward encrypted packets when a direct network path is unavailable. RABC does not describe this as an unlimited guarantee identical to stored-message E2EE and does not promise protection from a compromised endpoint or recipient recording.

7.7 No group-call E2EE claim

Version 1.0.1 makes no claim that group audio or video calls are end-to-end encrypted or available for public launch. If group calling is introduced, the call screen and a later notice must state the media architecture, relay or SFU role, recording position and encryption scope before Users rely on it.

7.8 Features outside private-message E2EE

Profiles, handles, contact discovery, group names, channels, broadcasts, official SYNC communications, legal notices, reports, grievances, privacy requests and information deliberately submitted to RABC are outside the private-message E2EE promise. A feature is not E2EE merely because it is delivered over HTTPS or encrypted transport.

7.9 Metadata

E2EE does not hide all metadata. RABC may process Account identifiers, devices, public keys, sender and recipient identifiers, group membership, message identifiers, time, routing, delivery status, call status, file characteristics, IP and security events. RABC applies minimisation, access control and retention requirements to this information.

7.10 Reports

When a participant reports a selected message, the app may provide that Content and relevant context in readable form to authorised RABC reviewers. Only the selected reported material and necessary context should be submitted. This does not unlock unrelated conversations or create a general encryption backdoor.

Before submission, the reporting flow should identify the selected material and explain that it will leave the ordinary private-message E2EE boundary for authorised review, evidence preservation and lawful action. The report should transmit only the selected evidence and the context reasonably needed to assess it.

7.11 Keys, devices and security changes

Private encryption material is generated or stored on authorised endpoints as designed by the application. Supported versions may display a security warning when a contact’s identity key changes and may require verification or explicit acceptance before silent trust resumes. Adding, replacing, resetting or losing a device can change keys and may affect access to earlier Content.

A User should treat an unexpected identity-key or device change as a security event until reasonably verified. RABC may require renewed verification, hold delivery or warn participants where the released protocol detects a material change. No recovery process can guarantee restoration of Content whose decryption material has been securely lost and is not held by RABC.

7.12 Backups and exports

An encrypted local or cloud continuity feature may have a protection model separate from live message E2EE. RABC will not claim that a backup is E2EE unless the feature states who controls the key and RABC cannot access plaintext. Device backups, screenshots, notification previews, exports and media saved outside SYNC may be readable by the device owner, operating system, recipient or external provider.

7.13 Lawful requests

RABC will disclose lawfully available Account information, metadata, reported Content and other records under valid legal process as described in the Law Enforcement and Government Request Guidelines. RABC cannot provide private-message plaintext that it does not possess and will not create a standing government or third-party backdoor. A legally applicable first-originator obligation does not itself require disclosure of message Content or unrelated Users.

7.14 User security duties

Use a strong device lock, keep the app updated, verify unexpected key changes, protect OTPs and email or SIM access, review linked devices, avoid untrusted software and report compromise promptly. Do not assume that disappearing Content, deletion, encryption or blocking prevents a recipient from retaining information already received.

7.15 Security contact

A suspected Account or encryption compromise may be reported to compliance@rabcorp.co.in. A privacy question must use privacy@rabcorp.co.in; abusive Content must use the in-product report or grievance@rabcorp.co.in; child-safety material must use childsafety@rabcorp.co.in. Do not email private keys, OTPs or unnecessary private Content.

Version integrity and public contact summary

This coordinated Pack is Version 1.0.1 with version date 7 September 2026. The effective date for a User is determined by the commencement rule at the beginning of the Pack. RABC will retain the released text and its content hash so that the version presented to an Account can be reproduced. A later legal change must not overwrite this immutable version.