iCallU.online

Cryptographic Architecture

iCallU.online is designed to provide private, end-to-end encrypted real-time communication - video calls, audtio calls, and chat. This document explains the cryptographic design, server trust boundaries, metadata minimization, and how these claims can be independently evaluated.

Verifiable E2EE No tracking No stored call content Public documentation

Overview

iCallU.online privacy guarantees are enforced through cryptographic design and data minimization, not policy-based assurances. The system is architected so that call content remains accessible only to the communicating participants.

Cryptographic building blocks

iCallU.online uses well-established, publicly reviewed cryptographic primitives:

  • Key agreement: X25519 (Elliptic Curve Diffie-Hellman)
  • Key derivation: HKDF (SHA-256)
  • Media encryption: AES-GCM (Authenticated Encryption)
  • Integrity protection: AEAD
  • Randomness source: Operating-system CSPRNG via Web Crypto API

No proprietary cryptographic algorithms are used.

End-to-end encryption design

  1. Each participant generates ephemeral cryptographic keys locally.
  2. Public keys are exchanged via an authenticated signaling channel.
  3. A shared secret is derived using Diffie-Hellman key agreement.
  4. Session keys are derived using HKDF.
  5. Media is encrypted on the sender's device before transmission.
  6. Decryption occurs only on the recipient's device.

At no stage does iCallU receive or process unencrypted audio or video.

Server role and limitations

iCallU.online servers facilitate session establishment and encrypted packet relay. They are technically incapable of accessing:

  • Call media
  • Encryption keys
  • Decrypted communication content

Servers do not act as trusted endpoints for call confidentiality.

Metadata considerations

Like all real-time communication systems, iCallU necessarily processes limited metadata for delivery, including IP addresses, session timing, and temporary connection identifiers. No system can eliminate all metadata; iCallU aims to reduce it to the minimum required for functionality.

  • No advertising identifiers or cross-site tracking
  • No behavioral analytics or profiling
  • No sale of personal data
  • No persistent storage of call content or recordings

Ephemerality and key lifecycle

  • Encryption keys are generated per session.
  • Keys exist only in volatile memory.
  • Keys are destroyed when the session ends.
  • Call content is not retained after delivery.

Transparency and verifiability

iCallU.online documents its cryptographic architecture, threat model, and data-handling assumptions to enable independent assessment. Privacy claims are intended to be verifiable through technical analysis, not dependent on brand trust or corporate policy.

  • Review documented encryption flows and assumptions
  • Inspect client-side behavior
  • Observe encrypted network traffic (no readable media)
  • Evaluate claims against WebRTC E2EE standards

Regulatory alignment

iCallU is designed around privacy by design, data minimization, and technical enforcement of confidentiality, aligning with the principles of major privacy and security frameworks.

GDPR (EU)

  • Data minimization: no storage of call content or recordings.
  • Purpose limitation: data is processed only to establish and maintain real-time communication.
  • Privacy by design: encryption is enforced at endpoints, not dependent on policy promises.
  • No secondary use: no analytics, advertising, or behavioral profiling.

CCPA / CPRA (California)

  • No sale or sharing of personal information.
  • No advertising identifiers or cross-site tracking.
  • No behavioral analytics or profiling.
  • No retention of call content or communication records.

HIPAA (U.S. healthcare context)

iCallU.online is not a healthcare provider; however, its cryptographic and data-handling design aligns with core HIPAA Security Rule principles for protecting electronic protected health information (ePHI).

Technical safeguards alignment (45 CFR 164.312)

  • Access control (164.312(a)): call content is accessible only to participating endpoints through end-to-end encryption.
  • Transmission security (164.312(e)): audio and video are encrypted in transit using modern, industry-standard cryptography.
  • Integrity controls (164.312(c)): authenticated encryption helps detect tampering.
  • Minimum necessary principle: iCallU does not collect, store, or process call content or recordings, minimizing exposure of sensitive information.

Important clarification

iCallU.online does not claim to be "HIPAA certified" or universally "HIPAA compliant." HIPAA compliance is context-dependent and may require organizational controls and, in some cases, a Business Associate Agreement (BAA). However, iCallU.online is end-to-end encrypted and built on no-retention architecture that can support HIPAA-aligned use cases where persistent storage of ePHI is not required.

Accessibility (Section 508)

  • Plain-language explanations of cryptographic concepts.
  • No security information is hidden behind inaccessible formats.

FAQ

Can iCallU servers access call content?

No. iCallU.online uses end-to-end encryption for call content. Servers do not have access to encryption keys or decrypted audio/video.

Does iCallU store call recordings or call logs?

iCallU.online does not store call recordings or call content. Operational metadata required for real-time delivery is minimized and not used for profiling or advertising.

How can people verify iCallU's privacy-first claims?

iCallU publishes its cryptographic architecture, threat model, and data-handling assumptions. Users and researchers can review documentation, inspect client-side behavior, and observe that media traffic is encrypted.

Is iCallU "HIPAA compliant"?

HIPAA compliance is context-dependent. iCallU does not claim universal HIPAA compliance or certification, but its end-to-end encrypted, no-retention architecture can support HIPAA-aligned use cases where persistent storage of ePHI is not required.

Summary: iCallU enforces confidentiality at the endpoint (E2EE), minimizes metadata exposure, avoids tracking and advertising identifiers, and documents its security assumptions to support independent evaluation. Trust is derived from architecture, not reputation.