This policy covers the gunbix.com showcase website and the application available at app.gunbix.com. It supplements the Privacy Policy, to which it refers for everything concerning the processing of personal data.
A cookie is a small text file placed on the User's terminal equipment when a website is visited. Similar technologies are treated as cookies for the purposes of this document: pixels, tags, and browser local storage.
Their placement and reading are governed by Article 5(3) of Directive 2002/58/EC (the "ePrivacy" Directive), transposed into Belgian law by Article 10/2 of the Act of 30 July 2018 on the protection of natural persons with regard to the processing of personal data, and by Regulation (EU) 2016/679 for any resulting processing of personal data.
That provision replaced Article 129 of the Act of 13 June 2005 on electronic communications, repealed by Article 256 of the Act of 21 December 2021 with effect from 10 January 2022. Since that date it is the Data Protection Authority that is competent in Belgium for tracking technologies, no longer the BIPT.
The rule is as follows: a cookie strictly necessary for the provision of a service expressly requested by the User does not require consent. Any other cookie does.
The showcase website consists of static pages. It contains no audience measurement script, no pixel, no iframe, no remote font and no third-party component. Its content security policy in fact forbids the browser from contacting any external origin whatsoever.
No cookie is placed there.
A single item of information is stored in the browser, in local storage rather than in a cookie:
| Key | Content | When it is written | Retention |
|---|---|---|---|
gx-theme |
light or dark |
Only if the User operates the appearance toggle themselves | Until erased by the User |
This value is never transmitted to a server, allows no identification, and is written only following an explicit action by the User. It therefore falls within the exception in Article 5(3).
The application places no authentication cookie. This is a deliberate design decision and not an omission, and it is worth stating precisely, because the mechanism is unusual.
Authentication works as follows. The User requests a sign-in code, which is sent to their email address; the code is valid for ten minutes, may be attempted five times, and is compared in constant time. Once verified, the server issues a session token, which the application stores on the device and presents on each request in the Authorization header.
That token is held:
| Platform | Where | What that protects, and what it does not |
|---|---|---|
| Web | Browser local storage, partitioned by origin (app.gunbix.com) |
Isolates the token from any other website. Does not protect against a script injected into our own page, which is what the content security policy is for |
| Android | The application's private preferences file, isolated by the system sandbox and covered by device encryption | Not the hardware keystore |
The server accepts the token only in the Authorization header, never in a cookie. A cookie is sent automatically by the browser, so an API authenticated by cookie must defend itself against cross-site request forgery. Requiring an explicit header removes that class of attack rather than mitigating it.
The consequence for this policy is straightforward: since the token is not a cookie, no cookie banner could offer to refuse it, and refusing browser local storage makes the application unusable in the same way that refusing an authentication cookie would.
The real safeguard against a stolen token is not where it is stored but the fact that it can be revoked: a session lasts thirty days at most, its expiry is absolute and is not extended by use, only a fingerprint of the token is held in the database, and a session may be revoked from any of the User's devices with effect for all of them.
Cloudflare, the hosting provider, may in addition place a technical security cookie intended to distinguish a human visitor from a robot. It is strictly necessary to the protection of the Service and serves no other purpose.
The application stores in the browser's local storage, and not in cookies, the chosen theme, the accent colour, the display language and whether the side menu is collapsed or expanded. These values are transmitted to no server and allow no identification.
The application loads the Google Maps library at the moment a screen needs a map, and on the first keystroke in an address field for autocompletion. It no longer loads it when the application opens: until 22 August 2026 it was loaded on every screen, including those that display no map, so Google received the IP address of every visitor before that visitor had asked for anything. A User who opens neither a map nor an address form does not contact Google.
When it is loaded, Google receives the terminal's IP address and the address of the page, and may place its own cookies, governed by its own policy. The detail is set out in the list of processors.
A User who wishes to object may block the maps.googleapis.com domain in their browser; the mapping screens will then stop working, while the rest of the Service remains usable.
A web page does not only load tracking technologies: it also loads the code and the typefaces it needs in order to display. These requests place nothing and read nothing on the terminal, but they do reveal to the server that answers them the visitor's IP address and the address of the page being viewed. This page lists them because a User who wants to know who their browser contacts on opening should be able to read it, even where the answer is not a cookie.
When the application opens, no request goes to a third party. The rendering engine, the brand typefaces, the fallback typefaces and the images are all served from Gunbix's own servers. Established on 23 August 2026 by observing the actual network traffic of the deployed application, and not by reading the code.
That was not the case the day before. Four loads went to Google on each opening, none of which was visible from any screen:
| What was sent | To | Removed on |
|---|---|---|
| The Google sign-in script, inherited from an abandoned module that no screen used any more, and capable of placing cookies | accounts.google.com |
23 August 2026 |
| The modules of a database service that was no longer in use | www.gstatic.com |
22 August 2026 |
| The application's rendering engine | www.gstatic.com |
22 August 2026 |
| Two fallback typefaces for the rendering engine, including the general-purpose Roboto typeface | fonts.gstatic.com |
23 August 2026 |
What guarantees that this remains the case. The rendering engine reports nothing when a typeface is missing: it displays empty boxes in place of the affected characters. Nobody would notice before a User complained about the way their name is written, and the temptation would then be to restore loading from Google. Because the addresses of these typefaces carry a version number, an update to the engine calls for others that the copy held by Gunbix would not contain. An automated check is therefore run on every deployment: it causes publication to fail if a single typeface file is missing. The statement made in this article is held in place by that check, and not by the vigilance of whoever wrote it.
The request for a sign-in code may be protected by Turnstile, a Cloudflare check that distinguishes a human visitor from a program. To do so it loads a script served by challenges.cloudflare.com.
This check is switched off as at 30 August 2026, and for as long as it is, no request goes to that domain: the browser asks the server whether the check is active before displaying the sign-in screen, and loads the script only if the answer is yes. It is described here in advance, because the wiring is in place and switching it on will require only a configuration change.
When it is active, this check will be strictly necessary to protect the Service against the automated sending of sign-in codes, and will serve no other purpose, in particular no audience measurement.
Gunbix operates no audience measurement tool, neither in-house nor third-party. No usage statistics are collected by cookie or by tag.
Gunbix places no advertising cookie, builds no marketing profile and shares nothing with any advertising network.
If audience measurement were introduced, this page would be updated and the User's prior consent would be obtained.
A tracking pixel slipped into an email is a one-pixel image, hosted on a server, that the mail software fetches at the moment the message is displayed. That request reveals that the message was opened, at what time, and from which IP address. It is a tracking technology, and it falls under the same Article 5(3) of the ePrivacy Directive as a cookie: the provision covers not only cookies but the storing of information and the gaining of access to information already stored in the User's terminal equipment. The same applies to a link rewritten in order to count clicks.
Gunbix emails contain none of these. The template that produces them contains no image, neither remote nor embedded, and no link is rewritten. What is measured, by contrast, is the delivery of the message: its acceptance or rejection by the recipient's mail server. That information is reported by mail servers and not by the recipient's software; it involves neither storing anything in nor reading anything from their terminal equipment, and therefore does not fall under Article 5(3). The detail is set out in Article 2.8 of the Privacy Policy.
If open tracking were to be introduced, this page would be updated beforehand and the User's prior consent would be obtained, with withdrawal made as simple as agreement.
A consent banner only makes sense if there is a cookie to refuse. To date, the only mechanisms that write or read information on the terminal are either strictly necessary or triggered by an explicit action of the User, and none is subject to consent.
No solicitation of a third party precedes the User's first action: the requests that once did have not been justified, they have been removed (Article 3.4).
On the day a cookie that is not strictly necessary is placed, a consent mechanism will be put in place, with refusal as easy to express as acceptance, and this page will be updated beforehand.
The User may at any time, from their browser settings, block or delete the site's cookies and local storage. Erasing local storage signs the User out, because the session token is held there (Article 3.1), and returns the display to its default values.
The help pages of the main browsers explain how to proceed: Mozilla Firefox (support.mozilla.org), Google Chrome (support.google.com), Microsoft Edge (support.microsoft.com), Apple Safari (support.apple.com), Brave (support.brave.com).
Data processed in connection with the mechanisms described above is processed under the conditions set out in the Privacy Policy. The User has in respect of that data all the rights provided for in Articles 15 to 22 GDPR.
This policy is updated as soon as the mechanisms described change, and before any cookie not listed here is placed.
For any question concerning the use of cookies: privacy@takion.be.
TAKION SRL Rue Mansart 39/A 7534 Tournai Belgium