Transparency Report

Inaugural reporting period: July 2024 to March 2026 · October 2026 server-side audit addendum included.

Revised edition · Published 2026-10-24 · Sterling and Pierce Holding L.L.C-FZ

1. Purpose and scope

Sterling and Pierce Holding L.L.C-FZ, the operator of 10 Seconds (the "Publisher"), provides this report to explain its reported handling of law-enforcement requests, safety referrals, and related matters during the stated reporting period.

This is a company-issued transparency report. It is not an independent audit, not a security certification, and not a guarantee that the service cannot be investigated or compromised.

The historical figures below relate only to the period July 2024 through March 2026. The revision date does not extend those figures to October 2026. A separate October 2026 server-side audit addendum (Section 11) describes an infrastructure-only audit completed on 23 October 2026 and does not alter the request / safety / incident counts reported here.

This public report does not replace any mandatory regulatory report, prescribed reporting template, notification to an authority, or communication to affected individuals. Where mandatory reporting requirements apply, the Publisher must comply with their scope, format, and deadlines.

2. How to read the figures

The figures are reported by the Publisher. They are not presented as independently verified.

0: The Publisher reports no identified event within the defined category and reporting period. A zero is not used where available information is insufficient to establish a count.
Not available: A reliable figure cannot be established from the information available. This is different from zero.
Not applicable: The category does not apply to the relevant activity.
Restricted reporting: Information may be omitted, delayed, or presented in legally permitted aggregate form where disclosure restrictions apply. No inference should be drawn about an individual matter.

A request, a disclosure, a referral, and a service restriction are different events. Figures from different categories are not automatically additive. One request may concern several identifiers, and one matter may lead to more than one legally required action.

3. Law-enforcement requests

The following figures concern requests and actions within the publicly reportable scope of this section. They do not constitute a statement concerning the existence or absence of confidential national-security process (see Section 8).

Metric	Reported count
Law-enforcement requests received	0
Requests fully complied with	0
Requests rejected or returned because of legal deficiencies	0
Requests received under Regulation (EU) 2023/1543 (EPO / EPresO)	0
Emergency disclosures concerning danger to life or serious physical injury	0
Identifiable user accounts affected by the reported requests	0

An emergency disclosure is not automatically attributed to Article 18 of the Digital Services Act. The applicable legal basis depends on the service, jurisdiction, and circumstances.

The absence of reported requests does not establish that users have not been investigated through their devices, payment providers, hosting providers, or other independent sources.

4. Request-handling principles

Requests are assessed for authenticity, jurisdiction, legal basis, scope, and applicable confidentiality requirements. The Publisher provides information only where disclosure is legally required or permitted and the information is actually available within its possession, custody, or control.

Preservation and disclosure are separate measures. A preservation obligation cannot retrospectively recreate information that was never retained or was already unavailable. Equally, ordinary deletion practices do not override a binding obligation concerning information that is available when that obligation arises.

Further information is provided in our Law Enforcement Guidelines. Those Guidelines describe the applicable handling process; they do not establish that any particular request occurred during this reporting period.

5. Messaging architecture and its limits

The following describes the current messaging design as represented by the Publisher at the revision date. It is separate from the historical statistics above and does not certify that every previous software version had identical characteristics.

End-to-end encryption: private text communications are end-to-end encrypted (TweetNaCl: Curve25519 / XSalsa20 / Poly1305). The Publisher does not hold the private decryption material.
Chat room lifetime: a hard maximum of 30 minutes (1800 seconds). Rooms are destroyed server-side on expiry.
Early purge if empty: within 30 seconds after all participants leave.
Message visibility: 10, 15, or 20 seconds (configurable at room creation; default 10 seconds), then removed from the chat interface.
No persistent chat archive: no message database, no conversation history, no chat backups.
No historical messaging logs: the messaging service does not retain historical connection logs or conversation-metadata logs; infrastructure logs are rotated by file size, written at ERROR level only, with usernames pseudonymised and lines encrypted at rest (see Privacy Policy §8).
Forensic watermark: every session renders an invisible watermark (username + date) across the chat area, allowing the originating account of a leaked screenshot to be identified.

Disappearance from the chat interface does not guarantee that a participant has not taken a screenshot, photograph, or other copy. These statements do not describe information independently held on user devices or by third-party providers.

The absence of retained conversations must also be distinguished from commercial documents, correspondence, safety reports, and legal-process records that may exist outside the messaging system. Such records are governed by applicable law and the Privacy Policy.

This report does not claim absolute anonymity, immunity from lawful investigation, or the absence of all information relating to a purchase or interaction with the Publisher.

6. Safety referrals and Acceptable Use

Metric	Reported count
Child sexual abuse material referrals to NCMEC (18 U.S.C. §2258A) or competent UAE authorities	0
Accounts terminated for violations of the Acceptable Use Policy	0
Enforcement decisions reviewed following a user request	0

These figures concern reported actions. They do not measure all unlawful conduct that may have occurred through user communications, nor do they imply that the Publisher can inspect end-to-end encrypted message content.

The appropriate recipient and timing of a safety referral depend on applicable law and the facts available. This report does not suggest that every allegation must automatically be sent to multiple authorities.

7. Security notifications

Metric	Reported count
Security incidents communicated to users during the reporting period	0
Mandatory breach notifications to competent data-protection authorities	0

