NetzSec Logo
Security

Nothing hidden.
Everything on the
record

A clear, database-backed view of what we store, why we store it, and how we protect it.

25 record groups6 hard exclusions0 ad profiles
The trust core

Your account is the perimeter.
Nothing else gets in.

Scripts, devices, webhooks, support tickets, licenses: every record you create sits inside your account, encrypted at rest and in transit, and sealed at the same boundary the rings expand from.

  • Role-based access across scripts, devices, and support tools
  • No hidden telemetry: no covert tracking of script runs or device activity
  • Schema-mapped transparency: see exactly what we store, below
Your dashboard/ 01

Why login is required.
Authentication protects your data and unlocks account features.

Account securityAuthentication protects your workspace and enforces role-based access across scripts, devices, and support tools.
Script workspaceYour scripts, descriptions, tags, and visibility settings live in your private workspace and require login to manage.
Devices & licensesDevices, licenses, and provisioning status are tied to your account so you can manage hardware and digital access securely.
Webhooks & integrationsWebhooks and their payloads are stored per account, so only you can view or rotate them.
Support ticketsSupport tickets and replies are private records linked to your account, so we can help without exposing your data.
NotificationsSecurity alerts, product updates, and ticket replies are delivered only to authenticated users.
Community interactionsScript reviews, ratings, and messages require authentication to prevent abuse and keep feedback trustworthy.
Abuse preventionCooldowns and infractions protect the platform from spam and misuse while keeping audit trails scoped to accounts.

No login, no private workspace. Without authentication, we could not provide private storage, device management, or personalized tools. Login is about protecting your workspace, not tracking you.

Full transparency/ 02

What data we store.
Pick a product. Every table it keeps, mapped one to one.

The hardware platform with accounts, licensing, and the dashboard. Every table below lives in the ZeroTrace backend.

users
4 fields
  • usernamereqPrimary account identifier
  • passwordreqStored only as a hash
  • rolereqAccess control
  • totp_secretoptTwo-factor authentication
sessions
2 fields
  • keyreqSigned-in session token
  • expires_atreqAutomatic logout
licenses
4 fields
  • key, license_hashreqLicense plus its BLAKE2b lookup hash
  • bound_hwidoptHardware this license is bound to
  • reasonreqWhy the row exists (purchase or regen)
  • expires_at, revoked_atoptValidity and soft-delete
devices
4 fields
  • device_type, statusreqProvisioning and usage
  • device_nameoptHuman-friendly labeling
  • device_licenseoptPer-device license and expiry
  • is_ghost_mode, ghost_keyoptAnonymous ghost provisioning
devices · shipping
4 fields
  • shipping_nameoptRecipient name
  • shipping_street, line2optFull delivery address
  • city, postal_code, stateoptAddress components
  • country, courier, invoice_idoptCarrier and invoice metadata
scripts
4 fields
  • title, content, descriptionreqYour work
  • mode, operating_systemoptRuntime targeting
  • visibility, tagsreqDiscovery controls
  • votes, downloads, flagsreqUsage and moderation state
script_interactions
2 fields
  • interaction_typereqVote, rating, or comment
  • rating, messageoptCommunity feedback
themes
3 fields
  • title, description, palettereqShared theme content
  • visibility, tagsoptDiscovery controls
  • votes, downloadsreqUsage counts
theme_interactions
2 fields
  • interaction_typereqVote, rating, or comment
  • rating, messageoptCommunity feedback
webhooks
2 fields
  • api_idreqIntegration identifier
  • contentoptPayloads you choose to store
messages
3 fields
  • username, rolereqSender context
  • contentreqMessage body
  • reactions, repliesoptInteractions and reply links
tickets
2 fields
  • subject, descriptionreqWhat you reported
  • status, priorityreqWorkflow state
ticket_messages
2 fields
  • messagereqReply body
  • rolereqYou or support staff
notifications
2 fields
  • title, bodyreqImportant updates
  • is_readreqTracks what you have seen
infractions
2 fields
  • type, reasonreqPolicy enforcement
  • details, expires_atoptContext and auto-expiry
cooldowns
2 fields
  • actionreqRate-limited action
  • expires_atoptWhen the limit lifts
airleak_tokens
2 fields
  • token_hash, prefixreqHashed API token
  • last_used_atoptMost recent use
airleak_runs
4 fields
  • started_at, finished_atoptScan run window
  • row_count, new_networks, statusreqRun results
  • device_model, device_brandoptScanning device
  • file_hash, file_bytesreqUploaded capture integrity
airleak_networks
4 fields
  • bssid, ssidoptWireless network identifiers
  • encryption, channel, typeoptRadio characteristics
  • best_lat, best_lonreqStrongest observed location
  • first_seen, last_seen, obs_countreqObservation history
airleak_discoveries
3 fields
  • bssid, country, stateoptNetwork and coarse region
  • published, flaggedreqSharing and moderation state
  • discovered_atreqWhen you found it
exam_attempts
3 fields
  • questions, answersoptYour exam submission
  • score, passedoptResult
  • integrity_eventsoptAnti-cheat signals during the attempt
badges
3 fields
  • public_id, holder_nameoptShareable badge identity
  • issued_at, expires_atoptValidity window
  • revoked_at, reasonoptRevocation record
withdrawals
4 fields
  • emailreqContact for the request
  • reference_number, statusreqRequest tracking
  • refund_amount, currencyreqRefund total (no card data)
  • itemsoptReturned products and condition
stripe_events
2 fields
  • event_id, event_typereqStripe event, for dedup only
  • processed_atreqWhen we handled it
platform
3 fields
  • products, packagesreqCatalog and shipping presets
  • announcements, changelogreqPublic change history
  • versions, redeem_codesreqRelease and reseller tracking
Privacy guardrails/ 03

What we don't store.
Nothing below has a place in our core account database.

Data lifecycle/ 04

Built-in expiry & auditability.
Expiry fields and timestamps define how long data persists.

Expiring sessionsSessions include explicit expiry timestamps to limit how long tokens remain valid.
Time-bound governanceInfractions and cooldowns include expiry fields, so restrictions can be lifted automatically.
Auditable timestampsMost tables include created-at and updated-at fields to support auditability and change tracking.
License windowsLicenses track expiration dates so access is granted only for valid periods.
How we protect you/ 05

Security measures.
Controls designed to reduce risk and protect sensitive data.

Authentication hardeningPasswords are stored as non-reversible hashes, and accounts can be protected with optional TOTP two-factor authentication.
Secure infrastructureDedicated servers, hardened configurations, and regular OS updates protect services at the machine level.
Database controlsStrict access controls and audited schema changes limit who can reach sensitive data.
Least-privilege accessRole-based permissions reduce blast radius and keep user data isolated.
Secure developmentWe apply secure-by-default coding practices and review sensitive changes before release.
Session safetySession expiry and rotation reduce exposure if a token is ever compromised.
Transparency/ 06

Public accountability.
Changes, audits, and policy updates, documented in public.

Announcements & changelogMajor changes, fixes, and policy updates are posted in a clear public record.
Independent auditsWhen we commission third-party audits, we publish summaries and the full reports.
Incident disclosureIf user data is at risk, we disclose what happened and what we changed to fix it.
Data minimizationWe follow a privacy-first approach inspired by leaders like Mullvad: collect only what we need.
Still curious?

Security is a conversation, not a page.

If anything here is unclear, or you think we can do better, tell us. Transparency only works when it goes both ways.