Trust & Security
This page summarizes how iCallU.online protects communication, what we claim, what we do not claim, and where you can verify details (threat model, E2EE design, logging policy, and demos).
At a glance
- Privacy-first: designed to minimize data collection and reduce retained data.
- WebRTC transport: real-time audio/video uses standard WebRTC security (DTLS-SRTP).
- Optional E2EE: on compatible browsers, media can be end-to-end encrypted (see E2EE design).
- No ads / no tracking: no tracking pixels or third-party analytics (see privacy-by-design).
- Transparent docs: public threat model, logging policy, and crypto demos.
Last updated:
Security guarantees
These are the core "what we try to guarantee" statements. Details and definitions live in the pages linked below.
- Transport security by default: WebRTC uses encrypted media transport (DTLS-SRTP).
- End-to-end encryption: when enabled and supported, only call participants can access media.
- Data minimization: the system is designed to avoid retaining call content and avoid tracking users.
- Verifiability-first: we publish assumptions, limits, and building blocks so you can evaluate claims.
Limits (what we do not claim)
Clear limits help users evaluate real risk. For the full list and threat boundaries, see the threat model.
- Device compromise: if a participant's device is compromised, confidentiality can be lost.
- Network availability: connectivity depends on the user's network; TURN helps but cannot fix all failures.
- Browser capabilities vary: E2EE depends on supported browser APIs and configuration.
Read: Threat model
How iCallU protects calls
1) Secure transport (baseline WebRTC)
Calls use WebRTC, which encrypts media transport by default using DTLS-SRTP. This protects audio/video in transit against passive network interception.
2) End-to-end encryption (E2EE)
On compatible browsers, iCallU.online can add an end-to-end encryption layer on top of WebRTC so only call participants can access media. Public signaling may relay coordination data, but E2EE is designed so session keys remain on user devices.
Read: E2EE design | Encrypted video call flow
3) Logging and data minimization
Security also depends on what is stored. iCallU aims to minimize retained data and avoid tracking. Logging policy explains what is logged and what is never logged.
Read: Logging policy | Privacy by design
How to verify (practical steps)
- Start with the Security hub to understand the model and navigation.
- Read the Threat model to learn the boundaries of what is (and isn't) protected.
- Review E2EE design for the high-level key agreement / derivation / AEAD approach.
- Check Logging policy for retained data commitments.
- Use Crypto demos to understand the primitives and tradeoffs in the browser.
- Optional: use user-verifiable checks where offered (SAS / fingerprints / verification guidance).
Public demos
These demos run in the browser and are separated from production systems. They demonstrate cryptographic building blocks (key agreement, HKDF, authenticated encryption) without exposing internal production logic.
- Crypto demos landing page
- E2EE primitives demo (key agreement, HKDF, AEAD primitives)
- Secure envelope demo (encrypted chat-style payload pattern)
Quick answers
Is iCallU end-to-end encrypted?
iCallU uses secure WebRTC transport by default, and offers E2EE for compatible clients. See the E2EE design page for the high-level model and constraints. Learn more.
Do you store call audio or video?
The system is designed to minimize retained data and avoid storing call content. Definitions and any exceptions belong in the logging policy and privacy documentation. Logging policy.
What can I personally verify?
Start with the threat model, then E2EE design, then logging policy. If verification guidance is available, use user-verifiable checks (SAS / fingerprints) where appropriate. Verifiability.