DEV Community: Anslem Owhofasa

No server in the middle: how Tracepack moves evidence between two browser tabs

Anslem Owhofasa — Wed, 19 Aug 2026 10:42:53 +0000

Part 2 of the Local-First Evidence series. Part 1 covered why routing sensitive exports through a third-party server is risky. This post is the mechanics: how the handoff and the hashing actually work.

Saying "it's local-first" is easy. Doing it without sacrificing reliability or integrity means solving two separate problems: how to pass structured data across browser tabs safely, and how to hash JSON so two different tools arrive at the exact same fingerprint for the exact same record.

Here's how it actually works.

Why not the obvious options

A few standard patterns get ruled out before landing on a window handshake:

A server API. Routing data through an intermediate backend defeats the entire point. It recreates the exact server-side attack surface and data-retention risk the previous post was about eliminating.
A browser extension. Tracepack's original design used externally_connectable inside a browser extension. That's gone now, replaced with a plain hosted page. An extension adds install friction and one more background process users have to trust before they've gotten any value from it.
URL state (query parameters or hash fragments). Fragments break once a payload grows past a few kilobytes, and worse, URL state leaks into browser history, referrer headers, and any proxy sitting in between. That's a non-starter for records containing customer PII.
A server-mediated iframe embed. Still routes customer bytes through infrastructure you have to run, secure, and pay for.

The actual mechanism: `window.open` plus `postMessage`

