Privacy

The plugin

Heimdall3D makes no network connections. It does not check in, does not look for updates and does not report what you opened. That is not a policy that could quietly change in a later build: the DLL imports only GDI32, KERNEL32 and USER32. No networking library is linked into it at all. Anyone can verify that with a dependency viewer.

Your licence key is checked on your own machine against a key embedded in the plugin. No activation, no machine fingerprint, no account. Nothing about the files you browse leaves your computer.

If the plugin crashes it writes one short text file on your own machine. That file records the fault, the call stack, the name and size of the file being previewed, and how far the preview had got. It goes to %LOCALAPPDATA%\Heimdall3D\crash, or to the LocalLow folder of the same name when the Windows preview pane is the host.

The newest five are kept and older ones are deleted. Nothing is sent anywhere, and you can delete the folder at any time. A full memory image of the process is written only if you set HEIMDALL_CRASH_DUMP=1.

This website

Reading these pages sets no cookie. This site can set five, and each is set by one thing you do. Signing in to the forum sets heimdall_member. It holds a session token and nothing else, and it goes with every request to this site, because every forum page has to know who is reading it. It lasts at most 90 days from the sign-in, however often you visit, and then you sign in again. Signing in to the admin area sets heimdall_admin, which also holds a session token and nothing else. Its path is /admin, so your browser does not send it with a request for a public page. Following the link in a forum account recovery mail sets heimdall_recover, a session token for the page on which you register a new passkey; its path is /account and it is sent nowhere else. A passkey ceremony, which is a sign-in or the adding of a passkey, sets heimdall_ceremony when it starts and clears it when it finishes, and that one is also sent only under /account.

The fifth is described under Counting visits below. It is set only in the admin area, only by me, and its only effect is to leave a browser out of the count.

No analytics service, no tracking pixels, no embedded fonts. Nothing on this site reports to anyone else about you, and the counting described below is done by this server alone. Every page except the one that takes a payment loads nothing from anywhere but this server, and the site's own content-security policy forbids it on those pages rather than leaving it to good behaviour.

The exception is the buy page, and it is described under When you buy below. It is the only page on this site that loads a script from anyone else.

Besides the page view record described below, the site software writes only a log. It writes startup messages, errors, and a few lines saying what it did: that a report was stored, how long it was and which country it came from, that a download was asked for under a filename this build does not publish, that a sign-in used a recovery code or a code that was already spent, how many expired sessions were deleted. No line carries an email address, an IP address, or the text of a report.

The site runs on a server in Nuremberg, Germany, rented from Hetzner. No content delivery network sits in front of it and no request is routed through a third party. Hetzner is my processor for the hosting itself and does not read the data.

The web server in front of the site writes one ordinary log line per request: your IP address, the time, the page or file requested, the response status and the browser's user agent string. That is what any web server writes. No figure on this site is taken from it: page views are counted as described above and downloads as described below, both by the site software itself. Those lines stay on that machine, are not joined to anything else, and are not sold or shared.

On the machine itself, the operating system records service start and stop events, as any Linux system does. Nothing there identifies a visitor.

Counting visits

This site counts its own page views, so that I know how many people read it. Nothing on the page does the counting: there is no script, no pixel, no beacon and no third party, so there is nothing here for a blocker to remove and nothing that leaves this server. The count is made by the site software while it answers the request, and it is not sent to anybody.

One row is written per page request. It holds the time, the page that was asked for, the status the server answered with, the host of the site you followed a link from if you followed one, the country your address is in, and one identifier. The page is recorded without anything after the question mark. The referring site is recorded as a host and never as a full address, because a full one can carry a search you typed or the title of a private page. The country is looked up on this server against a database held here, so no lookup goes anywhere. Files a page pulls in, such as images and video, are not counted separately from the page that pulled them.

Your IP address is not stored, and neither is your browser string. What is stored instead is the identifier, and it is what makes the figure people rather than requests. It is a hash of your address and your browser string together with a random value generated fresh for each day and held only in this database. Your address cannot be read back out of it. That random value is deleted the day after the day it belongs to, so only the last two or three days of them are ever held here, depending on how long it is since the hourly sweep last ran. Once a day's value has gone there is nothing left with which to turn that day's identifiers back into an address, and nothing with which to tell that an identifier from that day and one from another day belong to the same person. So your visits on any day whose value has gone cannot be traced back to you, and cannot be linked to each other. Today's value has to exist in order to count today, which is why this says older days rather than every day.

Each row is filed as one of four kinds, and it is worth knowing why, because most requests to this site are not people. A row is a person; or me; or a client that says it is not a person, which covers search engine crawlers, command line tools, monitors and the services that fetch a page because somebody pasted the link into a chat; or a request for a page this site does not have, which is what probing for somebody else's software looks like. On the traffic this site actually receives, the last of those is most of it. All four kinds are kept and all four are shown to me, because a figure that quietly threw traffic away would be a figure nobody could check.

My own visits are the second kind and they are left out of the first. Signing in to the admin area is enough on its own, and when I do, the identifier my browser produced that day is marked as mine so that the visits I make signed out that day are left out too. That mark is a hash of the same sort, it means nothing once the day's random value is gone, and it is kept and deleted on the same schedule as everything else here.

That leaves the fifth cookie. It is named heimdall_not_counted, it holds the single word excluded and no identity of any kind, its only effect is to keep the browser holding it out of the first figure, and it lasts a year. It can only be set from inside the admin area, so reading this site will never give it to you. It is named here because it is a cookie this software is able to set, not because it can reach you.

These rows are kept for 400 days and are then deleted. That is a year, so that a month can be compared with the same month a year before, and a margin on top of it. The random values are not kept anything like that long, as above: a row spends all but its first two days with nothing in this database that could reverse it.

When you download the build

Asking for a build writes a row, and this record is not like the page view record above: it keeps your IP address rather than a hash of it. One row per request. It holds which file and which version was asked for, the time, the status the server answered with, how many bytes actually reached you and whether the transfer finished, whether it was a resumed or partial request, your IP address, the country that address is in, your browser string, the address you came from if you came from one, and the language preference your browser sends.

It is kept in that detail because a download figure means nothing without it. Most requests for a large file are not somebody taking the build: they are crawlers, transfers that stopped part way, and clients asking for the first few bytes to see what is there. Telling those apart from a real download needs a record of what happened to each one. The same details are mailed to me when a build goes out, which is how I see that the machinery is working.

These rows are kept for 90 days and are then deleted, the address with them. That is the whole of it: the record is not joined to a purchase, to an email address, or to the page view record above, and it is not sold or shared.

When you buy

The payment is handled by a reseller acting as merchant of record. Card details go to them and never reach this server or me. I could not see them if I wanted to.

The buy page loads one script from cdn.paddle.com, which is the reseller's own. Opening that page fetches it, so Paddle's servers see the request: your IP address, the time, and the browser string, the same three things any server sees. No other page on this site loads it, and the script is not on the pages you read before deciding to buy.

That script tries to load a second one, an analytics library at public.profitwell.com. This site's content-security policy names Paddle's own domain and nothing else, so the browser refuses that request and it is never fetched. The claim above that nothing on this site reports to an analytics service holds on the buy page too.

Pressing the buy button opens Paddle's checkout in a frame over the page. Everything typed into it goes to Paddle and not to this server: your name, your address, your card number and your VAT ID if you give one. Their frame is theirs, and this site cannot read what is in it. What comes back to me is the outcome, described in the next paragraph.

What I receive is your email address and the order reference, and those exist for exactly two purposes: to issue your licence key, and to send it to you again if you lose it. Your address is also written inside the key itself, which is how the key stays personal to you and why a shared key is not anonymous.

That reseller is Paddle. They are a separate controller for the payment data, not my processor: they decide what they collect to take a card payment, to meet their own anti-fraud obligations, and to charge and remit the VAT in your country. Their policy governs that data, and this one cannot speak for it.

The order records I keep are your email address, the order reference, what was bought, the time the merchant billed it, and the time your key was sent. No amount and no payment detail is stored here. Those are business records under German law, so they are kept for the statutory retention period set by § 147 AO and § 257 HGB. That period is longer than most people expect, and it is not mine to shorten: an invoice I am required to be able to produce is not something I may delete on request. Everything outside those records is deleted when it stops being useful.

When you send a report

The form on the front page stores exactly what you type into it: the description, and the email address if you filled that field in. Nothing else is recorded with it. No IP address, no browser string and no identifier of any kind is attached to the report, so a stored report cannot be traced back to the person who sent it unless that person put their address in it.

Reports are read to fix the thing they describe. An address given with one is used to answer it and for nothing else: it is not added to any list. Reports are deleted when the thing they describe is fixed or judged not to be a fault.

