What is actually in the product
Every item below exists in the application as it ships. Where a control depends on how a deployment is configured, it says so.
Invite-only access
There is no public registration. An administrator issues an invitation to an address, and redeeming that invitation is what creates the account - which makes the invitation itself the proof that somebody controls the address. The framework's own registration endpoints are not merely unlinked: they answer as though they do not exist, for both GET and POST, signed in or not.
Multi-factor authentication
Time-based one-time codes from any standard authenticator application, with recovery codes issued once and stored only in hashed form. Enrolment is not complete until a working code has been entered, so nobody can lock themselves out by setting it up. Policy can require it of a role, and somebody it is required of is walked to enrolment before they can use anything else.
Session control
Every sign-in creates a session record carrying the browser, the operating system and the address it came from. Each account can see where it is signed in and sign any of those devices out. Revocation is observed on the next request rather than at the cookie's expiry, and an access token minted before a revocation stops working with it.
Suspension and revocation
An administrator can suspend or disable an account, and that takes effect on the account's next request everywhere it is signed in. Permissions are granted to roles as claims and checked through named policies, so a permission can be moved between roles without editing the code that enforces it.
Priveloq Vault
Selected conversations are kept out of the ordinary conversation list, out of search results and out of notification detail until the vault is unlocked - for one browser session, with a secret separate from the account password. The secret is stored with the same key derivation the account password uses and is not recoverable by anybody, including an administrator; a forgotten one is replaced by proving the account. This is an access-control feature, and the page says so wherever it is described.
Short-lived call credentials
A participant joining a call is issued a signed credential for that one room, minted per join and valid for minutes rather than for the duration of a meeting. That short life is what makes removing somebody from a conversation take effect on a call already in progress, instead of at the next time somebody happens to rejoin.
Private media authorisation
Attachments are stored outside anything a web server hands out by path, and startup refuses a configuration that would place them inside it. Every read is authorised against the conversation the file belongs to, uploads are checked against their actual bytes rather than their file extension, and photograph metadata is stripped before storage.
Temporary guest lifecycle
A guest invitation is single-use and expires on its own. A redeemed guest credential is valid for exactly one room. When the retention window closes, the room, its messages, its files, the objects behind them, the call record and the guest's ephemeral account are removed by a background service - not by asking a browser to forget.
Server-side authorisation
The application requires an authenticated caller by default. A page or an endpoint that is meant to be public has to say so explicitly, so forgetting to state a rule fails closed rather than open. Nothing is protected by the interface declining to draw a button.
Security event auditing
Sign-ins and failed sign-ins, multi-factor changes, invitations issued and redeemed, role changes, suspensions and session revocations are written to an audit trail with the actor, the target, the address and the time, and reviewed from the administration area.
Response and transport hardening
A content security policy with no wildcard in it: inline scripts run by nonce rather than by permitting inline script wholesale, and the only non-local origin ever named is the conference provider a deployment configured. Framing is refused, content-type sniffing is refused, and device permissions are granted to this origin and the conference and to nothing else.
Rate limiting that counts once
Sign-in, password reset, invitation redemption, guest redemption, uploads, vault unlocks and this website's contact form are all metered. On a multi-node deployment the counting is shared between nodes, because a limiter that counts per process gives an attacker one full allowance for every node you add.
Where the decisions are made
Authorisation happens where a request is answered. The conference provider carries audio and video; it never decides who is allowed to be in the room.
Deliberately shallow: an architecture diagram on a public page that named internal hosts, ports or schemas would be a reconnaissance aid rather than an explanation.
-
The browser
No application to install and no plug-in to trust. Messages, files, voice notes and calls all run in a current desktop or mobile browser.
-
Priveloq Chat
Every request is authenticated and then authorised on the server. A page that forgets to say who may see it is refused rather than served: the application requires a signed-in caller by default, and each public page states its exemption explicitly.
- Messaging Conversations, delivery and read state
- Media Uploads stored outside the web root
- Security Sessions, roles, permissions and the audit trail
- Calling Who may join, and for how long
-
The conference server
Audio and video run through a conference service the deployment operates or contracts. It never decides who may join: Priveloq Chat checks that, and issues each participant a short-lived credential for one room, which is what makes removing somebody take effect on a call already under way.
What this page does not claim
A security page is worth reading only if the absences are as deliberate as the claims. These are the things Priveloq Chat does not currently provide, stated so that nobody has to infer it.
Not end-to-end encrypted
Traffic is encrypted in transit and content is served only to authorised callers, but the server can read message content. That is what makes server-side search, administration and the guest-room purge work. If end-to-end encryption is a requirement for you, say so when you get in touch rather than assuming either answer.
No compliance certification claimed
This page makes no HIPAA, PCI DSS, SOC 2, ISO 27001 or GDPR compliance claim. Individual controls described above may be relevant to an assessment you are running; none of them is a certification, and we will not describe them as one.
No absolute guarantees
Nothing here is "unhackable", "military-grade" or "100% secure". Those phrases describe no property that can be tested. What can be tested is the list above, and that is the list we will answer questions about.
Some of it is your deployment's job
Retention windows, media policy, multi-factor requirements, guest capabilities, which proxies are believed and where the keys live are configuration. The application validates them at startup and refuses several dangerous combinations outright, but a deployment still decides its own policy.
Private communication without public signup.
Request access or sign in to your existing account. Accounts are created by invitation, so there is no public registration to work through.