Privacy policy

Scope and roles

This policy describes how Trades Backer handles information across the public site, the encrypted application intake, the Employer Dashboard, and the Staff Portal.

• Employers/Organizations publish listings and review applicants. They control hiring decisions and how decrypted data is used internally.
• Applicants submit information and documents through an encrypted form tied to a specific listing.
• Trades Backer Staff coordinates listing requests and receives staff-encrypted messages sent through the Contact form.

What we store

Trades Backer is designed so that sensitive payloads are encrypted before upload. The server stores:

• Ciphertext payloads for applications, uploads, and messages.
• Sealed key metadata required for the authorized key holder to decrypt in the browser.
• Minimal manifest-safe summary fields used for dashboard views and filtering. These are designed to avoid direct identifiers (for example: position/trade, experience, license indicator, submission timestamps, and source tags).
• Operational metadata needed to keep the service reliable and secure (for example: request timing, rate-limit counters, hashed abuse-prevention signals, and structured submission event logs that avoid decrypted form content).

What we do not store in plaintext

We do not store application answers, uploaded documents, or message bodies in plaintext on the server. Your identifying and contact information provided on an application form is included inside the encrypted payload. Decryption happens locally in the browser using a private key provided by the employer (or by staff for staff-only streams).

Contact messages

Messages submitted through the Contact page are encrypted to the staff key and appear in the Staff Portal “Messages” inbox. Staff may add internal notes and a status label to help route and respond. Those staff notes are stored as part of the staff manifest.

How we use information

• To deliver the encrypted intake and dashboard workflow (receive ciphertext, list items, and enable local decryption for authorized users).
• To coordinate employer listing requests, publish listings, and support basic operational messaging.
• To protect the platform from abuse (rate limiting, spam controls, and security monitoring).
• To maintain reliability (debugging and service health), using minimal logs necessary for operation.

Public pages, referrals, and basic analytics signals

Public pages on this site may generate standard web-server request logs and may receive first-party source tags in the URL (for example, ?src= parameters or UTM values) when an employer shares a listing across job boards, social media, QR materials, dispatch updates, or website links. We use those signals to help identify where traffic and applications came from.

• We do not use third-party ad networks or third-party behavior-tracking scripts on the public site.
• Source attribution is intended to measure listing channels, not to build cross-site advertising profiles.
• Public job pages may be indexed by search engines when a listing is meant to be public.

Cookies and authentication

The dashboard uses short-lived session cookies to validate access after you authenticate with your key. We may also accept signed-request headers as a sessionless fallback for authorized dashboard actions. We do not use third-party tracking scripts. We may use first-party, strictly necessary browser storage (such as session storage and limited localStorage metadata) for non-sensitive UI state, remembered routing preferences, and source attribution for listings. Source labels are intended to identify channels, not to create third-party behavioral profiles.

Sharing and access

Trades Backer cannot decrypt employer-encrypted application payloads. Only the holder of the matching private key can decrypt those submissions. Staff can decrypt staff-encrypted inbox items (for example, listing requests and contact messages) in order to coordinate publishing and support. We do not sell personal information.

• Employers/Organizations may share decrypted submissions internally as part of hiring, onboarding, dispatch, and verification workflows.
• Service providers (hosting, email delivery, logging) may process limited operational data to keep the service running. Ciphertext remains ciphertext to them as well.

Security practices

• Client-side encryption by default: sensitive payloads are encrypted in the browser before upload.
• Local-only decryption: private keys are loaded locally; plaintext is produced on the client device during review.
• Abuse controls: rate limiting, fingerprint throttles, hidden honeypot fields, minimum form-fill timing checks, and size limits reduce automated spam and oversized uploads.
• Minimal moving parts: no CMS, plugin ecosystem, or third-party trackers on the public site; fewer dependencies reduces attack surface.

Data retention and deletion

Ciphertext is retained to support ongoing reviews and exports, but the operator may configure automatic ciphertext purging. The default retention window is typically 180 days (see storageRetentionDays), after which encrypted blobs may be removed server-side while keeping a minimal “purged” manifest row for basic history.

• Employers and staff are responsible for exporting and retaining any records required for their own compliance processes.
• Projects/listings can be purged on request, which removes stored ciphertext and associated manifest data for that project.
• If you need a deletion request handled, contact staff with the listing name and approximate submission time.

Operational logging

Trades Backer keeps narrow operational and abuse-prevention logs to protect the service and troubleshoot failures. These logs are intended to capture metadata such as timestamp, outcome, route, project, key identifier, and hashed request fingerprints. They are not intended to store decrypted application answers, uploaded document contents, private keys, or message bodies.

• Submission events: accepted, rejected, rate-limited, or spam-filtered form posts, tied to project and route metadata.
• Dashboard access events: login success/failure, challenge issuance, manifest reads, staff stats access, blob download attempts, and update actions.
• Security events: same-origin failures, signed-header verification failures, replay protection hits, and other authorization denials.

Your choices

• Applicants: avoid submitting high-risk identifiers (for example, SSNs). Use normal HR/dispatch channels when required later in the process.
• Employers: safeguard your private key. If a private key is lost, encrypted submissions cannot be recovered. If a private key is compromised, anyone with that key can decrypt related submissions.

Employer-controlled data after decryption

Once an employer or organization decrypts and exports applicant information, that copied data is controlled by that employer or organization under its own internal practices, systems, and legal obligations. Trades Backer does not control how a recipient stores, shares, or deletes data after it has been decrypted or exported from the dashboard.

Contact and requests

Questions about this policy, project-level deletion requests, or privacy-related requests should be sent through the Contact form on this site. Include the listing name and an approximate submission date or time when possible so staff can identify the correct project stream.

Changes to this policy

We may update this policy as the platform evolves. The “Last updated” date reflects the most recent revision.