Legal

Privacy Policy

What we collect, what we do not, and what we will not claim. Version 1.3, effective September 22, 2026.

Entity: SEVEN KG LLC, a Kansas domestic limited liability company
Kansas Business ID: 10090770
Formation filed: September 4, 2026
Address of record: 4601 E. Douglas STE 150, Wichita, Kansas 67218, United States
Resident agent: KANSAS REGISTERED AGENT LLC
Privacy contact: privacy@svnkg.com
Version: Version 1.3
Effective date: September 22, 2026

This policy describes what the SEVEN KG systems actually do. Every statement in it was checked against the source code and the deployed configuration rather than taken from a template. Where the systems change, this policy changes with them, and section 13 explains how that is recorded.

In short

SEVEN KG verifies that a computer or phone is the hardware it claims to be, using signed evidence the hardware produces about itself. That work needs information about devices. It needs almost nothing about people.

We hold very little about people, and nothing that works as a password. If you do decide to create a SEVEN KG account, we only hold the email address for your sign-in, system notices, and for grouping your claimed phones. Customers’ API keys are also linked to their account, but we keep only a scrambled form of each key, never the key itself. A display name is optional. That is all we ask you for. If you only attest a device and never claim it, we learn about the device and nothing about you.

The website at svnkg.com sets no cookies, runs no JavaScript, contains no analytics, and makes no requests to any third party. You can verify this in your browser’s developer tools. The separate account page at api.svnkg.com/account uses one sign-in cookie and one small script, described in section 2.
We have never asked for or stored a password. You sign in with a one-time link sent to your email, not a password.
Permanent hardware identifiers are never stored in readable form. They are converted into a keyed hash before storage.
A device’s attestation evidence is replaced every time that device attests — we hold the most recent statement and nothing older. One small record does persist between attestations: whether the device’s hardware counters moved as they should have, stored as values derived under a key rather than as the counters themselves. It exists so we can tell you when a device stops looking like the one that enrolled. What we keep sets out every field.

There are also things we deliberately do not claim. Those are in section 12, and we would rather you read that section than this one.

1. Scope

This policy covers three different relationships, and the answers differ for each.

Someone reading svnkg.com: Section 2
Someone who attests a device, or runs a node: Section 3
A customer submitting work to the network: Section 4

This policy does not cover any website, product or service that SEVEN KG LLC does not operate, even where we link to it.

2. If you are reading our website

We collect nothing.

The site is a set of pre-built static pages. It has no login, no forms, no comment fields and no tracking.

No cookies. None are set, so there is no cookie banner, because there is nothing to consent to.
No JavaScript. The site’s Content-Security-Policy is default-src ‘none’ with no script-src directive at all, which instructs your browser to refuse to run any script on the page — including one an attacker managed to inject.
No third-party requests. Fonts, images and stylesheets are served from our own domain. There is no analytics, no advertising pixel, no embedded video, no social widget and no font service.
No referrer leakage. We send Referrer-Policy: no-referrer, so a site you visit after ours is not told where you came from.
No forms. The policy sets form-action ‘none’, so your browser will refuse to submit a form from our pages. There are none to submit.

The account page

The account page at api.svnkg.com/account is separate from the website. It is the only place we set a cookie.

One sign-in cookie. When you sign in, we set a single cookie that keeps you signed in for up to 30 days. It is marked so that scripts cannot read it, it is only sent over encrypted connections, and it is only sent to the account page. It holds a random value; we store only a scrambled (hashed) form of it, together with when the session started, when it was last used and when it expires. Signing out ends it immediately.
One small script. The page runs one script, and your browser is told to refuse any other. It lets you give your devices and groups nicknames. Those nicknames are saved in your own browser only and are never sent to us. Clearing your browser’s data erases them.
Sign-in links. To sign in, you type your email address and we email you a link that works once, for 15 minutes. We store only a scrambled form of it. The page shows the same message whether or not an account exists for that address, so it cannot be used to find out who our customers are.