These figures count incidents actually communicated. They are not counts of all attempted attacks, vulnerabilities, suspected incidents, or notifications to regulators. A zero does not establish that no security incident occurred.

Publication of a periodic transparency report does not replace or postpone any legally required breach notification or communication to affected persons.

8. Confidentiality and restricted reporting

Publication is subject to applicable confidentiality rules, court orders, investigation-secrecy requirements, and restrictions on national-security reporting.

Where legally permitted and appropriate, information may be published using aggregate figures, permitted numerical bands, or delayed reporting. The Publisher does not undertake to publish information that it is legally prohibited from disclosing.

This report does not operate as a "warrant canary". Changes to its wording, an omitted section, a publication delay, or the absence of an update must not be interpreted as confirmation that a confidential demand has been received. Nothing in this section confirms or denies the existence of any particular confidential request, order, or investigative measure. The Publisher is subject to the laws of the United Arab Emirates (notably Federal Decree-Law No. 34/2021 on Combating Rumours and Cybercrimes) and to the confidentiality obligations of any binding legal process directed at it; absence of silence here is not a signal.

9. Protection of individuals

Public reporting is intended to explain aggregate activity, not expose users, victims, reporting persons, or investigators. Names, account identifiers, contact details, message contents, and identifying case narratives are not included in this report.

Additional breakdowns will be published only where lawful and sufficiently protective of individuals. Small numbers or combinations of categories may require aggregation to avoid identifying a person or confidential matter.

10. Updates and corrections

The Publisher intends to issue its next voluntary report for calendar year 2026 during the first quarter of 2027. Any earlier or differently structured mandatory reporting obligation remains applicable.

That calendar-year report will overlap with this inaugural report for January through March 2026. The overlap will be identified so that readers do not add the figures together as if they represented separate periods.

Material errors identified in published figures or descriptions will be corrected, with an explanation and revision date where legally permitted. Changes to reporting definitions or methodology will be identified to support meaningful comparisons between periods.

11. October 2026 server-side audit (addendum)

On 23 October 2026 the Publisher completed an internal server-side audit and refactoring of the deployed infrastructure. The audit covered authentication, state sharing, log privacy, concurrency and horizontal scaling. It is self-attested, is not an independent certification, and does not alter the request / safety / incident counts reported in Sections 3, 6 and 7.

Scope of the audit (six work-streams, B.1 to B.6):

B.1 — Password hashing. Server-side bcrypt confirmed at cost 10 (OWASP 2026 standard) applied to a client-side SHA-256 pre-hash.
B.2 — MySQL connection pooling. Introduced a pool of 32 persistent connections per worker (128 total). Prevents connection-exhaustion denial-of-service as a vector.
B.3 — WSGI runtime. Moved from a development server to gunicorn with the geventWebSocket worker class, four isolated worker processes, 2 000 greenlets per worker (~8 000 concurrent connections). Crash in one worker does not affect the others.
B.4 — Password-hashing isolation. bcrypt operations deported into a dedicated gevent thread pool so a hash computation never blocks the request loop.
B.5 — Shared application state. Session rooms, participant lists and transient counters moved out of in-process memory into a Redis instance bound to 127.0.0.1 only. Redis is never exposed outside the server loopback; no new public network surface was introduced.
B.6 — Atomic server operations. Hot-path updates (participant join, participant leave, cleanup of stale heartbeats) executed as Lua scripts inside Redis. Guarantees atomicity across all four workers and eliminates race conditions between them.

Private-key encryption and log privacy (aligned with the above):

Private-key protection. PBKDF2-SHA256 iteration count for the user's encrypted private key confirmed at 600 000 (aligned with OWASP 2026 master-key guidance and NIST SP 800-63B).
Server logs. Written at ERROR level only. Usernames and room identifiers replaced by HMAC-SHA256 pseudonyms. Each log line is written as an autonomous Fernet token (AES-128-CBC + HMAC-SHA256). A disk extraction or backup theft reveals no readable log entry. Full detail in the Privacy Policy §8 and Security Overview §10.
Rate limiting. The internal load-test bypass flag has been removed from the deployed binary. Sliding-window rate limiters are permanently active on authentication and sensitive routes (anti-bruteforce 5 attempts per 15 minutes per IP + username; anti-flood 10 writes per 60 seconds). They cannot be re-enabled without a code change.

Load testing. The server was validated with the Locust load-testing framework under three successive scenarios on 23 October 2026:

Concurrent synthetic users	Duration	Measured error rate
500	10 minutes	0.00%
1 000	10 minutes	0.00%
2 000	10 minutes	0.00%

No change in this audit affected end-to-end encryption: TweetNaCl (Curve25519 / XSalsa20 / Poly1305) remains in place and the server continues to process ciphertext only. The audit did not change what the Publisher is technically capable of disclosing in response to legal process.

Full statistical reports from the load tests are available on request to contact@10seconds.io. Reproduction by an independent party is welcome under reasonable scope agreement; publication of this addendum does not constitute an invitation to test production systems without prior written authorisation.

12. Contact

Questions about this report or suspected factual inaccuracies may be sent to contact@10seconds.io. Do not include unnecessary personal information or illegal material in your message.

Reporting period: July 2024 to March 2026 · October 2026 server-side audit addendum.
Revised edition: Version 2026.15 · Effective 2026-10-24.
Published by Sterling and Pierce Holding L.L.C-FZ, Meydan Free Zone, Dubai (UAE).
Contact: contact@10seconds.io