The principal security mechanisms and their documented limitations in 10 Seconds.
10 Seconds is operated by Sterling and Pierce Holding L.L.C-FZ, Meydan Grandstand, 6th Floor, Meydan Road, Nad Al Sheba, Dubai, United Arab Emirates.
The service provides private text communications between prearranged participants. Audio and video calls are not included. Its security depends on the implementation of the service, the integrity of the software delivered to the browser, correct key handling, and the security of each participant's device and credentials.
This overview should be read together with the Privacy Policy, the Cookies and Browser Storage Policy, the Terms of Service, and the Law Enforcement Guidelines.
In ordinary operation of the messaging service, message content is encrypted on the sender's device before transmission and decrypted on the recipient's device. The server processes ciphertext only.
The implementation uses NaCl box through TweetNaCl, combining:
These primitives provide authenticated encryption when correctly implemented. Their protection depends on secure randomness, correct nonce handling, protection of private keys, and reliable association of public keys with the intended participants.
Cryptographic authentication does not certify a participant's civil identity or provide conclusive third-party proof that a particular person authored a message. A username or possession of room credentials is not identity verification.
End-to-end encryption does not conceal every connection characteristic from network operators or other parties. It does not protect plaintext already accessible on a compromised participant device.
Each account generates an asymmetric key pair in the browser via tweetnacl. The private key is encrypted locally using AES-GCM 256-bit with a key derived from your password through PBKDF2-SHA256 at 600 000 iterations (aligned with OWASP 2026 master-key guidance and NIST SP 800-63B). Only the encrypted private-key representation is sent to the server.
Account passwords are additionally protected server-side by bcrypt (cost 10, OWASP 2026 standard) applied to a client-side SHA-256 pre-hash. The plaintext password never reaches the server. Hash computation is offloaded to an isolated thread pool so a slow hash never blocks the request loop.
An encrypted private-key representation is still key-related data. Its presence on a server must not be described as an absence of all key material. It is distinct from a private key available in plaintext for ordinary server-side use.
Password-based encryption reduces the risk of unauthorised use of the stored encrypted key, but its resistance also depends on password strength, salts, nonce handling, and implementation. A stolen encrypted key may be exposed to offline password-guessing attempts; the 600 000 PBKDF2 iterations and bcrypt cost 10 are chosen to make such attempts computationally expensive on current hardware.
We do not guarantee that every form of server compromise leaves all communications unaffected. An attacker controlling application delivery may attempt to modify the browser code or interfere with key distribution. Compromise of credentials, endpoints, or key material can create additional risks.
The description in this overview does not establish forward secrecy or post-compromise security for the account-level NaCl box construction. In particular, deletion of messages from the service does not guarantee that encrypted copies captured elsewhere could never become readable following a later key compromise.
Claims about resistance to a specific attack require assessment of the complete protocol and deployed implementation, including participant-key verification and key lifecycle.
Removal from the document object model or release of a memory reference is not forensic erasure from every memory location or device. Browser memory, operating-system behaviour, extensions, screenshots, downloads, and participant-created copies are separate considerations.
Message-display expiry, room expiry, website authentication expiry, and browser-storage expiry are different mechanisms. Ending a room does not automatically prove that every related browser-storage entry has been deleted. See the Cookies and Browser Storage Policy.
The absence of retained message content does not mean that no information is processed temporarily or that no commercial or administrative records exist (see Section 10 and the Privacy Policy).
Each room is identified by an HMAC-SHA256 hash rather than exposing the human-readable room name directly. Joining a room requires both the room identifier and the password. The server verifies passwords in constant time (hmac.compare_digest) to limit one potential timing signal.
This design can reduce exposure of room names and make unauthorised discovery more difficult. It does not guarantee that enumeration, credential guessing, or access using leaked credentials is impossible. Protection depends on secret quality, key management, access controls, and the overall request-handling design.
Constant-time comparison for one secret does not establish that the entire application is free from timing or other side-channel vulnerabilities.
Room names, passwords, and invitation details should be shared only with the intended participant through an appropriately protected out-of-band channel.
Every active session renders an invisible watermark across the chat area containing the viewer's account identifier and the current date. The purpose is to discourage unauthorised disclosure and potentially assist examination of a leaked image.
A watermark may be absent, unreadable, removed, altered, or misleading. It does not reliably identify the natural person who captured or disclosed an image and must not be treated as conclusive evidence on its own.
If a capture preserves the watermark, it may also expose the embedded account identifier and date to recipients of that capture. Users should consider this when choosing an identifier and sharing images.
The browser client uses available signals — the Print Screen key, page-visibility changes, and loss of window focus — to identify activity that may warrant a capture-related alert. Where triggered, an alert is shown to session participants in real time. False positives are reduced by a skip-window on known user interactions (file-picker opening, tab switching).
These signals do not prove that a screenshot was taken. Ordinary actions (switching applications, opening a system dialog) may produce similar events. Some screenshots and recordings generate no detectable signal at all, in particular:
The absence of an alert does not mean that no capture occurred. An alert does not, by itself, establish misuse by a participant. This feature is a deterrent, not a screenshot-prevention guarantee.
The production service requires HTTPS with TLS 1.2 or later. HTTP Strict Transport Security is configured with max-age=31536000; includeSubDomains; preload to promote HTTPS connections for supported browsers. Inclusion of a preload directive in an HSTS header does not, by itself, establish that the domain is included in a browser preload list; any statement of actual preload status requires separate verification.
Content Security Policy Level 3 is used to restrict permitted script and resource sources, together with X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: no-referrer, Cross-Origin-Opener-Policy and Cross-Origin-Resource-Policy set to same-origin. Effectiveness depends on the deployed directives and any exceptions. This overview does not claim that a Content Security Policy eliminates script-injection risks.
Production authentication cookies use Secure, HttpOnly, and SameSite=Lax. These attributes do not encrypt cookie contents and do not apply to browser sessionStorage (see Cookies and Browser Storage Policy).
Message content, encrypted account-key material, and administrative records are distinct data categories. An absence of retained chat content must not be described as an absence of all stored information.
Billing information and other personally identifiable administrative fields are stored encrypted at rest using Fernet (AES-128-CBC + HMAC-SHA256) with a server-side master key held outside the database. Even a direct database dump reveals no readable billing data.
Server-side logs follow the same philosophy and go further: they are written at ERROR level only, usernames and room identifiers are replaced by HMAC-SHA256 pseudonyms, and every log line is encrypted at rest as an autonomous Fernet token. Even a disk extraction or backup theft reveals no readable log entry. Full detail in the Privacy Policy §8.
Important clarification: encryption at rest controlled by the Publisher is distinct from end-to-end message encryption. It does not make administrative records technically inaccessible to the Publisher, whose authorised applications may lawfully decrypt them when required for billing, support, or compliance. It protects against exposure of the database alone, not against a compromise that also yields the master key or against an authorised internal query.
Backups follow the same encryption standard. Server locations: primary infrastructure in the European Union and the Meydan Free Zone, Dubai (UAE); identity of the hosting provider is confidential and disclosed to competent authorities on valid legal request. See Privacy Policy for data-residency details.
The server stack was audited and refactored in October 2026 to withstand sustained traffic without compromising isolation. The following measures are now in production:
127.0.0.1 only. Redis is never exposed outside the server loopback; nothing travels on the public network.Load testing (October 2026): the server was validated with Locust at 500, 1 000 and 2 000 concurrent synthetic users for ten minutes each. All three test runs completed at a measured 0.00% error rate. Full statistics available on request.
These measures reflect operational posture at the publication date of this version. They do not establish certification by a regulator or by an independent auditor; where such claims are made elsewhere, their scope, date, and findings are expressly identified.
Use a strong, unique passphrase and protect access to your device and browser. Keep the operating system and browser updated, review extensions, and avoid entering credentials on untrusted pages.
Your password is the only key to your encrypted account material. In the described password-protected key design, the Publisher cannot decrypt your private-key representation without the necessary password material. Losing that material may permanently prevent access to the corresponding encrypted key.
Account-access reset and recovery of cryptographic keys are separate functions. Any available recovery process is described accurately in the service interface. Losing your password does not mean that an archive of previous messages exists or can be recovered — it does not.
User precautions complement the Publisher's security obligations but do not transfer the Publisher's own legal responsibilities to the user.
Any network-level privacy or security software a user may independently choose to install on their own device may change which network parties can observe particular connection information, but no such software guarantees anonymity or protects against every form of device compromise, correlation, or voluntary disclosure.
The legality of particular tools and uses depends on applicable local rules, which vary significantly by country, by use case, and over time. This overview does not represent that any particular tool is lawful or unlawful in any particular jurisdiction. Users must verify the legality of specific tools and uses in their own country before use and comply with applicable law. Independent third-party tools do not authorise unlawful conduct.
Security incidents are assessed according to their nature, the information affected, and applicable legal obligations. Notification to a competent authority or to affected persons is made where legally required and within the relevant statutory deadline.
Where the Publisher acts as processor under a Data Processing Agreement, it notifies the relevant controller without undue delay — and in any event within 72 hours (GDPR Art. 33) — of becoming aware of a personal data breach affecting the controller's data.
Applicable requirements may include the GDPR, UAE Federal Decree-Law No. 45 of 2021 on Personal Data Protection, UAE Federal Decree-Law No. 34 of 2021 on Combating Rumors and Cybercrimes, the EU Digital Services Act (Regulation 2022/2065), and relevant US federal or state privacy, security, and breach-notification rules. Their application depends on the processing and circumstances.
Nothing in this overview claims certification by a regulator, establishes universal legal compliance, or excludes non-waivable rights and remedies. An independent security assessment is claimed only where its scope, date, and findings are expressly identified.
Report suspected vulnerabilities to contact@10seconds.io using the subject line SECURITY REPORT — [brief description]. Please include:
We aim to acknowledge valid reports within 72 hours. This is an operational target, not a guaranteed remediation deadline; reports are prioritised according to assessed severity.
This page does not grant blanket authorisation to access systems, test third-party infrastructure, disrupt the service, conduct social engineering, or obtain other users' information. Seek written scope agreement before conducting testing that could affect production systems or other persons.
If you encounter another person's data unexpectedly, stop the affected activity, avoid further access or copying, and report the issue promptly. We work in good faith with researchers before any public disclosure and seek coordinated disclosure without restricting legally protected reporting to competent authorities.
No bounty or payment is promised unless separately agreed in writing. These guidelines do not create legal immunity from third-party claims or applicable law.
This overview is updated when material security features or documented limitations change. Its publication does not replace a detailed technical specification or an independent assessment of the deployed service.
Questions: contact@10seconds.io — single point of contact for all matters.
Version 2026.15 · Effective 2026-10-23.
Published by Sterling and Pierce Holding L.L.C-FZ, Meydan Free Zone, Dubai (UAE).
Contact: contact@10seconds.io