Server logs

Our hosting and network providers keep short-lived operational logs of requests to the site. These are produced by that infrastructure, not by us, and typically record an IP address, a timestamp, the page requested and a browser user-agent string. We use them only to keep the site running and to investigate abuse or outages. We do not build profiles from them, do not combine them with anything else described here, and do not sell or share them.

Email

If you write to us, we receive your message and keep it in our mailbox in the ordinary way, for as long as we need it to deal with your enquiry and to keep a record of our correspondence.

We also send email: sign-in links to account holders, and the two notices we send before deleting a stored evidence bundle (section 6). Those go only to the address on the account.

3. If you attest a device, or run a node

This is the section that matters most, because it is where real data is processed.

3.1 What your device sends us

When you attest, your device produces a package of evidence about itself and sends it to our server over HTTPS. That package contains:

A certificate chain produced by your device’s secure hardware — signed by Google on Android, or by your TPM manufacturer on a PC. The chain describes the security state of the device: whether the bootloader is locked, whether the operating system is the manufacturer’s signed build, which security patch level it reports, and what kind of secure hardware performed the signing.
A signature over a random challenge our server generated moments earlier. This proves the evidence is live and was not copied from somewhere else.
A second, long-lived hardware key and its certificate chain, which gives your device a stable identity across attestations. Without it, every attestation would look like a brand-new device.
A label for the device made from its model name and a random suffix (for example SM-S908U-2748d644), and a statement of how much work it is offering to do.
If you are claiming the device: the one-time code you typed into it.

The label is generated by the app. You do not choose it, and it contains nothing about you. For phones that can prove a permanent hardware identity, and for PCs with a TPM chip, we file the device under that identity rather than the label, so the label is only ever a name to show on screen.

3.2 What your device does not send us

The app does not request and cannot see your contacts, your location, your photos, your messages, your call history, your installed app list, your microphone or your camera. It asks for the internet permission and nothing else. The evidence describes the platform, not you and not your activity.

3.3 Accounts are optional

Attesting a device requires no account, no email address, no sign-up and no login. Our record of an unclaimed device consists of its label, the result of the verification, the evidence itself, when it attested, and how much capacity it offered. There is no field in that record for a person.

If you choose to claim a device, you link it to a SEVEN KG account you already have. You get a one-time code on your account page and type it into the device, which proves itself with its hardware in the same step. The code works for 10 minutes and only once, and we store only a scrambled form of it. From then on our record of the device is connected to your account: we record which account holds it and when it was claimed. The device shows your email address back to you partly hidden, so you can check it joined the right account.

On your account page you can switch groups of devices on and off and release a device at any time. Releasing a device removes the link between it and your account; we keep a note that it was released, so a device that changed hands is not confused with one that was never claimed.

3.4 The identifiers inside that evidence

This is the part most privacy policies get wrong by overclaiming, so we will be precise.

The certificate chain your hardware produces contains a permanent, unique identifier — on a PC, the TPM’s endorsement key; on Android, the public key of the attesting key. These do not change when the device is factory-reset. They are, for practical purposes, a hardware serial number, and kept in a readable column they would be a permanent tracking identifier.

So we do not keep them that way. Before anything is stored, the identifier is passed through a keyed one-way function (HMAC-SHA256) under a secret key held only on our server, producing what we call a subject ID. The subject ID is what our database records, what appears in logs, and what our operator tools display.

What that protects against. Anyone who obtains a copy of our database — through a breach, a stolen backup, a subpoena served on a hosting provider, or a mistake of ours — gets subject IDs. They cannot work backwards from one to your hardware identifier, and they cannot test a guess against it, because the secret key is not in the database.

What it does not protect against, stated plainly. SEVEN KG holds that key, so we can always recognise a device that attests to us again. The accurate sentence is that these records are meaningless to someone who steals our database. The inaccurate sentence — which you will not find anywhere in our materials — is that we do not know which device you are. We do. That is how the network tells your device apart from someone else’s.