The release list

If you give your address to the release list, that address is stored so a confirmation request can be sent to it. Nothing is sent to an address that has not answered that request, which is the double opt-in that § 7 UWG requires. An address that never confirms is deleted rather than kept.

The list carries one message per release and nothing else. It is not shared and not sold. Every message carries an unsubscribe link, which opens a page with one button and needs no reply and no account. The address is kept after that, and kept for one purpose: so that it stays off the list. You can also ask to have it erased outright by mailing quark@heimdall3d.com.

When you email me

Support email lands in an ordinary mailbox and stays there until it is no longer useful. If you send a file so I can reproduce a bug, it is used for that and deleted afterwards.

Key recovery

The recovery page emails your key to the address that bought it, and never displays it. That is a privacy decision as much as a security one: a page that showed a key to whoever typed an address would let anyone find out what someone else had bought.

Accounts

There are two kinds of account here, and they do not hold the same things. One is a forum member's account. The other is my own admin account, and there is one of it.

A member account holds the email address, whether and when it was confirmed, the handle you chose, a display name if you gave one, the account's role, when it was made, and when it was deleted if it has been. It holds no password. A member signs in with a passkey, and the column a password hash would go in is empty for every member. The account also holds one opaque identifier: a random value that your browser presents during a passkey ceremony in place of the address, so the address itself is never what the ceremony is about. The handle is public. It is the name your posts appear under.

The admin account holds two things more. A password hash, from which the password cannot be recovered, and the secret behind its second sign-in factor. That secret is stored encrypted under a key that lives in the server's environment and never in the database, which is named here because it changes what a copy of this database would contain.

A passkey is a pair of keys made on your own device. What this server holds is the public half, together with an identifier for the credential, the algorithm it uses, a counter the device advances each time it signs, an identifier for the make of authenticator, a hint about how it connects, whether the device reports the passkey as backed up, a name you gave it if you gave one, and when it was added, last used and removed. The private half never leaves your device and this server never receives it. A public key can check a signature and cannot make one, so what is held here cannot be used to sign in as you.

Signing in records the address and the browser string the sign-in came from, so the account holder can see their own sessions and end one they do not recognise. That is the same row for both kinds of account. A session row is kept until it expires or you end it, whichever happens first, and the row is deleted within an hour of that.

Deleting a member account clears every column that names a person: the address, the display name, the handle, and the passkey identifier above. Your passkeys are deleted and your sessions are ended. The row itself stays, and so do your posts. They are shown as written by a former member, and every reply and quote that pointed at them still resolves, which is why the row is kept rather than removed. The handle is retired: it goes on a list of names that will not be issued again, dated to the day and holding no link back to the account, because posts under that name stay readable and a name quoted and linked for a year should not become somebody else. After that the account holds nothing that names you. Records kept for another reason, such as an order, are kept under the section that describes them.

A member whose confirmed address is the address on a purchase is shown a licence badge on the forum. The badge is not stored and it is not something you claim: it is a lookup, made when it is needed, joining the address on the account to the address on the order records described under When you buy. It is not a code anybody types. The plugin plays no part in it: your licence is checked on your own machine, and the plugin never asks this site anything.

Actions on an account are recorded in one trail: which account acted, what it did, when, and the address it acted from. For a member that includes confirming the address, each passkey sign-in, a recovery request, and the deletion itself. Deleting the account does not remove those lines; they keep the account's number, which after deletion identifies nobody. That record is kept rather than pruned, because it is itself a security control. None of this is passed on to anyone.

A failed sign-in to the admin area is recorded the same way, and that one can be about somebody with no account here. The record holds the email address typed into the form, the IP address it was sent from, the time, and a short reason the attempt failed. That reason says which step failed, so it records whether an account exists at that address. It is written whether or not one does, so typing an address into the sign-in form puts it in that record even if it has never been used here for anything else.

Those rows are kept indefinitely. An attempt to get into the admin area is the thing an audit trail exists for, and a trail that expires before the attempt it describes is found is not one. The admin area is not linked from any page and its form is not the one the forum asks you to sign in with, so a row here is either mine or somebody probing the form. A member's sign-in writes a line to the trail when it succeeds and nothing when it does not.

Your rights

You can ask what I hold about you, ask for it to be corrected, or ask for it to be deleted, subject to the retention periods above. Email quark@heimdall3d.com. You also have the right to complain to a data protection supervisory authority.