Your hunting data is locked.
Only you hold the key.

What "zero-knowledge" means

All of your hunting records are encrypted on your device before they reach our server. The server is a dumb, encrypted storage: it holds your data but cannot read it. The key is never on the server, not in backups, not in log files.

This applies from the first minute. In the setup assistant you choose a ground password, it is mandatory there, and that one password is also the key: it opens access and it decrypts the data. There is no second, silent password beside it, and the server does not allow one. In the same step 12 recovery words are generated inside your browser, and that is the only place they are readable. There is no operator emergency key: none that we could hand over on request, not even on a court order.

What is protected

Everything that makes up your hunting ground. Not just photos and notes, but also positions, game species, dates, boundary and harvest:

Map & 3D: the same protection by a different route

Your entries are encrypted by your device before they set off. For the map files that is not possible: the boundary, the terrain model and the aerial imagery stock are produced on the server when your 3D map is built, out of official survey data. Hence the second route.

What stays in clear text

The absolute minimum without which the server cannot function. This data contains no hunting data:

That is the frame, not the contents. The server knows: "Account #31 pays for Hunting Ground #71, which uses 2.3 GB, lies in Lower Austria and had its model built in this area." It does not know where your boundary runs, not where a marker stands, not what you harvested, not what is in your photos. Your IP address sits in the running access log, as with any web server; we do not analyse it and we do not keep it permanently. The payment country (Paddle) is mandatory for tax reasons and sits with Paddle, not in our database. The payment country is mandatory for tax reasons and sits with the payment processor, not in our database.

Two of these tend to surprise people, so plainly: the ground name and the names of your trail cameras are clear text. The server needs the ground name to log you in and show you the right ground, and the camera name because it has to file your camera's pictures while your phone is asleep. Whoever gives a ground or a camera a field name is giving away a hint about the place. If you would rather not, pick a neutral name; the pictures and everything else are untouched by this.

The named exceptions

Encryption that promises everything lies. What follows is what the server knows about your hunting ground, and above all when: what it never sees, what it briefly sees while computing, what it knows permanently, and what is left in the logs. This list is the state as of 4 September 2026. We measure it against the program code instead of asserting it, and when something turns up, it comes here.

1. What the server never sees

Everything you enter: markers with their positions, notes, photos and videos, harvest and cull plan, the stand-hunting diary, trail-camera pictures, the ledger with its receipts, your boundary and the parcel numbers behind it. Of all that, only ciphertext sits with us. We cannot read it, cannot decrypt it and cannot hand it over, not even on a court order.

2. What it briefly sees while computing

• The window while editing and building. When you edit the boundary or have the 3D map built, your browser sends the boundary along for that one request, because the server is meant to compute for you. It goes into a file that exists only in memory, and that file is deleted when the job ends, even if the build crashes. It never lands on the hard disk, not even as a backup copy. Between two such requests the boundary is closed to the server.
• The moment a document is made. The GPX file, the cull-plan record, harvest lists, the annual report, statistics and the ledger exports are typeset by the server, and when it emails a sheet to an authority it sees that sheet. Your browser decrypts exactly the rows that belong on it and sends them along for that one request. The server sets the sheet, hands it back and keeps nothing of it.
• Trail-camera images at the moment they arrive. A trail camera sends its image to the server, not to your phone, and usually every device of yours is asleep. So the server seals the image itself, immediately on arrival, with the public key of your hunting ground. After that it cannot open it. It sees the image once, for a fraction of a second, and never again.
• The build fetches from official sources. While your 3D model is being made, our server fetches aerial imagery, the elevation model, tracks and waters from the official sources on your behalf (in Austria basemap.at and the BEV, plus OpenStreetMap). Those requests name the map section you are having built. So the outside bodies see the area, never your boundary and never your entries, and they see our server, not you. Before the build of a locked ground there is therefore a text of its own that you have to confirm.
• One coordinate for the twilight analysis of the trail cameras. That panel needs a point on the earth, and in a locked ground the server has none: the location part of the map file is sealed along with everything else. Your device therefore sends the coordinate with that request, rounded to two decimal places. That is a cell roughly 1.1 kilometres tall and 0.75 kilometres wide, and your ground sits somewhere inside it. The coordinate travels in the body of the request and never in the address, and it is written nowhere: not into the database, not into a file. In memory it sits as the note of a short-lived cache until the service restarts. If it is missing, the server says so openly and the affected panels stay empty, rather than showing a figure computed for somebody else's location. What this rounding is not: a hiding place. Where your model was built, the server knows more precisely anyway, and permanently (point 3). The rounding only makes sure that no more precise a point than necessary goes down the wire.
• Weather. Your device rounds weather points to 0.01 degrees, about one kilometre, before querying. It contacts GeoSphere Austria for Austrian grounds and Bright Sky with DWD data for German grounds directly; these services see the rounded location and your device's IP address. Supplementary forecasts, the wind field and fallback weather come from Open-Meteo hosted on our own infrastructure, as does the Swiss forecast. Our server sees those rounded points during the request, checks your session and subscription, and forwards no session data to the weather service. Points are sent in the request body, not the URL. Location-specific responses stay briefly in memory; there are no permanent weather-location logs. Model synchronisation is independent of ground locations. “Do not fetch weather” under “Weather & sky” disables all these queries per device; it does not undo earlier queries.