How long the raw chain is held. For a node, the raw evidence is replaced every time that device attests: we hold the most recent statement it made and nothing older. Where evidence is attached to a customer’s job, it is kept for longer, and section 6 gives the exact rule. During that period the raw identifier is present in our systems, beside its own subject ID. We state that rather than letting the architecture imply otherwise.

3.5 If your device cannot be attested

Some devices cannot produce hardware-backed evidence — an older phone, an unlocked bootloader, a custom ROM, or a PC without a TPM. We record that fact and a coarse reason for it, and the device can still take part in a limited way. We do not compensate by fingerprinting the device some other way. A device that cannot prove itself stays unproven. That is a deliberate design choice, and it is also a privacy protection, because the alternative would be to collect more.

3.6 Node credentials

If your device is accepted as a node, our server issues it a token so it can collect work. That token is a bearer credential: whoever holds it can act as your node until it expires. We do not store it. We keep only a SHA-256 hash of it, held in the server’s memory rather than in the database, compare it in constant time, and discard it when the attestation that issued it expires. We cannot recover your token and could not hand it to anyone who asked for it.

4. If you are a customer

Customers use a SEVEN KG account, and their software authenticates with an API key issued to that account. Our record of a customer is the account’s email address, an optional display name, the roles it holds, whether it is active, and when it was created. For each API key we hold a scrambled (hashed) form of the key, never the key itself, an optional label, when it was issued, when it was last used, and whether it has been revoked. There is no password in that record. If your account pays us for verification, we also hold the reference number Stripe uses for you, and one record for each monthly bill: which month it covers, how many devices it charged for, the amount, Stripe’s reference for that bill, and whether it has been paid and when. Working out that count means keeping a list, month by month, of which devices were on your account. We keep nothing about what those devices did.

Alongside it we hold the jobs you submitted with their parameters and status, the hardware policy you asked us to enforce, the verification records supporting each placement decision, and our own accounting of what you were charged.

4.1 Your data and the work itself

Where a job involves your own files or your clients’ data, that content is handled under the separate agreement between us, not under this policy. Our commitments there — including retention, deletion, sub-processing and breach notification — belong in a Data Processing Agreement, which is the document a regulated customer should be reading. This policy governs what we do as the operator of a public website and an attestation service.

4.2 If you are a regulated financial firm

If you are an SEC-registered investment adviser or broker-dealer, your obligations under Regulation S-P extend to us as your service provider, including the requirement that we notify you no later than 72 hours after becoming aware of unauthorised access to your customer information. A commitment of that kind belongs in a signed agreement rather than in a policy we can amend on our own. Ask us for it before you send us anything.

5. Why we process this information

We process what is described above in order to verify that a device is what it claims to be, which is the service itself; to decide whether a device satisfies a customer’s stated requirements; to produce a signed record of that decision so it can be checked later; to keep the network running, secure and accounted for; and to meet our legal and contractual obligations.

We do not process any of it for advertising, for sale to data brokers, for training machine-learning models, or to build a profile of you. We have no advertising business and no intention of starting one.

Where the law requires a lawful basis to be named: we rely on your consent for attesting a device you own; on performance of our contract with you for customer processing; and on our legitimate interest in operating and securing the network for the infrastructure logs described in section 2.

6. How long we keep it

Your device’s attestation evidence: The most recent statement only. Each attestation replaces the last.
Attestation evidence attached to a customer job: While the account is open, plus 24 months after it closes
Verification result and subject ID: While the node or job record exists
Customer record and job history: Until the account is closed, and thereafter as needed for our accounts
Stored copy of an evidence bundle: 30 days from verification, or longer on a paid retention plan. Deleted after two emailed notices.
Record that an expiry notice was sent: Permanently. It is our proof that you were told before a bundle was deleted.
Device claims: While the device is claimed; afterwards, a note that it was released
Sign-in links: 15 minutes, then deleted once used or expired
Sign-in sessions: Up to 30 days, then deleted 7 days after they end
Claim codes: 10 minutes, then deleted once used or expired
Invoices, and the reference number Stripe uses for you: Seven years after the invoice, because tax records have to be kept that long
The monthly list of which devices an account held: As long as the invoice it supports is kept
Node tokens: Not retained. A hash held in memory, discarded when the attestation expires
Infrastructure logs: As set by the providers in section 8, typically days

Read the second row carefully, because it is the one that surprises people. Evidence attached to a job is kept for as long as that customer’s account remains open. For an account that stays open, that is indefinite. The 24-month clock starts when the account closes, not when the verification happened. We keep it because the reason for holding the bytes is being able to recover from our own verifier having been wrong — which has happened — and to answer a question about a decision long after it was made.

Stored copies of evidence bundles are different again. The first time you download a bundle, we keep an encrypted copy so you can download the same file later. That copy is kept for 30 days from verification unless you buy a longer retention plan. Before it is deleted we email you twice, 14 days and 3 days beforehand, and nothing is deleted unless both notices are on record. After the window closes, the bundle can no longer be downloaded. We are not a record-keeper: keep your own copy of any bundle you need.

The deletion is not a promise somebody has to remember. A scheduled task runs on the server, deletes expired evidence, and records in the system log how many records it removed and when it will next run. If it fails, it logs an alert.

7. Security

In transit

Traffic between your device or browser and our service is protected by TLS. The site is served with HTTP Strict Transport Security including subdomains, which instructs browsers never to attempt an unencrypted connection to us again. The connection between our network provider and our origin server is encrypted and the origin’s certificate is validated, so there is no leg of the path where traffic travels in the clear.

Two things are worth stating plainly about interception. First, an attacker who intercepts attestation evidence cannot forge a passing result: the evidence is signed by hardware whose key they do not have, and it is bound to a single-use challenge our server chose, so it can be neither modified nor replayed. Second, what interception would expose is which device attested and what it reported — the confidentiality of the exchange rather than its integrity. That is why the transport is encrypted even though the evidence is tamper-evident on its own.

Our development and laboratory environment deliberately uses unencrypted connections on a private network, and the server prints a warning at startup when it is running that way. No customer data is present in that environment.

At rest

Passwords do not exist in our systems, so they cannot be stolen from us. API keys, sign-in links, session cookies and claim codes are stored only as SHA-256 hashes. Node tokens are not stored at all. Permanent hardware identifiers are stored as keyed hashes, as described in section 3.4. Stored evidence bundles are encrypted on our server, under a key our storage provider does not hold, before they are uploaded. Database backups are encrypted the same way before they leave the server.

Reporting a vulnerability

If you find a security problem, please tell us. Our contact details for disclosure are published at svnkg.com/.well-known/security.txt. We will not pursue anyone who reports a genuine vulnerability in good faith and gives us a reasonable chance to fix it.

8. Who else is involved

We use a small number of service providers. We do not sell personal information and we do not share it for anyone else’s advertising.

Cloudflare, Inc.: DNS, TLS, protection against attack, hosting of the static website — United States and global edge
Hetzner Online GmbH: The server that runs the verification service — Falkenstein, Germany
Cloudflare R2: Storage for encrypted database backups, and for encrypted copies of evidence bundles — Backups: Eastern North America (United States). Bundles: Western Europe
Fastmail Pty Ltd: Receiving mail sent to our published addresses, and sending sign-in links and expiry notices — United States
Stripe, Inc.: Sending our invoices and collecting payment for them. Your card or bank details go straight to Stripe and never reach us — United States

Two disclosures a reader is entitled to have rather than discover.

Our network provider terminates TLS at its edge in order to protect the service, so that provider necessarily handles traffic to us in decrypted form.

