Security & Data Privacy
Iristick.Assist is built on a privacy-first architecture. All audio and video flow directly between devices. Nothing passes through Iristick servers. Nothing is stored. This page explains how that works.
Architecture: Peer-to-Peer by Default
Iristick.Assist uses WebRTC, an open standard for real-time communication. Once a session is established, media streams flow directly between the field worker's device and the remote expert's device.
Iristick's role is limited to session setup only:
- Signaling. Clients exchange session metadata (SDP) through the Iristick signaling server to find each other.
- ICE candidate exchange. The clients work out the best route for a direct connection. If firewalls block direct access, STUN/TURN servers help establish the path.
- Peer-to-peer media. Once connected, encrypted audio and video flow directly between devices. Iristick is no longer involved.
flowchart LR
A[Field worker] -->|Signaling only| B[Iristick Server]
C[Remote expert] -->|Signaling only| B
A <-->|Encrypted P2P media| C
STUN/TURN servers
When direct connections are blocked by network firewalls, STUN/TURN servers relay the traffic. Even in this case, all media stays end-to-end encrypted. The relay server cannot read the content.
Connection Establishment Step by Step
The sequence below shows what happens when a session starts. Signaling carries only the metadata the two devices need to find each other. Once the peer connection is up, audio and video take the direct path.
sequenceDiagram
autonumber
participant A as Fieldworker app
participant S as Iristick signaling server
participant B as Expert browser
participant T as STUN/TURN server
A->>S: Create offer (SDP)
S->>B: Send offer (SDP)
B->>S: Create answer (SDP)
S->>A: Send answer (SDP)
A->>T: ICE candidate exchange
B->>T: ICE candidate exchange
A->>S: Send ICE candidates
S->>B: Deliver ICE candidates
B->>S: Send ICE candidates
S->>A: Deliver ICE candidates
A->>B: Establish peer connection
A->>B: Start media stream (audio/video)
B->>A: Start media stream (audio/video)
When a firewall blocks the direct path, the handshake is identical but the media runs through a TURN relay. The relay forwards encrypted packets it cannot read, so the call stays end-to-end encrypted either way.
sequenceDiagram
autonumber
participant A as Fieldworker app
participant S as Iristick signaling server
participant B as Expert browser
participant T as STUN/TURN server
A->>S: Create offer (SDP)
S->>B: Send offer (SDP)
B->>S: Create answer (SDP)
S->>A: Send answer (SDP)
A->>T: ICE candidate exchange
B->>T: ICE candidate exchange
A->>S: Send ICE candidates
S->>B: Deliver ICE candidates
B->>S: Send ICE candidates
S->>A: Deliver ICE candidates
A<<->>T: Establish peer connection
B<<->>T: Establish peer connection
A->>T: Start media stream (audio/video)
T->>B: Start media stream (audio/video)
B->>T: Start media stream (audio/video)
T->>A: Start media stream (audio/video)
Network Requirements
Assist needs a path for the direct peer-to-peer connection. On most networks this works without any change. On a corporate network with an outbound firewall, IT needs to allow the following.
| Purpose | Protocol and port | Required |
|---|---|---|
| STUN/TURN, establishing and relaying the media path | UDP 3478 | Yes |
| Fallback when UDP is blocked, and all signalling | TCP 443 (HTTPS/TLS) | Yes |
UDP 3478 carries the direct path and gives the best call quality. When a network blocks UDP, Assist falls back to 443 and the call still connects. Media stays end-to-end encrypted either way, but the extra hop costs some latency. Opening UDP 3478 is the difference between a call that works and one that works well.
No inbound ports need to be opened. All connections are established outbound from the client.
Room Access Control
When a remote expert joins a room, the session is locked automatically. No additional participants can join unless explicitly invited by someone already in the call. This prevents unauthorized access to active sessions.
Encryption
Media (audio, video, photos)
All media is encrypted using DTLS-SRTP with ephemeral keys:
- A unique encryption key pair is generated for each session
- Keys exist only on the two connected devices
- Keys are destroyed immediately when the session ends
Nobody can decrypt the media stream, including Iristick.
Signaling
All signaling data exchanged during session setup is protected with HTTPS / TLS 1.2+.
Zero Storage
Iristick.Assist stores no media. Ever.
| What | Stored on Iristick servers? | Stored on devices? |
|---|---|---|
| Audio | No | No |
| Video | No | No |
| Photos taken during a call | No | Only during the active session |
| Signaling metadata | No (transient only) | No |
Download photos before ending the call
Photos captured through the smart glasses during a session are transmitted directly to the expert via WebRTC. Once the call ends, all photos are immediately and permanently deleted from both devices. Download any photos you need before disconnecting.
Data Collected by Iristick
Iristick collects anonymous usage data only for abuse prevention and service improvement:
- No personally identifiable information
- No location data
- No device IDs
- No profiling, advertising, or resale of data
All usage data is stored and processed within Europe.
Infrastructure
| Component | Managed by | Protected with |
|---|---|---|
| Signaling server | Iristick | TLS 1.2+ |
| STUN/TURN servers | Iristick | End-to-end encryption (DTLS-SRTP) |
| Media routing | None, direct P2P | DTLS-SRTP with ephemeral keys |
Development, staging, and production systems are strictly separated to prevent unauthorized access or data leakage.
Comparison with Iristick.Teams
Looking for the Teams security model? Iristick.Teams uses a different architecture based on Microsoft Azure Communication Services. See Iristick.Teams Permissions, Data & Security.
| Iristick.Assist | Iristick.Teams | |
|---|---|---|
| Connection model | Peer-to-peer (WebRTC) | Azure Communication Services |
| Media through Iristick servers | Never | Never. Always through Microsoft Azure Communication Services. |
| Data stored by Iristick | Anonymous usage data only | User info + call summaries |
| Encryption | DTLS-SRTP (end-to-end) | TLS 1.2+ (in transit), AES-256 (at rest) |
| Authentication | Room-based, no account required | Microsoft Entra ID via MSAL |