Tracepack uses a direct handshake between the source app (a help desk, an internal tool, whatever you're building) and the evidence viewer tab it opens. No server sees the payload at any point, not even Tracepack's own: the hosted app only ever serves static JavaScript.

There are two versions of this handshake live at once, and which one you get depends on whether you hand-roll the postMessage calls yourself or use the @tracepack/integration package. Both are real, both are wired into the live receiver, they just make different tradeoffs.

The plain handshake , the one you'd write by hand from the embed guide:

+-------------------+ +-------------------+
| Source App | | Tracepack Viewer |
| (e.g. Helpdesk) | | (Hosted app) |
+---------+---------+ +---------+---------+
          | |
          | 1. window.open(tracepackUrl) |
          |--------------------------------------------->|
          | |
          | 2. { source: "tracepack", type: "ready" } |
          |<---------------------------------------------|
          | |
          | 3. { source: "tracepack-producer", |
          | type: "evidence", |
          | payload: { ... } } |
          |--------------------------------------------->|
          | |
          | 4. { source: "tracepack", type: "imported", |
          | projectId, evidenceCount } |
          | (best effort, may never arrive if the |
          | tab is closed before a pack is picked) |
          |<---------------------------------------------|

If the payload fails validation here, there's no reply telling the source tab why. Tracepack shows the error inline on its own page, and that's the only place it shows up. Fine for a producer that just wants to fire evidence at Tracepack and doesn't need to react to failure programmatically.

Protocol v1, via @tracepack/integration, is a real state machine, not a looser version of the same thing:

  ready ──▶ send(handoff_id) ──┬──▶ accepted(handoff_id) ──┬──▶ imported(handoff_id, project_id, evidence_count)
                                │ └──▶ cancelled(handoff_id)
                                └──▶ rejected(handoff_id, issues[])

Every message after send carries the same handoff_id, so a producer can correlate a specific submission to its outcome, not just infer success from silence. rejected carries a real issues[] array with a machine-readable code per problem (UNSUPPORTED_PROTOCOL, INVALID_HANDOFF, PAYLOAD_TOO_LARGE, DUPLICATE_HANDOFF, and others), so a producer can show the user something more useful than "something went wrong." Re-sending the exact same accepted handoff is idempotent, it just gets acknowledged again rather than double-imported, and trying to send a second, different handoff while one is already awaiting review gets an explicit DUPLICATE_HANDOFF rejection instead of silently clobbering the first.

On origin checking: both versions already check that the reply actually came from the window that was opened (event.source === window.opener on the receiving side), so a message from some other tab is ignored regardless of which protocol you're using. What differs is origin pinning. @tracepack/integration's producer side records the exact origin it opened (targetOrigin) and refuses to trust a reply from anywhere else, from the very first message. The receiver's very first ready broadcast has to go out to "*", because it genuinely cannot know the opener's origin before the opener's own first message arrives, that's a hard limit of cross-origin window.opener, not a shortcut. Every reply after that targets the real origin exactly. None of this is an allowlist of approved producer sites, there isn't one, and there's no practical way to pre-register every app that might embed this button. That's a deliberate trust boundary, not a gap.

Why hashing raw JSON isn't enough

Set the problem up before the fix: two semantically identical JSON documents can serialize to completely different bytes. Key order, whitespace, and number formatting (1 versus 1.0) all vary by library. Hash the raw bytes and the same evidence can produce two different hashes depending on which tool wrote the JSON, which breaks the entire point of hashing in the first place. Proving nothing changed only works if "nothing changed" can actually be checked.

RFC 8785 in one paragraph

RFC 8785, the JSON Canonicalization Scheme, fixes this by defining one deterministic serialization: fixed key ordering, fixed number formatting, fixed string escaping. The same logical document always serializes to the same bytes, no matter which tool produced it. That's what makes integrity.payload_hash meaningful. It's a hash of the canonical form, not whatever bytes happened to come off the wire.

The two-hash model

A single record actually carries two separate hashes, each proving a different thing:

content_hash on each attachment: a SHA-256 of the raw file bytes. Proves a specific screenshot or document wasn't altered, independent of everything else in the record.
integrity.payload_hash: a SHA-256 of the whole envelope after RFC 8785 canonicalization. Proves the record as a whole (metadata, observations, attachment references) wasn't altered.

Together you can check a single file, the entire record, or both, and know exactly which one failed if a check ever comes back wrong.

What's actually proven versus what's asserted

source.producer_id and source.producer_name are self-reported by whatever tool packaged the evidence. There's no signature tying them to anything. The hash proves the bytes weren't changed after export. It doesn't prove who exported them. Those are two different guarantees, and conflating them is the easiest mistake to make when writing about evidence handling.

If you've seen Sigstore mentioned around this project, here's the accurate scope of it today: Sigstore protects Tracepack's own published npm and CLI release artifacts. You can verify a downloaded package came from the real repository's release workflow with cosign verify-blob. It isn't used for evidence payloads or producer identity, and evidence data never goes anywhere near a public transparency log. A tracepack-authentication layer for real producer identity is a documented research direction, not a shipped feature.

What this design doesn't solve

Worth being honest about the edges:

It doesn't stop someone from editing a record before hashing it. Garbage in, verifiably-consistent garbage out.
It doesn't prove producer identity, as above.
It depends on both tabs being genuine. A compromised or spoofed viewer tab could still claim imported when nothing actually happened.

Part 3 walks through building your own "Send to Tracepack" button end to end, using @tracepack/integration and protocol v1, the version worth building against.

Repo: https://github.com/ace2016/tracepack Format spec: https://github.com/ace2016/tracepack/blob/main/packages/evidence-interchange/SPEC.md

Why exporting support tickets is a security risk and how to fix it local first

Anslem Owhofasa — Tue, 18 Aug 2026 10:32:21 +0000

When a critical bug, billing dispute, or compliance issue happens, someone on the team inevitably needs to export a support conversation. A security engineer might need the raw thread to investigate a report, or a customer might request an official copy of their history.

In most help desks, exporting a conversation means clicking a button that generates a plain text file, a PDF, or a raw JSON dump sent through email or a third party server.

That approach creates three quiet problems that most engineering teams ignore until a compliance audit forces them to deal with it.

1. Unchecked PII Exposure

Support threads are full of sensitive customer data: email addresses, phone numbers, IP logs, internal staff notes, and occasionally accidental API keys or passwords pasted by users. When you export a raw thread to a third party server or email attachment, you duplicate that sensitive data across unmonitored systems.

2. Zero Proof of Integrity

Standard text or PDF exports can be modified by anyone with a text editor. If a customer or an auditor asks for proof of what was said at a specific timestamp, a standard text file holds zero cryptographic proof. There is no easy way to verify if an attachment or message was altered after the fact.

3. Heavy Server to Server Overhead

Building server integrations between your help desk and external audit platforms usually requires storing API keys, maintaining webhook infrastructure, and paying for third party storage just to hold static logs.

The Local First Solution: Client Side Handoffs and Canonical Hashes

To solve this without adding heavy server infrastructure, we can shift the export workflow to be local first.

Instead of sending conversation data to an external server, the help desk hands the structured payload directly to a hosted web app via a postMessage handshake, the same-origin-safe way two browser tabs exchange data without either one hitting a server.

Here is how that workflow operates step by step:

Structure the payload in the help desk. The help desk application extracts the conversation, attachments, and basic metadata, then formats it into a standardized schema.
Generate cryptographic fingerprints. Instead of relying on file names, each attachment gets hashed with SHA-256 the moment it's packaged. The whole payload is then canonicalized (RFC 8785) and hashed again as a single envelope fingerprint, so both individual files and the record as a whole can be checked for tampering later.
Perform a zero-server handoff. The help desk opens the evidence viewer in a new tab and the two tabs negotiate a handshake (ready → evidence → imported). The payload moves directly between the two tabs; Tracepack's own server only ever serves static JavaScript and never sees the evidence itself.
Review before saving. Because the data lives in the browser the whole time, the person handling the export can review the record and apply redactions locally before producing a hashed, portable evidence file.

What a Portable Evidence Schema Looks Like

To keep evidence files consistent across different help desks and tools, the underlying export should follow a simple, deterministic schema.

Here is an example of how a conversation thread converts into a portable record (the real tracepack-evidence v1 format):

{
  "schema_version": 1,
  "source": {
    "producer_id": "freescout-tracepack-module",
    "producer_name": "FreeScout",
    "producer_version": "1.0.0"
  },
  "capture_timestamp": "2026-08-18T10:00:00Z",
  "source_url": "https://support.example.com/conversation/1042",
  "evidence_type": "support_conversation",
  "attachments": [
    {
      "id": "att_01",
      "filename": "screenshot.png",
      "mime_type": "image/png",
      "size": 48213,
      "content_hash": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
      "encoding": "base64",
      "data": "..."
    }
  ],
  "observations": [
    {
      "id": "obs_01",
      "kind": "message",
      "label": "Customer message",
      "detail": "Transaction timed out on checkout page.",
      "attachment_ref": "att_01"
    }
  ],
  "integrity": {
    "algorithm": "sha256",
    "canonicalization": "RFC8785",
    "payload_hash": "..."
  }
}

A few things worth calling out about the real shape:

attachments[] and observations[] are kept separate rather than merged into one generic "records" list. Attachments are the files; observations are the structured claims about the conversation (a message, a note, a flagged detail).
There are two hashes, not one: a content_hash per attachment (raw file bytes), and a single integrity.payload_hash for the canonicalized envelope as a whole.
source.producer_name and source.producer_id are self-reported by whatever tool packaged the evidence. They are not cryptographically verified, so the export UI and any copy describing it should say "reported by," not "verified."

By standardizing this payload, any local tool can read the thread, verify the hashes, and allow safe redactions without breaking the historical record.

Why This Matters for Open Source Maintainers

Building local first workflows keeps systems lean. Help desk maintainers do not have to worry about storing customer data on third party servers or managing complex webhook queues. The entire operation happens right in the browser, tab to tab.

If you are interested in exploring how portable evidence packages work in practice, check out the open source tracepack-evidence v1 specification and CLI on GitHub. I built it to help developers and support teams handle local evidence files safely, and feedback or contributions are always welcome.

Truth Technology and the Architecture of Digital Trust

Anslem Owhofasa — Sat, 04 Apr 2026 21:48:32 +0000

The digital economy has entered a credibility crisis.

Across industries, borders, and institutions, systems now move information at extraordinary speed, yet too often fail at the more fundamental task of proving what that information actually means. Credentials can be duplicated. Professional claims can be inflated. Identity can be fragmented across platforms. In this environment, the central challenge is no longer access to data, but confidence in its validity.

This is not a peripheral issue. It is one of the defining infrastructure problems of the modern technological era.

My work sits precisely at this intersection. As a Data Scientist and Full-Stack Developer, I have come to view trust not as a social abstraction, but as a systems problem that must be solved through rigorous engineering. The future of digital platforms will depend on whether they can distinguish verified truth from unverified assertion, and whether they can do so at scale, across contexts, and in ways that remain usable to people.

That is the premise behind Truth Technology.

Truth Technology as a New Category of Engineering

Truth Technology is the design of digital systems that make verification a core function rather than an afterthought.

It is a category of engineering focused on reducing uncertainty where trust matters most. In practice, this means building infrastructure that can verify human skills, validate professional credentials, and support portable forms of digital credibility. It is an approach that recognizes that modern economies do not merely require information. They require evidence that information can be trusted.

This is a technical challenge with profound economic and social consequences. In a global market shaped by mobility, remote work, and digital identity, the ability to verify competence is now essential. Without reliable verification, institutions face inefficiency, individuals face exclusion, and systems become vulnerable to manipulation.

My approach to this problem is grounded in applied technical depth. Data Science provides the methods for identifying patterns of integrity, inconsistency, and risk. Python supports the automation and logic needed for scalable verification workflows. SQL provides the precision and structure required for auditable data systems. Angular enables the creation of interfaces that make these systems transparent, accessible, and operational for real users. Together, these tools form the basis of an architecture that is not only technically sound, but ethically deliberate.

The significance of Truth Technology is that it shifts the goal of engineering from mere digitization to trustworthy digitization.

The Silicon Delta as an Emerging Centre of Global Technical Leadership

The Silicon Delta is increasingly important in this conversation.

It should not be understood merely as a regional innovation cluster, but as a rising technology hub in Nigeria with global relevance. It is a place where technical ambition, local problem-solving, and entrepreneurial discipline are converging to produce work that speaks to international standards. In a global technology landscape that increasingly values resilience, adaptability, and practical innovation, the Silicon Delta represents a meaningful source of both talent and perspective.

What distinguishes this region is not only the presence of capable engineers. It is the nature of the problems being addressed. The most valuable innovations are often born in environments where trust, access, and systems integrity must be engineered carefully and intentionally. That reality creates a generation of technologists who are not simply building products, but designing responses to structural gaps in the digital economy.

To contribute from the Silicon Delta is to participate in a broader redefinition of where serious technological leadership emerges. It is to demonstrate that world-class innovation is not confined to established global centres. It can also emerge from regions that understand the urgency of solving real-world infrastructure problems with precision and discipline.

TiiQu and the Global Verification Challenge

My work with TiiQu is a direct expression of this philosophy.

TiiQu is a global entity focused on verifying human skills and credentials, and its mission aligns closely with the future of digital trust. As labour markets become more distributed and opportunity becomes increasingly borderless, the ability to establish credible proof of human capability has become critical. Institutions need reliable verification. Professionals need portable credibility. Technology platforms need systems that can support both.

This is where collaboration becomes strategically important. Verification is not a local problem with a local answer. It is a global requirement that demands interoperable systems, robust data practices, and engineering frameworks that can adapt across markets. TiiQu’s work reflects that reality, and my contribution to it has been shaped by the conviction that trust infrastructure must be built with both technical rigor and global relevance.

The broader implication is clear. If we want digital systems to support real opportunity, they must be able to authenticate human value in a way that is reliable, scalable, and transparent.

Conclusion: Innovation Must Now Be Measured by Trustworthiness

The next era of technological leadership will not be defined only by speed, scale, or automation. It will be defined by trustworthiness.

That is why Truth Technology matters. It recognizes that the most consequential systems of the future will be those that can justify belief. They will not merely process claims. They will verify them. They will not simply store records. They will make records credible. They will not just enable participation. They will make participation meaningful.

The Silicon Delta has a growing role in shaping that future. So do the engineers, scientists, and builders who understand that trust is not a secondary feature of technology. It is the foundation on which durable digital progress depends.

My work is committed to that principle. Build systems that can be verified. Build platforms that deserve confidence. Build technology that restores trust in the digital economy.

That is not only a technical goal. It is a standard for the future.