Privacy Policy

Any revision will be announced as a new version under Appendix A.1; earlier versions are never modified.

1. Introduction

HakoSpace is self-hosted software. This Privacy Policy describes how the HakoSpace software itself handles data. It does not govern any specific hosted instance, because we do not run any HakoSpace chat server instance. What HakoSpace does operate is: the official website and software release source; the opt-in anonymous Improvement Program (telemetry); license verification for commercial editions (not yet offered); the HakoSpace Official Account (which has its own Terms of Service and Privacy Policy and is outside this Policy); and an opt-in public server directory, hakoHub (Section 4A).

When you deploy HakoSpace, you are the one in control. Apart from the information involved in features you choose to turn on (the Improvement Program and hakoHub; see Sections 4 and 4A), the HakoSpace development team has no visibility into your server, your users, or your data.

2. Self-Hosted Architecture

This is the most important thing to understand about HakoSpace:

• HakoSpace runs entirely on infrastructure you control
• The HakoSpace development team has no access to any data stored on self-hosted instances (once you voluntarily turn on hakoHub, HakoSpace reads the directory information that server chooses to make public, see Section 4A; this is not access to stored data)
• We cannot read, monitor, or retrieve messages, files, user accounts, or any other data from your server
• Each server instance is fully independent and isolated from every other instance
• HakoSpace operates no central cloud service or shared database that carries chat content, and by default the software sends no telemetry or other server data to HakoSpace (the desktop application does, by default, connect to HakoSpace's software release source to check for updates; see Sections 4 and 6). The central services HakoSpace operates are limited to those listed in Section 1, of which telemetry and the directory must be turned on by a server administrator

Your server is yours. We have no way in; the only service that connects to a server is the hakoHub directory service: once you choose to turn hakoHub on and register, it periodically reads the directory information that server chooses to make public (Section 4A), which contains no messages, files or user accounts. In addition, when anyone submits a server address for registration with an Official Account, the directory service sends one verification request to that address's hub endpoint, whether or not the server has turned hakoHub on; if verification fails, no data about that server is kept.

3. Data Stored by the Software

HakoSpace stores the following data locally on the server operator's infrastructure:

• User accounts: username, display name, password hash (bcrypt), avatar image
• Messages and attachments: all chat messages and uploaded files sent by users
• Voice/video metadata: call records (who called whom, when, and for how long) stored in the local database. This metadata includes participant user IDs, session start/end timestamps, and channel identifiers — it does not include any audio, video, or screen-share content.
• Server configuration: settings, roles, permissions, channel structure
• Audit logs: moderation actions and administrative events, including the IP address of the person who performed the action (stored on the operator's server and not sent to HakoSpace)
• Server logs and IP ban list: the server log (hako.log in the data directory, kept for up to 30 days under the default rotation settings; in container deployments the same output also goes to the container log, kept as the operator configures) records the user ID and IP address of voice connections; IP addresses that trip rate limits are automatically added to the IP ban list, and the record is kept after the ban expires. All of this is stored on the operator's server and is not sent to HakoSpace. For the consent record stored when a user accepts the EULA and this Policy, see Appendix A.2.
• AI usage records: when the operator enables AI features, the software records, for each use, the member, the time, the provider, the model, the token counts, the cost (when OpenRouter is used), and whether it succeeded or why it failed. It does not record the content of the messages a member sends to the AI (a direct message itself is stored like any other message). Tool calls the AI performs are recorded with their parameters and results. Per-call records are kept for 30 to 365 days depending on the server setting (default 90 days); daily aggregate figures are kept.

3.1 Real-Time Media Data Flow (Camera, Microphone, Screen Share)

When a user activates their camera, microphone, or screen share, the corresponding media stream follows a relay-only path through the server:

1. Capture: The browser or desktop client captures frames from the device (via getUserMedia or getDisplayMedia). Capture occurs entirely on the participant's device; no frames leave the device until transmission begins.
2. Encoding & Transmission: Frames are encoded (VP8 / VP9 / H.264) and transmitted over an encrypted WebRTC connection (DTLS-SRTP) to the HakoSpace server instance.
3. Relay (SFU): The server acts as a Selective Forwarding Unit. Incoming media packets are forwarded to other participants who have subscribed to the stream. The server does not decode, transcode, inspect the contents of, or persist media packets. Packets reside in in-memory buffers only for the milliseconds required to forward them.
4. Playback: Receiving participants decode the stream client-side and render it for display.
5. Termination: When the broadcaster toggles off the camera/microphone/screen, the underlying media track is explicitly stopped (track.stop()), which releases the hardware and extinguishes the operating-system camera / microphone indicator. No frames captured during the session are retained by the software.

What is persisted: call metadata (who joined, when, duration) and privacy-chip signal logs for abuse-response purposes; these contain no media frames. What is not persisted: audio samples, video frames, screen-share content, or any derivative (thumbnail, still, transcript) of them.

Device-level permission: The software respects the operating system and browser permission model. Camera and microphone access require an explicit user grant (browser prompt, or OS-level TCC on macOS, or Windows Privacy Settings). Denying or revoking permission at the OS or browser level disables the corresponding feature in the software; no workaround is present in the software.

HakoSpace does not and will not introduce in-product recording capabilities within the current major release line. This commitment mirrors EULA §11.2 and reflects HakoSpace's architectural and product intent: the software exists as a relay for ephemeral communication, not as a retention platform for user media.

Operator-enabled recording, if any: A server operator may, at their own legal risk and responsibility, install or configure external recording infrastructure that captures relayed media outside the unmodified HakoSpace software. Such recording is not part of the software, requires affirmative operator configuration of third-party tooling, and obligates the operator (not HakoSpace) to comply with applicable recording-consent laws for every participant. See the EULA §11.2 for the corresponding license terms.

All of this data lives in a local SQLite database file and local file storage on the operator's machine. None of it is transmitted to HakoSpace.

4. Telemetry & Data Collection

On first launch, the server administrator is presented with a one-time prompt asking whether to participate in the HakoSpace Improvement Program. This is entirely voluntary.

• If you decline (or dismiss the prompt): zero outbound telemetry; the server does not connect to HakoSpace for the Improvement Program (other outbound connections are described below).
• If you opt in: the server periodically sends anonymized usage statistics and a randomly-generated Instance ID to HakoSpace. You may opt out at any time from the server settings panel.

What is collected (opt-in only)

All collected data is numeric or categorical. No information that directly identifies a person (such as usernames, email addresses or IP addresses) is transmitted. The above describes only the Improvement Program (telemetry).

Boundary between telemetry and the directory. "Hostnames or domain names" in the NOT Collected column of the table refers to the Improvement Program: telemetry neither collects nor transmits your hostname or domain name. hakoHub (Section 4A) is a separate feature that must be turned on separately; once it is, HakoSpace obtains the server address (a domain name) you list. The telemetry Instance ID is not linked to directory data.

Random Instance ID: The software generates a random UUID (e.g., 123e4567-...) at first start to uniquely identify the installation and keeps it in your own database; it is sent only while telemetry is enabled or when an administrator presses “Request deletion” (see “Data Retention and Deletion” below), and not otherwise. This is used strictly to deduplicate metrics (e.g., counting active servers) and track version adoption over time. This ID is mathematically random, contains no hardware signatures, and is not linked to your identity, IP address, or domain name.

Network Logs: The HakoSpace development team does not collect end-user IP addresses from your server (the software, running on the operator's own server, records some IP addresses there, including that of the person performing an administrative action in the audit log, in the server log, in the IP ban list and in consent records, see Section 3 and Appendix A.2; these records stay on the operator's server and are not sent to HakoSpace). However, when your server instance or desktop application communicates with our infrastructure (for opt-in telemetry, license verification, or checking for and downloading software updates), our CDN provider, Cloudflare, processes the public IP address of your server or device in transit for security, DDoS protection, rate-limiting, and content-delivery purposes; HakoSpace's own services have no logging enabled that would retain IP addresses, and we do not correlate these IP addresses with personal identity. There are also connections in the opposite direction: once hakoHub is turned on, HakoSpace's directory service connects to your server periodically, and when anyone submits your server's address for registration with an Official Account, there is one verification connection (Section 4A). Your server will see these connections.

Other outbound connections

1. ACME / Let's Encrypt — to obtain TLS certificates, if the operator enables this feature
2. AI provider APIs (Anthropic, OpenAI, Google, OpenRouter, etc.) — AI conversations connect only if the operator enables AI features and supplies their own API keys. In addition, an administrator fetching the model list or pressing "Test" in the server settings also causes connections: when OpenRouter is selected, opening the "Overview" tab of the settings connects to openrouter.ai to fetch the model list (even with no key supplied and AI features not enabled); for the other providers, once a key has been saved, a connection to fetch the model list or to test may occur even while AI features are off. These connections go directly from your server to the AI provider; HakoSpace is not in the middle.
3. License verification (commercial editions only; not yet offered) — periodic key validation with the HakoSpace license server. This transmits only the license key itself and a hashed, anonymous instance ID to prevent license abuse. No user data, metadata, or PII is transmitted during this process.
4. Desktop application update checks — When automatic updates are enabled (the default; they can be turned off in the desktop settings), the desktop application connects to HakoSpace's software release source at startup and periodically while running, to look up and download new versions published by HakoSpace; the same applies when you check for updates manually; and after you press "Update now" manually, the application still connects once at the next launch to check, even if automatic updates are turned off. The release source is dl.hakospace.com (operated by HakoSpace using Cloudflare's storage and delivery services); when it is unavailable, the application connects to GitHub (api.github.com and its file download addresses) instead. These connections carry no information about your account, your messages, or the servers you connect to; standard connection information such as the IP address is handled as described under "Network Logs" above, and, for connections to GitHub, by GitHub under its own privacy statement.
5. Server update checks — Only when a server administrator manually checks for or downloads a software update in the server settings does the server connect to the same software release source (dl.hakospace.com, or GitHub when it is unavailable) to look up and download new versions published by HakoSpace. These requests carry only standard connection information and the server's software version, and no user data; the server's IP address is handled as described under "Network Logs" above, and, for connections to GitHub, by GitHub under its own privacy statement. Servers deployed from the official Docker image do not use this feature.

Data Retention and Deletion: HakoSpace keeps one record for each server that has opted in: the statistics listed in the table above (overwritten with the latest values on each report), the instance identifier, the first and last report times and the report count. It contains no IP address or geolocation and is stored in Cloudflare D1 (Asia-Pacific region). The record is kept until you delete it: you can opt out at any time to stop sending, and you can press “Request deletion” in the Improvement Program section of the server settings, which sends HakoSpace a deletion request carrying only the instance identifier; we then delete that record. Deleted data remains in the backups of Cloudflare D1's point-in-time recovery for at most 30 more days and then disappears. If the Improvement Program is still on, the next report creates a new record. Aggregate statistics are computed from the existing records at the time they are viewed, so a deleted record is no longer counted; aggregate figures taken before the deletion cannot be traced back to individual servers and are not changed. hakoHub data, by contrast, can be withdrawn and deleted; for retention see Section 4A.

4A. Public Server Directory (hakoHub)

hakoHub is a public directory of HakoSpace servers operated by HakoSpace (hub.hakospace.com). It is opt-in: off by default and independent of the Improvement Program in Section 4.

4A.1 Who can turn it on, and how

Only a server administrator with the manage_system permission can, on the "Make my server public" page in hakoApp, turn hakoHub on, generate a hub key, write the directory description, and switch the two count statistics on or off individually. To be listed in the directory, the administrator (or someone they have authorized) must also register the server with a HakoSpace Official Account at auth.hakospace.com/hub and agree to the Official Account Terms of Service and the hakoHub Listing Policy. The administrator can at any time disable publishing, regenerate the key (the old Listing is withdrawn once HakoSpace's probe confirms it), or withdraw the Listing in the Official Account.

4A.2 What HakoSpace reads

Once turned on and listed, HakoSpace reads: the server address, name, directory description, icon URL (only the URL is read and no image is stored; visitors' browsers load the image directly from your server; when review staff view a Listing on the review page (both the approved icon and a pending new icon), HakoSpace downloads the icon from your server solely to show it on the review page and does not store the image), how to join (registration mode), a member-count range and an online-count range (each read only if you choose to publish it), the hakoApp version and the protocol version (always read, never shown publicly), and the host name your server reports having received (for review staff reference only, not shown publicly). Counts are provided only as ranges (0, 1–4, 5–19, 20–99, 100+): member counts exclude bots, banned accounts and unverified accounts, and online counts exclude invisible users and AI bots; the member count is published by default and the online count is off by default.

HakoSpace does not read messages, files, channels, member lists or members' personal data, and does not obtain exact counts.

4A.3 How it is read

The direction is from HakoSpace to your server; hakoApp does not connect to HakoSpace on its own to notify or upload directory information. HakoSpace's directory service periodically (currently about every 30 minutes; about once a day for hidden Listings) sends a request to your server's hub endpoint, looking up the domain's DNS before each connection. The request carries your registered address, a timestamp, a random value, the Listing's current directory status (pending, listed, or hidden, with a reason category) and a signature computed with the hub key, and hakoApp records that status and shows it on its admin page; the request and the normal response are both signed with the hub key, and the probe carries only signatures, never the key itself (when you register or change the address, you submit the hub key once to the Official Account service over an encrypted connection). A full probe is made at the moment of registration, and at registration and when the icon changes, a header-only request checks the icon's type and size; a request with an incorrect signature gets no name, description, count or other directory information (it only learns that the endpoint is "not enabled" or "authentication required", or receives the public fingerprint of your hub key). Your server will see these connections and may record them in its own logs. An administrator can switch the endpoint off entirely with the environment variable HAKO_HUB=off.

4A.4 How HakoSpace handles it, and for how long

HakoSpace stores the data it reads, the address and tags you submit, the hub key's public fingerprint and an encrypted probe key derived from the hub key (the hub key itself is not kept), probe status, the registrant's Official Account identifier and consent record, and review and notification records, and shows approved directory information publicly. This data belongs to the HakoSpace Official Account service; how it is handled and how long it is kept (including a 90-day tombstone after withdrawal, and the block list) are set out in Sections 9 and 11 of the HakoSpace Official Account Privacy Policy, and your rights and how to exercise them in its Section 12, not in the rest of this Policy. For withdrawal, see 4A.1.

4A.5 Review and take-down

A first Listing and changes to the name, description, icon, tags and server address are subject to HakoSpace review; under the hakoHub Listing Policy, HakoSpace may hide or take down a Listing and, for serious or repeated breaches, block a domain name or hub key fingerprint. Review covers only the data shown in the directory, not the server itself or the content on it (EULA §11.7).

4A.6 Your users

The directory publishes server-level information and count ranges, and no data about any individual user. We recommend (but do not require) that operators tell the users of their server before making it public in the directory; hakoApp's "Make my server public" page will carry the same reminder.

5. Server Operator Responsibility

If you run a HakoSpace instance, you are the data controller for all user data on that instance.

• You are responsible for your own data protection obligations under applicable law
• You should inform your users about what data you collect and how you handle it
• You are responsible for backups, security, and access controls on your server
• HakoSpace provides the software; compliance is your responsibility
• Where your instance is likely to be used by minors, you must assess your obligations under child-privacy laws applicable to your users' jurisdictions (e.g., COPPA in the United States, GDPR Article 8 in the European Union, PIPL Article 31 in the People's Republic of China, the Personal Data Protection Act in Taiwan). HakoSpace provides the software; legal-age determination and parental-consent mechanisms, where required, are your responsibility as operator.
• The software displays, on first camera activation by any user, a one-time in-app notice disclosing (a) that a live camera stream will be transmitted to other participants, (b) that the stream is not recorded by the unmodified software, and (c) that the user remains responsible for the content they broadcast. This notice is intended to reduce surprise; it is not, by itself, sufficient to constitute verifiable parental consent where such consent is legally required.

5.5 Minor Users

The software is general-purpose communication infrastructure and is not specifically directed to children. Nevertheless, because individual server instances may be used by users of any age, each operator must assess obligations under applicable child-privacy laws (COPPA in the US, GDPR Article 8 in the EU, PIPL Article 31 in PRC, Personal Data Protection Act in Taiwan, etc.) for their user population.

By accepting this Privacy Policy, you represent that you are at or above the age of digital consent in your jurisdiction (commonly 13–16), or that a parent or legal guardian with lawful authority has reviewed and accepted on your behalf. Server operators whose instances are used by minors in jurisdictions requiring verifiable parental consent must implement additional operator-level controls (e.g., age gating at registration, operator-initiated parental consent workflow); the software does not substitute for these.

If you are a parent or guardian and believe a minor under your care has accepted this Privacy Policy without your authorisation, please contact the server operator to request deletion of the minor's account data under §7.

Protection against recording: As stated in §3.1 and EULA §11.2, HakoSpace does not and will not introduce in-product recording capabilities within the current major release line. This reduces the privacy exposure surface for all users, and is particularly relevant for minor users whose transmitted likeness must not be retained by the platform.

A. Legal Consent Enforcement

HakoSpace uses a server-side legal consent gate to ensure that every user of a HakoSpace server instance has actively accepted the "most recent version requiring consent" of the EULA and this Privacy Policy, or any later version (see A.1 and A.3), before using any feature that processes personal data.

A.1 Versioning

Each of the EULA and this Privacy Policy is identified by an independent effective date in ISO format (YYYY-MM-DD), displayed in the document header (e.g., Privacy Policy effective 2026-10-16). Any of the following is a material change: expansion of collected data categories, change of retention period, introduction of new third-party processors, new feature categories (noting that, per §3.1 and EULA §11.2, HakoSpace commits not to introduce in-product recording within the current major release line), or any other change that would, in HakoSpace's good-faith assessment, affect a reasonable user's decision to use the service.

Any change to the wording, including editorial changes (typo fixes, phrasing cleanup, link corrections, clarifications that do not change the meaning), is never applied in place to a published version; it is published as a new version (a new effective date, or, if another version must be issued on the same day, a suffix, e.g., 2026-09-26-a), and the earlier version stays unchanged. New versions are of two kinds: a material-change version (any of the situations in the previous paragraph) requires re-consent; an editorial version (editorial changes) does not require re-consent. The software records the "current version" and the "most recent version requiring consent" separately, and only the latter is used by the consent gate (see A.3).

A.2 Account-Level Acceptance Record

Your account on a given server instance stores four values: the EULA version you last accepted, the Privacy Policy version you last accepted, and the UTC timestamps of each acceptance. These values constitute personal data and are processed solely for the purpose of operating the consent gate and providing evidence of your acceptance. In addition, each time you accept, the server stores a separate consent record of the versions and time, your IP address, User-Agent, the source label sent by the client and the server version, kept permanently as evidence of acceptance.

A.3 Server-Side Gate

At each session start (HTTP API request or WebSocket HELLO), the server compares your recorded acceptance versions against the "most recent version requiring consent". You are treated as having consented if the version you accepted is not earlier than that version (and not later than the current version), so an editorial version does not stop you. If your recorded version of either document is earlier than the most recent version requiring consent, later than the current version (for example, after the server is rolled back), malformed, or empty, the server refuses the request with an error (LEGAL_CONSENT_REQUIRED) and returns the list of documents requiring re-acceptance together with the current version strings.

The client, upon receiving this error, must display a blocking modal containing the full text of each document requiring re-acceptance. The modal has no dismissal path other than accepting or leaving the service. Each document requiring re-acceptance has its own checkbox ("I have read and agree to the EULA" / "I have read and agree to the Privacy Policy"), which can be checked only after that document has been scrolled to the bottom in its full-text viewer; the Accept button is enabled once every document requiring re-acceptance this time has been checked; a document that does not require re-acceptance is not shown and need not be checked. Upon acceptance, the client POSTs the accepted version strings to the server, which updates only the version and time fields of the document(s) requiring re-acceptance (the record of the other document is left unchanged) and grants access.

A.4 Applies to All Users, Not Only New Ones

On the release day that introduces a new material-change EULA or Privacy Policy version, all existing users (not only newly-registered ones) will see their next connection intercepted by the re-consent modal. This design reflects that (i) a material change in collected data categories or processing purposes affects existing users equally, and (ii) GDPR and equivalent frameworks require affirmative, informed consent for the new purpose — passive continuation of use does not constitute such consent.

Server operators migrating to a new version therefore must expect temporary access friction for their users on release day; this is a feature of the consent framework, not a bug.

A.5 Decline Consequences

If you decline the new version, you will be unable to use that server instance until you accept. Your existing account data is not deleted by the decline; you may return and accept at any later time. You retain the right to request deletion of your personal data under §7 / §8 below, independently of the consent decision.

A.6 Historical Versions

Each published version of this Privacy Policy and the EULA remains accessible at a stable archive URL (typically /legal/archive/<YYYY-MM-DD>/privacy and /legal/archive/<YYYY-MM-DD>/eula), so that you may always review the exact text you accepted.

6. Desktop Application

The HakoSpace desktop application (Electron) connects only to server addresses you configure and, when checking for and downloading software updates, to HakoSpace's software release source (dl.hakospace.com, or GitHub when it is unavailable; see "Other outbound connections" in §4).

• Sign-in tokens (including refresh tokens): the desktop application keeps them in the encrypted storage provided by the operating system; if the operating system cannot provide encryption, the tokens are not saved and you must sign in again at the next start. The web version (used in a browser) still has its tokens kept by the browser. Earlier versions stored sign-in tokens unencrypted in the application's browser-storage files: the first time you open each server after upgrading, its old tokens are moved into the encrypted store and deleted from those files, though old copies may remain on disk until the files are overwritten; the old refresh token stops working at its first renewal, and the access token at its own expiry (60 minutes by default). For a server not opened again after the upgrade, the old tokens stay where they were, unencrypted, until their original expiry.
• No user data is sent to HakoSpace (update checks and downloads reach HakoSpace's software release source and carry only standard connection information, as described above)
• The app itself has no built-in telemetry or crash reporting (for operating-system components, see below)
• Local cache: To display content, the desktop application may cache received images, avatars, and stickers in the application data directory on your device. The game HUD feature uses a dedicated cache directory whose contents are deleted when the voice session ends and whenever the application starts or exits. Cached content is used only for local display and is not transmitted to any server.
• Game HUD (foreground window information): When the game HUD is enabled, the desktop application reads the title, process identifier, executable path, window identifier, on-screen position and size of the current foreground window, and the display it is on together with that display's scaling factor, solely to decide whether to show the HUD over that program and where to place it, to maintain the "disabled list" you configure (stored as executable paths in your local desktop settings until you remove them), and, when you choose "Share this game" from the HUD panel, to identify the window to be shared (the shared content itself is handled as described in Section 3.1 of this policy on screen sharing). This information is processed only on your device; it is not transmitted to HakoSpace or to the server you are connected to.
• Keyboard events: To provide global shortcuts and push-to-talk, the desktop application receives keyboard events at the system level in order to match the key combinations you configure; this listening does not intercept or alter the keys that other applications receive. The game HUD itself does not listen to keyboard events at the system level; it only receives the shortcuts you configure for the HUD, through the operating system's hotkey registration (when you press such a key combination, it is received by the HUD). While the HUD panel is open, the panel becomes the foreground window and receives your keyboard input, just as any other window does when you switch to it; some programs may still detect keystrokes by other means, such as reading the keyboard state directly, which is beyond this software's control. The desktop application does not keep a record of your keystrokes and does not transmit keystroke data to any server; messages you deliberately send from the HUD input box are transmitted to the server you are connected to, the same as messages sent within the application.
• Operating-system components: The game HUD is rendered by the Microsoft Edge WebView2 Runtime built into Windows. That component is part of the operating system; collection of its diagnostic data is governed by Microsoft's privacy statement and the Windows "Diagnostics & feedback" setting, and is not collected or transmitted by this software.

7. Contact

For questions about this policy: legal@hakospace.com

For questions about data on a specific HakoSpace instance, contact the operator of that instance.

For data that HakoSpace itself holds, namely the per-server Improvement Program record (Section 4), hakoHub directory data (Section 4A, handled under the HakoSpace Official Account Privacy Policy) and email you send us (Section 8), you may, under Taiwan's Personal Data Protection Act, request access or review, a copy, supplementation or correction, cessation of collection, processing or use, and deletion. Write to legal@hakospace.com and we will act within the periods of Article 13 of that Act: for access, review or a copy, we decide within 15 days of receiving the request, extendable by 15 days where necessary; for supplementation or correction, cessation of collection, processing or use, or deletion, we act within 30 days, extendable by 30 days where necessary; where we need an extension, we will tell you the reason in writing. An Improvement Program record can only be matched by its instance identifier, so please include the Instance ID shown in the server settings, or simply use “Request deletion” there.

8. Website and Communications

When you visit hakospace.com to download our software or read documentation, the site is served by Cloudflare as static files. HakoSpace keeps no web server logs, and the site sets no cookies and uses no analytics or tracking scripts. As a reverse proxy, Cloudflare processes connection information (such as your IP address) in transit under its own privacy policy; the traffic and security statistics in its dashboard are kept by Cloudflare, and HakoSpace does not export or keep them. The home page and the download page have your browser fetch the list of versions from HakoSpace's software distribution source (dl.hakospace.com), or from GitHub when that is unavailable; the list is stored in your browser's localStorage (reused for 10 minutes, then fetched again and overwritten) and stays on your device. If you contact us via email (e.g., support requests), we will retain your email address and the content of your message solely for the purpose of resolving your inquiry, for 365 days after the matter is closed, after which it is deleted (where the law requires a longer period, that period applies). We do not sell or share this information with third parties.

The hakoHub directory pages (hub.hakospace.com). Browsing the directory does not require an account. What the directory pages do with visitors' data (server icons are loaded by the visitor's browser directly from each server, each server sees the visitor's IP address, the pages set no cookies and use no analytics scripts, and HakoSpace does not separately record visitors' IP addresses) is set out in the hakoHub Directory Privacy Notice (linked in the directory's footer). Clicking a server in the directory takes you to a website run by a third party, to which its own policies apply. For the directory's content and data handling, see Section 4A.

The HakoSpace Official Account website used to list on hakoHub (auth.hakospace.com) is governed by the HakoSpace Official Account Privacy Policy, not by this section.

9. Language Versions

This Privacy Policy is published in English and Traditional Chinese. In the event of any discrepancy or inconsistency between the English version and the Traditional Chinese version of this Policy, the Traditional Chinese version shall prevail.