Cookie and Browser Storage Policy
B.1. Purpose and scope
B.1.1. This policy explains what information the Zero Door application console operated by Zerone Siber Güvenlik Limited Şirketi (“Zerone”) stores on the user’s terminal equipment (browser), for what purpose, for how long, and on what legal basis. It discharges the cookie-related part of the transparency duty under Article 10 of Turkish Law No. 6698 on the Protection of Personal Data (the “Law”) and satisfies the requirement for a separate and accessible cookie disclosure set out in the Guidelines on Cookie Practices published by the Turkish Personal Data Protection Authority.
B.1.2. This policy covers both installations hosted by Zerone as a service and installations that the Customer hosts in its own infrastructure. The cookies and storage items written to the browser are identical in both cases; a Customer running an on-premises installation may adopt this policy towards its own data subjects.
B.1.3. The Zero Door agent software is not a browser component, uses no cookies, and falls outside the scope of this policy.
Scope note: this policy addresses the Zero Door application console. Zerone’s marketing website is governed by a separate document (docs/legal/04-web-ve-ticari-iletisim/61-web-sitesi-gizlilik-ve-cerez-metni.md), and the findings recorded here shall not be extended to that surface.
B.2. What a cookie is, and the categories used
B.2.1. A cookie is a small text file placed on the user’s terminal equipment through the browser when a website is visited, and returned by the browser to the issuing domain on subsequent requests. Cookies are either session cookies (deleted when the browser closes) or persistent cookies (retained for a defined lifetime), and either first-party (written by the visited domain) or third-party (written by another domain).
B.2.2. Four functional categories are used:
| Category | Definition | Consent required |
|---|---|---|
| Strictly necessary | Technically required to deliver the service the user has explicitly requested: session continuity, authentication, security, load balancing | No |
| Functional | Remembers a preference the user has chosen (language, appearance, layout) so the service can be delivered in a personalised form | No, where written on an explicit user action and carrying no identifier |
| Performance / analytics | Measures visitor behaviour, page views and usage statistics | Yes, prior explicit consent |
| Marketing / targeting | Advertising delivery, profiling, cross-site tracking, conversion measurement | Yes, prior explicit consent |
B.2.3. The Zero Door console uses cookies falling only into the first two categories. No performance, analytics, marketing or targeting cookie is used.
B.3. Complete list of cookies used by the Zero Door console
B.3.1. The table below is the complete list, verified against the source code. No cookie other than those listed is written by the console.
| Cookie name | Purpose | Category | Lifetime | Party | HttpOnly | Secure | SameSite |
|---|---|---|---|---|---|---|---|
next-auth.session-token | Maintains the session and carries the authentication token without it ever being exposed to browser JavaScript | Strictly necessary | 7 days | First party | Yes | Yes over HTTPS | Lax |
next-auth.csrf-token | Cross-site request forgery (CSRF) protection token | Strictly necessary | Session | First party | Yes | Yes over HTTPS | Lax |
next-auth.callback-url | Returns the user to the correct page once the authentication flow completes | Strictly necessary | Session | First party | Yes | Yes over HTTPS | Lax |
NEXT_LOCALE | Remembers the language (en, tr, ar) the user has explicitly selected | Functional | 365 days | First party | No | Not applicable | Lax |
B.3.2. Secure-connection prefixes. In installations served over HTTPS the session cookie is written under the name __Secure-next-auth.session-token, which the browser will transmit only over a secure connection. The other authentication-flow cookies are likewise written with a browser prefix in such installations. A prefixed and an unprefixed name are two deployment forms of the same cookie and do not constitute an additional cookie.
B.3.3. Specific note on NEXT_LOCALE. The internationalisation layer underlying the console tends, by default, to write a language cookie on every page response. That default behaviour has been deliberately disabled: the middleware returns its own response on every route, and the automatic cookie write is dropped. The NEXT_LOCALE cookie is written only where the user makes an explicit selection in the language switcher. The mere loading of a page is not the expression of a preference and does not cause a cookie to be written. The cookie carries no value identifying the user or the session; its content is one of three language codes and has no cross-site meaning.
B.3.4. The console writes no cookie belonging to a third-party domain, and does not facilitate the writing of one.
B.4. Browser storage that is not a cookie
B.4.1. The console stores the items below in the browser’s localStorage and sessionStorage. These items are not cookies: they are not transmitted to the server automatically, they are not carried in HTTP headers, and they can be read only by the application on the same origin. They are nevertheless disclosed here, because information is stored on the user’s terminal equipment and Article 10 of the Law requires transparency in respect of it.
B.4.2. localStorage (not cleared when the browser closes; persists until the user clears it):
| Key | Content | Purpose | Nature |
|---|---|---|---|
theme-store | Theme, corner radius, page layout, navigation bar and footer type preferences | Opens the interface in the appearance chosen by the user | Functional, contains no personal data |
sidebar-store | Whether the sidebar is collapsed, its type and its background | Interface preference | Functional, contains no personal data |
zerodoor_timezone | Selected time zone | Displays dates and times in the user’s time zone | Functional |
zerodoor_tenant_override_id | Identifier of the organisation a platform administrator is temporarily viewing | Multi-tenant administration; created only for users holding the super_admin role | Authorisation context, high sensitivity |
zerodoor_tenant_override_name | Display name of that organisation | Interface label | May contain a Customer organisation name |
zerodoor_tenant_override_slug | Short name of that organisation | Interface label | May contain a Customer organisation name |
zerodoor_getting_started_dismissed | Record that the getting-started card was dismissed | Prevents a dismissed notice from reappearing | Functional, contains no personal data |
zerodoor_whats_new_seen | Marker of the release whose what’s-new panel was seen | Prevents the same announcement repeating | Functional, contains no personal data |
zerodoor_tour_status | Local mirror of the product tour completion state | Prevents the tour restarting | Functional, contains no personal data |
zd_alerts_shortcut_hint_dismissed | Record that the keyboard shortcut hint was dismissed | Interface preference | Functional, contains no personal data |
zd-support-surface | Whether the support console opens as a panel or a window | Interface preference | Functional, contains no personal data |
B.4.3. sessionStorage (cleared when the browser tab is closed):
| Key | Content | Purpose |
|---|---|---|
sso_callback_url | Destination address on return from single sign-on | Returns the user to the intended page after the identity provider redirect. The value is deleted the moment it is read |
zerodoor:experience:journey-start and keys prefixed zerodoor:experience:done: | Timestamp mark used to measure interface readiness, and a completion mark preventing duplicate submission | Measurement of interface response time. The measurement is sent only to Zerone’s own backend service; its body consists of the event name, the view type, the starting source and a duration. It is transmitted to no third party |
zd_alerts_enrichment_banner_dismissed | Record that the enrichment banner was dismissed | Prevents it reappearing during the session |
zerodoor_seat_limit_banner_dismissed | Record that the seat limit banner was dismissed | Prevents it reappearing during the session |
zerodoor_license_banner_dismissed | Record that the licence banner was dismissed | Prevents it reappearing during the session |
zerodoor_tour_snoozed | Record that the product tour was snoozed | Prevents the tour reopening in the same session |
B.4.4. The console does not use IndexedDB. There is not a single production use of it in the source tree.
B.5. Session and refresh tokens are not held in browser storage
B.5.1. The access token, the refresh token and the token expiry marker are not stored in localStorage or sessionStorage. The session is carried in a cookie flagged HttpOnly, whose content cannot be read by JavaScript running on the page. Token material used transiently within the application is held in memory only.
B.5.2. This is a deliberate design decision that prevents a token from being read and exfiltrated in a cross-site scripting (XSS) attack, and it is locked in by an automated regression test: the test verifies that no token key is present in localStorage after sign-in, and that a forged token key planted from outside is never read by the application. The build pipeline fails if that test fails.
B.6. Absent cookies and verified positive findings
B.6.1. The findings below have been verified by source code review and are limited to the Zero Door application console.
- There are no third-party cookies.
- No analytics or statistics tool is loaded. There is not a single reference in the source tree to Google Analytics, Google Tag Manager, Segment, Amplitude, Mixpanel, PostHog or Hotjar.
- There is no advertising or targeting technology.
- There is no session replay tool.
- There is no error tracking tool. No Sentry or equivalent third-party error collector is present.
- Fonts are served locally. The interface font is loaded from a local file inside the application bundle; the user’s IP address does not reach a font delivery network.
- No content delivery network is used. The icon library is pinned to an offline build.
- A build gate protects this position. The build fails where the compiled output contains a reference to an external domain, and every exception is recorded with an individual justification of why it is inert.
B.6.2. Content security policy. The console sends a content security policy header on every response. Its directives are:
default-src 'self';
script-src 'self' 'nonce-<per-request value>' 'strict-dynamic';
style-src 'self' 'unsafe-inline';
img-src 'self' data: blob:;
font-src 'self';
connect-src 'self';
frame-ancestors 'none';
frame-src 'none';
base-uri 'self';
form-action 'self';
object-src 'none';
worker-src 'self' blob:;
manifest-src 'self';
upgrade-insecure-requests
B.6.3. The consequence of these directives, as regards cookies and tracking, is as follows: connect-src 'self' prevents the browser opening a request to any other origin; font-src 'self' makes loading an external font impossible; frame-ancestors 'none' prevents the console being framed by another site and tracked by that route; object-src 'none' disables plugin-based storage. The script-src directive contains no 'unsafe-inline'; scripts execute only under a single-use value regenerated on every request. 'unsafe-eval' is added in the development environment only, and the policy remains strict in test and production builds. The 'unsafe-inline' within style-src is a deliberate and bounded concession: style injection can re-skin the page but cannot execute code or exfiltrate data. Depending on the operator’s configuration, the header may be served in enforcing mode, or temporarily in report-only mode while a release is rolled out, in which case violations are recorded but not blocked.
B.6.4. The frame-src directive is 'none' by default. It is opened to the origin of the bot protection component described in clause B.7 only where that component is configured, and only an absolute https origin is accepted.
B.7. Bot protection component (disabled by default)
B.7.1. The sign-in screen carries a bot protection (captcha) component that may be triggered after failed sign-in attempts exceed a threshold. The component is disabled by default; unless a site key is configured it is never loaded and the user’s browser makes no request to the provider.
B.7.2. Where the component is enabled in an installation, the browser issues a script request to the provider’s domain. That request conveys the IP address, the user agent and the referrer to the provider. The component’s own browser storage is under the provider’s control and is not determined by Zerone. In addition, the end user’s IP address is transmitted to the provider by the server during verification.
B.7.3. The legal characterisation of that transfer, the safeguards applied and the identity of the provider are set out in 20-aydinlatma-metni.md, 21-privacy-notice.md and 29-alt-isleyen-listesi.md. In installations where the component is not enabled, no such transfer occurs.
B.8. Legal assessment: why there is no separate cookie consent banner
B.8.1. Every cookie used in the Zero Door console is necessary in order to deliver the service the user has explicitly requested. Without the session, CSRF and redirect cookies, authentication cannot occur, the session cannot be maintained, and the console cannot function. The language cookie is written only upon the user’s own explicit selection, carries no identifier and produces no cross-site value.
B.8.2. Under the Law, no explicit consent is required for these cookies. The session, authentication and CSRF cookies rest on Article 5(2)(f) of the Law, namely the legitimate interest of the data controller in securing its systems and accounts; that processing is narrow in scope and does not prejudice the fundamental rights and freedoms of the data subject. Since Article 12(1) of the Law obliges the data controller to prevent unlawful access to personal data, these session-security cookies also serve the discharge of a statutory duty. The language cookie rests on the same provision and is triggered by the user’s own act.
B.8.3. The decision not to rely on explicit consent here is deliberate. The Turkish Personal Data Protection Authority treats reliance on consent, where a legal basis other than consent is available, as an abuse of right. Asking for consent to a strictly necessary cookie offers the user a choice that does not in fact exist and is irreconcilable with the requirement that consent be freely given.
B.8.4. The position is the same under European Union law. Article 5(3) of Directive 2002/58/EC, as amended by Directive 2009/136/EC, exempts from the consent requirement any storage that is strictly necessary in order to provide an information society service explicitly requested by the user. The four cookies above fall within that exemption. The same provision makes clear that the exemption removes the requirement of consent but does not remove the requirement to inform; this policy discharges that duty of information.
B.8.5. For those reasons no cookie consent banner is displayed in the console. A banner shown for strictly necessary and functional cookies would invite the user to accept something that cannot be refused. The duty to inform, however, is not extinguished, and this policy is accordingly published and kept accessible under the /legal section within the console and at https://zeronesecurity.com/legal/.
B.8.6. Future change. Should any performance, analytics, marketing or targeting cookie, or any third-party measurement script, be added to the console, this assessment ceases to hold; before any such item is brought into service, a prior explicit consent mechanism, granular by category and offering refusal with the same ease as acceptance, will be implemented, and this policy will be updated at the same time.
B.9. Managing cookies and browser storage
B.9.1. The user may inspect cookies and site data through the browser’s settings, delete them individually or in bulk, block them for particular domains, and configure the browser to refuse all cookies. The relevant settings are found under: “Settings > Privacy and security > Cookies and site data” in Google Chrome and Microsoft Edge; “Settings > Privacy & Security > Cookies and Site Data” in Mozilla Firefox; “Settings > Privacy” in Apple Safari. In a private or incognito window, both cookies and browser storage are cleared when the window is closed.
B.9.2. The localStorage and sessionStorage items listed in clause B.4 are deleted together with the browser’s clear-site-data function. When the user signs out, the items relating to organisation switching are additionally cleared by the application.
B.9.3. Consequence of blocking strictly necessary cookies. Where the first three cookies in the table at B.3.1 are blocked or deleted, it is not possible to sign in to the console, an open session is terminated, and the service does not function. That is not an imposed restriction but the technical consequence of session-based authentication. Where the NEXT_LOCALE cookie is blocked, the console continues to operate; the language preference is simply not remembered on the next visit and the language code in the address path governs. Where the browser storage in clause B.4 is blocked, the console still operates; interface preferences revert to their defaults on each visit and dismissed notices may reappear.
B.10. Updates to this policy
B.10.1. This policy is updated whenever the cookies or browser storage items used by the console change. A new item is recorded in the tables before it is brought into service; an item that is removed is deleted from the tables.
B.10.2. On each update the version date is incremented and the current text is published at https://zeronesecurity.com/legal/ and within the console. Where the change is material, such as the addition of a new cookie category, it is additionally announced within the console before it takes effect.
B.10.3. Versions of Zerone’s legal texts are maintained together with acceptance records, so that the date on which each version was published is auditable.
B.11. Contact and requests
B.11.1. Questions concerning this policy may be sent to privacy@zeronesecurity.com.
B.11.2. A data subject may submit requests concerning the rights listed in Article 11 of the Law:
(a) in writing, by wet-signed petition sent to, or delivered by hand at, Yenibaraj Mahallesi, Nursultan Nazarbayev Bulvarı No: 1, İç Kapı No: 3, Seyhan / Adana, Türkiye;
(b) signed with a qualified electronic signature or mobile signature and sent to kvkk@zeronesecurity.com;
(c) sent to kvkk@zeronesecurity.com from the electronic mail address previously notified to Zerone and registered in Zerone’s systems.
Requests are concluded as soon as possible and in any event within thirty days. For full information on the identity of the data controller, the purposes of processing, transfers and retention periods, see 20-aydinlatma-metni.md and 21-privacy-notice.md.
Data controller: Zerone Siber Güvenlik Limited Şirketi MERSIS: 0998199408600001 · Trade registry no: 98809 (Adana Chamber of Commerce, chamber registry no: 95025) Tax office: Ziyapaşa Tax Office · Tax identification no: 9981994086 Address: Yenibaraj Mahallesi, Nursultan Nazarbayev Bulvarı No: 1, İç Kapı No: 3, Seyhan / Adana, Türkiye Telephone: +90 507 806 21 37 · Email: contact@zeronesecurity.com Data controller contact person: Hüseyin Volkan Akyüz, Director
Governing language. In the event of any discrepancy between the Turkish and the English text, the Turkish text prevails.