3. What it knows permanently

• Where your 3D model sits. This is the furthest-reaching exception on this page, so it comes first. So that your diorama works without a signal, the server fetches a square of map at build time and stores it inside your ground: elevation model and aerial imagery around your boundary, for a typical ground a good eight kilometres across. The pictures inside it are encrypted, their folder names are not, because a folder name is the number of the official map sheet the picture came from, and from a sheet number the place can be computed back. Anyone holding our server can read from it which piece of map had a model built here, to about fifty metres. What they cannot read: where your boundary runs inside that square, where a marker stands in it, what you have recorded, and where you are right now. The square is markedly larger than the ground inside it and says exactly one sentence: a map was built here. We could make those folder names unreadable, and we have not, because the offline delivery hangs on precisely these names; as long as that is so, we would rather say it than keep quiet about it.
• The frame around your ground. Ground name, country and region, the master data for official forms and the names of your trail cameras sit in clear text in our database. They are listed one by one above. The server needs them to log you in, to deliver, and to pick the right shooting-season table. Whoever gives a ground or a camera a field name is giving away a hint about the place.
• Where your map comes from. For every hunting ground it stays readable which official source its map was built from: the elevation model, the aerial imagery and the body that publishes them (for an Austrian ground, the BEV and basemap.at, for example). The server needs that name in order to find your ground's map stock again. What follows from it is the country, and in Germany the federal state as well, because each state there has its own survey office.
• The dimensions of the model. The edge length of the square, the number of tile pictures and how much space they take stay readable, because the server delivers by them and counts your storage. None of those figures says anything about contents.
• Timing and counts. The server knows how many rows your hunting ground holds, when one is added and when it is changed. That is the price of several devices sharing one state and of the trash bin working at all. What the row says, it cannot see. Someone watching long enough can tell that you entered something on Friday evening, but not what.
• Credentials for a camera portal. If you let our server collect your images from a camera portal, it has to be able to log in there. Those credentials are stored encrypted, but the key for them sits with us, not with you. It is the one place in the whole product where we can unlock something, and it concerns that single portal password, no hunting data. Whether you deposit it is your decision.

4. What the logs give away

Like every web server, ours keeps an access log: which address was fetched when, plus the IP address, the browser and the page you came from. Two things in it relate to place, and we would rather name both ourselves:

• Map tiles are fetched by their sheet number, and that number therefore sits in the address. Anyone reading the log can follow which map section somebody looked at, at what magnification and in what order. It is the same place as in point 3, now with a timestamp as well. What is recorded on the map is not in there: markers, boundary and photos travel encrypted down the same wire.
• Switching between 2D and 3D carries your map section into the address, so that you carry on in the same spot. That address is in the log too, and it is more precise than anything else here. This is neither an accident nor a bug, but the price of the jump not landing somewhere else on the map. It is the same section you have on your screen at that moment.

We do not analyse these logs, and they live only as long as the running program version: every time a new version is installed they are thrown away. None of it sits in our database, which has no column for IP addresses. One exception we built ourselves: the frame-rate measuring panel (the view with ?perf=1) has a button "Bericht senden" (send report). Whoever presses it sends us frame rates and device details, and we store that report with the IP address and the ground number as a file, so that we can match feedback to it. That happens only when you press the button and contains no ground contents.

How encryption works

Additional protection

Encryption is the foundation. On top of it stand further layers:

Password & recovery

The flip side of real encryption: no key, no data. If no one still has the hunting-ground password, the encrypted data is irretrievably lost. We cannot restore it either.

That is why 12 recovery words are generated when you set up your ground, inside your browser. That is the only place they are readable. On our server they sit encrypted, and only your own ground key opens them: to us they are the same alphabet soup as your markers. Write them down and keep them separate from the password. You can look at them again at any time in the planner, as long as your device is unlocked.

A ground password must be at least 10 characters long, and the server checks that. It is one secret for the whole hunting ground and at the same time the key to it: pick a sequence of words nobody outside your team would guess, and none you already use elsewhere. A weak password makes even the best encryption attackable.

The proof: see it on your own data

The strongest promise is worthless if you cannot verify it. This is what a marker looks like as it leaves your device: on the left what you read in your hunting ground, on the right what arrives in our database.

The example above is one instance. You can check it yourself, without taking our word for it: open your browser's developer tools (F12), the "Network" tab, and create a marker in your hunting ground. The request that goes out carries no name, no coordinate and no species word, just a single field of alphabet soup.

Four levels of verifiability

• An automated guard (running): before every release, test suites drive the real server and measure each write route for whether any content field goes out in clear text. With a counter-probe: switch the encryption off and they must go red.
• Your own look at the network (any time): the paragraph above. It costs you two minutes and requires no trust.
• Open code: the client code will be published; today it is still private.
• Bundle hash and a rebuildable release: every release will then name the hash of the delivered program, and anyone can rebuild it from source and compare.

Whitepaper & sources

You know cryptography? The technical whitepaper contains the full threat model, all parameters, design rationales and honest limits: