Server never sees plaintext

Verifies

Requires an AI engine: publishes a verdict PER SCOPE (per class of messaging room, `result.scopes`) instead of one verdict for the whole messaging feature. `public-broadcast` is never evaluated (a public/open channel does not promise confidentiality). `server-managed-group` may PASS only under its own certificate (server-managed group confidentiality: encrypted by the room's identity, server-managed key, decryption restricted to that room's own members) — it never claims end-to-end. `device-to-device` may PASS only when no server-side path of that class decrypts, stores or forwards message plaintext; message storage of that class holds ciphertext and delivery metadata only.

Inputs

Non-test code files of the checkout (JavaScript, TypeScript, Python, PHP) plus Prisma and SQL schemas. Messaging files are located by path, content or message schema; server files by side classification. Every messaging file is classified into a scope BEFORE any decrypt/ciphertext evidence is read: a public/open broadcast or livestream channel (viewer/subscriber/follower counts, a Channel/Stream/Broadcast store with no membership list) is `public-broadcast` and excluded from every further check. Of what remains, a server file that decrypts message content is `server-managed-group`; a server file with a recognised end-to-end protocol reference that never decrypts is `device-to-device`; anything else with ciphertext evidence and no decrypt call is `server-managed-group` (the default: a schema alone cannot prove device-to-device). The message schemas and server-side messaging files of a scope (at most 24 per scope) are sent together in one assessment call PER SCOPE to the chosen engine through the platform ai service; at most 160000 estimated tokens per scope. Paths listed in excludes (test, spec and tmp files, __tests__, __mocks__, fixtures, test, tests and audit-scripts folders) are never analysed. Every model call (rubric, repository context and files) stays under 120000 characters; a candidate set that does not fit is sent in parts, each part bounded by what the chosen engine serves in one call (the engine publishes that budget; a call is never filled up to the transport cap). Speed pass (1.0.11): each file goes to the model as the EXCERPT of the lines relevant to the requirement (decryptions, ciphertext and message content, per-room access checks, and the notification, log, search and webhook paths that carry a message), 12 lines around each of them (the whole file when that is most of it), omitted spans marked; a server file of the server-managed group class with NONE of those lines (a file that only shares the messaging vocabulary) is not sent and the trace names it — a group scope left with nothing to assess keeps the deterministic verdict it already had; the device-to-device class never drops a file (every one has a protocol or ciphertext line by construction); message schemas always go whole; at most 48 files, most relevant first; parts are cut by path with content-defined boundaries and a context that lists no files, so an unchanged file lands in an unchanged part the engine may answer from its verdict cache; up to the engine's concurrent-call limit, parts go in parallel and are aggregated in part order.

Decision rule

A file is judged SERVER only with proof of its own runtime or of the import graph: the language (Python, PHP), a `server-only` import or a `'use server'` directive, a location the framework declares as server (route.ts, middleware, pages/api, app/api, *.server.*, +server, wsgi/asgi), a Node built-in or server-only package, an HTTP response sink or a Lambda handler export, importing a module that is itself proven to run on a server, or a server folder by framework convention. It is judged BROWSER when it declares `'use client'` or imports `client-only`, when its code touches the DOM, a Web Worker scope, `new Worker(`, a React client hook or a browser-environment polyfill, when a client-declared file of the checkout imports it, when it sits in a browser folder by convention, or when it only uses a Web API the browser serves (`crypto.subtle`, `globalThis.crypto`, `CryptoKey`, `new Blob`, `atob`) with no server evidence at all. NEITHER is NOT server: the shared layer of a monorepo is never accused on a folder name, and the trace says the layer is unproven. `workers/` is not a server folder. A decryption is a CALL (decrypt…(, .decrypt(): an identifier such as decryptError, and the import or re-export line of a decrypt function, are references and are never reported. SCOPES (1.0.7): `public-broadcast` is detected by SHAPE (broadcast/livestream/viewer/subscriber vocabulary, a Channel/Stream/Broadcast store with no membership list) BEFORE any decrypt evidence and is always NOT_APPLICABLE, never evaluated. Among the rest, a server file that decrypts message content is `server-managed-group`: a per-room access restriction anywhere in the same file (resolveRoomBot, getBotByRoom, a membership/participant check) makes it a PASS candidate under the group-confidentiality certificate; NO restriction at all is HIGH (`unrestricted-group-decrypt`) and this scope can never come out clean for that room. A server file with a recognised end-to-end protocol reference that never decrypts is `device-to-device`, and may PASS only under the device-end-to-end certificate. A message schema with a plaintext body and no ciphertext field, or a feature with no encryption evidence anywhere (no protocol library, no ciphertext field, no server-managed-group file), is HIGH `plaintext-message-storage` and the group scope FAILs outright with no model call. Not applicable overall only when the checkout has no messaging feature, when the feature has no server-side file or schema at all, or when every messaging file is `public-broadcast`. Each scope with a model call requires confidence of at least 0.8 that its own requirement holds: an unsatisfied or undecided assessment is a FAIL for that scope, a HIGH finding in that scope is a FAIL for that scope, MEDIUM blocks only inside Extended suites, an unparseable answer is a FAIL. The aggregate `status` is the most blocking of the published scopes (ERROR > FAIL > PASS > NOT_APPLICABLE, same precedence a suite uses over its checks): one scope failing never hides a clean one, and NOT_APPLICABLE never blocks. A messaging feature exists only with a message or conversation model, a chat transport, a messaging protocol library, a chat UI or end-to-end keys in a messaging folder somewhere in the checkout: messaging vocabulary alone is not-applicable with the reason (1.0.2). Without an AI engine the check is not executed (requires an AI engine).

Type

ai-assisted · engine chosen by the organisation · medium

1.0.11: SPEED PASS: each file goes to the model as the EXCERPT around the lines the deterministic part marked relevant to THIS requirement (decryptions, ciphertext and message content, per-room access checks, and the notification, log, search and webhook paths that carry a message), 12 lines on each side (the whole file when that is most of it); the omitted spans are marked in place and a finding on a line that was not sent is dropped. A server file of the server-managed group class with none of them (a file that only shares the messaging vocabulary) is not sent and the trace names it; a group scope left with nothing to assess keeps its deterministic verdict; the device-to-device class never drops a file; message schemas always go whole. Up to 48 files, most relevant first, instead of 24 whole ones. STABLE PARTS: the files are packed by path with content-defined part boundaries (decided by the path, never by the content) and the repository context lists no files, so an unchanged file lands in a byte-identical part the engine may answer from its verdict cache (per organisation, declared in the trace and in the attestation). The parts are sent in parallel up to what the engine admits (ctx.ai.maxConcurrentCalls) and aggregated in part order, so the verdict never depends on which answer arrives first. The assessment reason is ONE sentence of at most 30 words (the platform GPU spends 46 ms per output token and the reason was most of every answer). Requirement, categories and decision rule unchanged. (1.0.10: the operational-notification exclusion of 1.0.9 was vetoed whenever the file named "members" or "contacts", so an alert fanned out to the members of an organisation was still judged as person-to-person messaging. The veto is now conversation addressing only (a recipient or sender id, the participants of a room, a conversation, room, thread or chat id): a file that addresses a conversation is still the messaging feature and still fails in plain text. (1.0.9: an OPERATIONAL incident/alert notification system — opening an internal incident, notifying a dispute, delivering account-lifecycle notices, counting webhook deliveries — was classified as part of the messaging feature just because it reuses the same coarse vocabulary ("inbox", "channel", "message", "push", "send"): its audience is an operator or a third-party integration, never a person-to-person conversation. Excluded before the file is added to the messaging feature at all, unless it also addresses a person (recipient, sender, participant, member). (1.0.8: `followerCount`/`follower_count` dropped from the public-broadcast vocabulary: "follower" is a universal social-graph relationship (who follows whose profile), not a stream's audience, and it fired on an ordinary follow-count feature unrelated to messaging — a real checkout with a follow feature and a private group chat would have had that group misclassified as a public channel it never was. `viewerCount`/`subscriberCount` are unchanged: they name a stream's audience specifically. (1.0.7: the check now classifies every messaging file or schema into up to three CLASSES before any decryption analysis, each with its own verdict in result.scopes: public-broadcast (a many-to-many, audience-facing channel, detected by shape, never by whether the server can decrypt) is excluded from this requirement entirely, not-applicable, because no confidentiality is promised there (local to the chat-e2ee suite: the same channel keeps its normal verdict in every other suite); server-managed-group (a symmetric key tied to the room/group's own identity, decryption gated to that room's own membership or an assigned bot/participant) reports a real, HIGH finding when the decryption is unrestricted — this class can never come out clean without a restriction — and otherwise is judged under its OWN distinct guarantee, worded as confidential group messaging and never as end-to-end or point-to-point; device-to-device is the strict default for everything else, and only this class may pass under the device end-to-end guarantee. The check's own aggregate status is the worst of the published classes (ERROR > FAIL > PASS > NOT_APPLICABLE): a clean device-to-device class next to a legitimate server-managed-group class is PASS, never a fail borrowed from a class that never promised end-to-end, and never a pass that hides a class that does not qualify. (1.0.6: WHERE A FILE RUNS is decided from the FILE (and, when the file alone does not say, from the import graph of the checkout), never from a list of folder names of one particular repository, and a file whose server nature is UNPROVEN is never reported as server code. A monorepo has a SHARED layer — a package the browser bundle and the services both import — and the old rule read every ambiguous file as server: WebCrypto of the browser (`crypto.subtle` in a shared e2ee service that a client component imports) came out as "key generation in server code", once per product sharing the layer. The evidence is now, strongest first: the language (Python, PHP); a `server-only`/`client-only` import or a `'use server'`/`'use client'` directive; a location the framework declares as server (route.ts, middleware, pages/api, app/api, *.server.*, +server, wsgi/asgi); a browser runtime in the code (DOM member, Web Worker scope, `new Worker(`, a React client hook, a browser-environment polyfill such as fake-indexeddb or jsdom); a server runtime in the code (Node built-in, server-only package such as express/mongodb/winston/@aws-sdk, HTTP response sink, Lambda handler export); the IMPORT GRAPH (a module a client-declared file imports runs in the browser, a module that imports a server-proven module runs on a server); the folder convention (`workers/` is no longer one of them: a worker folder is a browser convention as often as a server one); a universal Web API of the browser with no server evidence at all; otherwise unproven, which is never server. Found by the attestation campaign of the platform (2026-09-25): 73 of the 252 high findings of every project were this one classification. A decryption is a CALL (`decrypt…(`, `.decrypt(`): an identifier that merely starts with the word (`decryptError`, a field naming a failure) and the import or re-export line of a decrypt function are references, never a server decrypting a message. (1.0.5: `assess` mode cuts the candidate set to what the chosen ENGINE serves in ONE call (`ctx.ai.maxInputChars`, published by the engine per its catalogue budget; `ENGINE_CALL_MAX_CHARS` = 32 000 when an older sandbox does not publish it), instead of filling the call up to the TRANSPORT cap of the proxy (`spec.promptMaxChars`, unchanged at 120 000). On a 1 319-file checkout the old packing produced single prompts of 17 672 / 26 709 / 29 351 tokens and the platform GPU answered "CUDA out of memory": the check ended in `error`. Every call of the same run under ~24 000 characters was answered normally. The part aggregation of 1.0.1 is unchanged: a HIGH in any part is a FAIL, an unsatisfied part is a FAIL, undecided never passes. (1.0.4: the browser asset folders of the server-rendered frameworks (static/, wwwroot/ and Laravel resources/js/) are classified as browser code, like public/ and assets/ already were: browser JavaScript of a Django, Flask or Go application was being analysed as server code (false positive found by the control bench of the audit scripts). (1.0.3: requires an AI engine (spec.requiresEngine: true): the check needs judgement and is executed only when the organisation provides an engine; the core catalogue runs without one. 1.0.2: applies only to a real messaging feature: a message or conversation model, a chat transport (socket, channel or pub/sub events of a conversation), a messaging protocol library (Signal, MLS, Olm/Megolm, XMPP) or a chat UI; messaging vocabulary alone (an error message pushed to a queue, a notification channel, a case signal route) is not-applicable with the reason; never analyses temporary files (*.tmp.*; spec.excludes follows AUDITOR_ANALYSIS_EXCLUDES). (1.0.1: never analyses test, spec, fixture and mock paths nor the auditor's own scripts (spec.excludes = AUDITOR_ANALYSIS_EXCLUDES); a fixture-looking secret (sk_test_, example, dummy) in real code is LOW, informative; every model call stays under the engine prompt cap (spec.promptMaxChars = AUDITOR_AI_PROMPT_MAX_CHARS): assess mode sends the candidate set in parts and aggregates the verdicts (a HIGH in any part is a FAIL, an unsatisfied part is a FAIL).)))))))))

The full script is disclosed on request in a read-only viewer (never published on GitHub); the attestation binds to this exact hash.