S.00 Security and trust
What we claim, what we do not, and how to check either.
Tracepoint runs on a machine its user controls. That is the trust boundary, and every security statement on this page is written from inside it.
S.01 What we claim
Seven statements, each one backed by a mechanism in the product.
Every evidence item's SHA-256 is computed in the browser the moment it arrives and stored with the record.
Within a running workspace, every guarded action appends a row and no row is edited. The application enforces this; the file system does not, which is why we do not say immutable.
Each row carries a named person, their role, and their statement. A typed name on a holder-controlled machine is a management attestation rather than a signature under FAR 2.101, so we say attested.
The TraceSeal manifest prints its canonicalization rules. Any SHA-256 implementation can recompute the root digest, now or in ten years.
No server, no account, no login, no telemetry, no listening port, no network call of any kind. Nothing leaves the device unless a person exports a file and carries it somewhere. Once loaded, the application keeps working with the network cable pulled, and it is verified by running it that way.
Any current browser on Windows, macOS, or Linux, with no installation and no administrator rights. Every record, every attached document, and the full trail live in the browser's own storage on that device, and the whole workspace can be saved to a single file and restored from it.
OSCAL output is validated against the vendored NIST schema and eMASS output against the field matrix before either file saves. A file that would fail import is refused with the reason, and the person is warned on the case before they reach the export.
S.02 What we do not claim
The seal fixes bytes. It binds no credential and no clock.
These limits are true today, and the site says so. The first five are printed on the manifest itself, so a reviewer reads them from the artifact and not only from this page.
The seal fixes bytes; it binds no credential. Evidence of authorship means signing the manifest with the agency's own PKI, outside this application.
Timestamps come from the local machine clock, which the holder can set. Evidence of time means an external trusted timestamp over the root digest.
A sealed record can be a sealed mistake. Tracepoint does not judge whether evidence is sufficient.
Role separation is a workflow control rather than an access control. The same person can create another profile, and an administrator can alter files outside the application. The threat model names what each of these can and cannot do.
Tracepoint holds no ATO and no accreditation. It is client-side files with no server component, which is a materially smaller assessment than a hosted system, and each organization applies its own software approval process to the published file set.
The workspace lives in the browser's storage and in the files a person exports. Protection at rest comes from the device: full-disk encryption, the operating system's controls, and the organization's handling rules for the media the files sit on. The product adds no encryption layer of its own, and says so.
The roster of people is self-declared inside the workspace. There is no login and no credential. Every switch of the acting person is written to the trail, so the record shows who was declared to be acting, and the seal fixes that record. Binding a declared name to a real identity is the organization's PKI, outside this application.
S.03 The threat model
Ten named threats, and what the product does about each.
The full threat model states each one, the mechanism that answers it, and where the answer stops. These are the headings.
Impersonation
A person attests under another name. The trail records the profile, and the seal fixes the trail, so the substitution is visible against any prior seal. The product cannot bind a credential.
Clock manipulation
The holder sets the machine clock. Every timestamp is labelled as local machine time, and the TraceSeal says so on its face. Trusted time requires an external timestamp.
Deletion
A workspace file can be deleted like any file. A seal kept where the holder cannot reach it shows what existed. Retention is the organization's records process, and the product says so.
Editing the workspace outside the application
The file is open JSON. Any edit changes the root digest, and a prior seal shows the change. Importing a workspace file replaces the trail with the one that file carries, and a seal taken before the import shows the replacement.
Administrator or root-level tampering
Not defended. Nothing running on a machine can defend against its administrator. The seal, held elsewhere, detects it.
Substituting the application
Every build ships with a published SHA-256 manifest so an organization can verify the files it received are the files we released.
Selective omission
A package can be built from a workspace that omits records. The package states what it contains; a prior seal over the full workspace shows what it does not.
Evidence substitution
Evidence bytes are hashed at ingest and the digest is sealed. Replacing a file after the fact changes its digest.
Concurrent use and divergent copies
The product is single-holder by design. Two copies of a workspace edited separately do not merge, and the product does not pretend they do.
Data spill through the package
Packages carry the evidence bytes that were attached. Tracepoint is for unclassified information only, and the package states this on its cover.
The threat model in full, including what would change these answers
S.05 Questions
The questions an assessor asks, answered in order.
Q.01What does the seal prove, and what does it not?
It proves the bytes of the records, the trail in order, and the evidence digests have not changed since the seal was taken, and anyone can recompute it with any SHA-256 implementation. It does not prove who wrote them or when. Authorship needs the agency's own PKI over the manifest, and time needs an external trusted timestamp.
Q.02Where does the data go?
Nowhere. There is no server, no account, no telemetry, no listening port, and no external connection. The application runs identically with the network disabled, and that is how it is verified.
Q.03What is the trust boundary?
The machine the user controls. Every statement on this page is written from inside it. An administrator of that machine can alter files outside the application, and a seal held elsewhere is what detects that.
Q.04How do I verify the files I received are the files you released?
Every build ships with a SHA-256 manifest. Run it through any SHA-256 tool and compare. This site does the same for itself, and the result is shown at the top of this page.
Q.05Is role separation an access control?
No. It is a workflow control. The same person can create another profile, and the threat model says so. What role separation does is put the person, the role, and the statement on every row, so a substitution is visible against any prior seal.
Q.06What about classified material?
Tracepoint is for unclassified information only, and every package states that on its cover. Controlled Unclassified Information stays on the machine and inside the package under the organization's own handling rules.
S.06 Verification
Verify the files you received.
Every build of the application publishes a manifest, and the build fails if the policy pin inside it no longer matches. This site does the same, and the check at the top of this page is that manifest being read in your browser.
The application ships with SHA256SUMS and INTEGRITY.txt, listing every file and its digest. The Content-Security-Policy that ships with it allows scripts only from its own origin, plus one inline registration pinned by its hash, and permits no external fonts, no external connections, and no framing by any other site.
To check a build on any machine with a SHA-256 tool, run the manifest through it and compare. The command for this site is:
shasum -a 256 -c SHA256SUMS
/SHA256SUMS lists every file served here, including the application under /app/.
/.well-known/security.txt, per RFC 9116. Report anything to info@arssconsulting.com.
Nothing from anyone else. Fonts, scripts, styles, and the application are all served from this origin under the product's own policy, with one change so the site may frame its own application for the demo.
S.07 Privacy and accessibility
No cookies, no analytics, no third parties, and a site that works without JavaScript.
Privacy
This site sets no cookies, runs no analytics, embeds nothing from third parties, and does not track visitors. Our host may keep ordinary server logs. The application stores its work in your browser's own storage on your machine and sends nothing to us or to anyone else. The only way to reach us from this site is an email address.
Accessibility
The site and the application are built to WCAG 2.1 Level AA and the Section 508 standards. The site works without JavaScript, respects reduced-motion preferences, offers a pause control for anything that moves on its own, keeps every control keyboard-reachable, and holds text contrast at AA or better. If anything here is not accessible to you, tell us at info@arssconsulting.com and we will fix it.