Our verification server is in Germany. Our backups are stored in the United States and our stored evidence bundles in Western Europe, both with Cloudflare R2. Both are encrypted before they leave the server, under a key the storage provider does not have, so what the provider holds is ciphertext it cannot read. We would rather say so than let the choice of a German server imply more than it delivers.

A current, dated sub-processor list is maintained separately and we will send it on request. We will also disclose information where we are legally compelled to, and where we are permitted to tell you that this has happened, we will.

9. Your rights

Wherever you live, you can ask us to tell you what we hold about your device, to correct it, to delete it, to give you a copy in a portable form, or to stop processing it.

Write to privacy@svnkg.com. We will respond within 30 days. We will not charge you, will not require you to create an account in order to ask, and will not treat you differently for having asked. If you have an account, write from the email address on it and we will know it is you.

One practical limitation, stated honestly. For a device that was never claimed, we hold nothing that identifies you, so we cannot look up your records from your name or your email address. To find them we need the device label the app showed you, or the subject identifier the app showed you, or the ability to attest the same device again. This is the direct cost of collecting so little, and we would rather pay it than hold an identity register in order to be able to search one.

Depending on where you live you may have further rights and the right to complain to a supervisory authority. Residents of the Philippines may complain to the National Privacy Commission. Residents of Hong Kong may complain to the Privacy Commissioner for Personal Data. Residents of Australia may complain to the Office of the Australian Information Commissioner. Residents of US states with comprehensive privacy laws may have rights of appeal and may contact their state attorney general.

That list is not exhaustive, and naming an authority is not a claim that we have completed a formal assessment under its law. If you are unsure which rules apply where you live, write to privacy@svnkg.com and we will tell you what we know and what we do not.

10. International transfers

We are a United States company. Our verification server is in Germany. Our network and storage providers operate globally. Information covered by this policy therefore crosses borders as a matter of course, and by using the service you understand that it will.

If you are in the Philippines, the Data Privacy Act of 2012 applies to our processing of your information, and we process device evidence from Philippine residents on the basis of consent given before the first attestation.

11. Children

The service is not directed at children and we do not knowingly collect information from anyone under 18. We ask that you not attest a device if you are under 18. If you believe a child’s device has been attested, write to us and we will delete the records.

12. What this policy does not promise

We would rather be believed on the small claims than doubted on the large ones, so here is what we are not saying.

We do not claim to be anonymous. We hold the key that links a subject ID back to your hardware. See section 3.4.
We do not claim that a device we verified is physically in the hands of the person who operates it. Attestation proves properties of hardware, not custody of it.
We do not claim that work running on a node is hidden from whoever owns that node’s hardware. That is a separate and much harder problem, and our technical materials say where we are on it.
We do not claim that a passing verification means a job completed correctly. A verification record is a statement about a device at a moment, not a guarantee about an outcome.
We hold no SOC 2 report, no ISO 27001 certificate and no HIPAA attestation, and we say so rather than imply otherwise.
We are a company of one person. We do not claim a security team, a 24-hour response capability, or an independent audit, because we have none of those things.

13. Changes to this policy

When this policy changes we will update the version and effective date at the top and keep previous versions available, so you can see what changed and when. Where a change materially reduces the protections described here, we will publish it before it takes effect rather than after.

Version 1.1 adds accounts, sign-in and device claiming, which version 1.0 described as planned. Version 1.2 adds the testers’ page and its cookie (section 2). Version 1.3 adds billing through Stripe: what we hold once an account is billed (section 4), how long those records are kept (section 6), and Stripe itself as a provider (section 8).

14. Contact

Privacy and data-subject requests: privacy@svnkg.com
Security and vulnerability reports: security@svnkg.com
Legal notices: legal@svnkg.com
General enquiries: contact@svnkg.com
Postal: SEVEN KG LLC, 4601 E. Douglas STE 150, Wichita, Kansas 67218, United States