Privacy Policy — OasisGUI, OasisNet and oasisgui.com
Draft prepared for review by counsel on 2026-10-06. This is a first draft produced for attorney review and is not legal advice. Every statement about what the software does was checked against the repository on that date (commit e6ee7b24 plus uncommitted website edits; shipped version 2.0.0). Section 5.7 (the enterprise documentation portal) was re-verified on the same day against the portal's source, delivered in the same change set (portal/src/db.ts schema, auth.ts cookie and session handling, routes/auth.ts, routes/account.ts and routes/admin.ts audit and counter calls, views/admin.ts administrator pages, views/pages.ts account page, config.ts lifetimes); what remains open in that section are decisions, not facts, and it must still be checked against the live Set-Cookie header once deployed. Points that need a decision by the company or its counsel are marked [DECISION: …] or [COUNSEL: …] and collected in Section 20.
Effective date: [DECISION: effective date — after counsel sign-off and resolution of Section 20]
Related documents: Terms of Service · End User License Agreement · Cookie and Local Storage Statement · Sub-processor List · Data Processing Addendum · Third-Party Notices · Vulnerability Disclosure Policy · Index
1. Who we are and what this policy covers#
1.1 This Privacy Policy explains how Varrock Inc. ("Varrock", "we", "us") handles personal data when you visit oasisgui.com (including the public pages, the embedded live demo and the enterprise documentation portal at /docs/, for which you create an account — Section 5.7), download or update OasisGUI, or use OasisGUI, OasisNet or the Oasis Mobile companion app (together, the "Software"). [DECISION: Oasis Mobile is not on the App Store at 2.0.0 and is supplied only by direct install or TestFlight on request — confirm whether this policy should cover it now, and note that Apple's TestFlight terms apply to testers.]
1.2 Varrock Inc. is a corporation organized under the laws of the State of Delaware, United States (Delaware file number 10482601). For the purposes of the EU and UK General Data Protection Regulation ("GDPR"), Varrock is the controller of the personal data described in Section 5. For the push gateway in Section 6, Varrock acts as a processor for an organization that enables mobile notifications for its users (see the Data Processing Addendum) and as a controller only where an individual uses the gateway for their own devices. [COUNSEL: confirm the controller/processor split for the push gateway, including whether an individual user's own runner-to-gateway traffic is household use under Article 2(2)(c).] [COUNSEL: whether Article 3(2) GDPR / UK GDPR applies to Varrock at all (English-only site, no EU pricing or language); this draft is written as if it does, which is the conservative choice but should be a deliberate one, consistent with Terms of Service §18.3.]
1.3 Postal address of the controller: [DECISION: controller postal address — the only address on record is the registered agent's (LegalInc Corporate Services Inc., 131 Continental Drive, Suite 305, Newark, DE 19713, USA), a service-of-process address, not a correspondence address for privacy requests].
1.4 This policy does not cover personal data that the Software processes on computers, servers, virtual machines and networks that you or your organization operate; such data never reaches Varrock (Section 7). An organization that deploys OasisNet is the controller of the data flowing through its own coordinators and relays.
2. Short version#
- No telemetry, no analytics, no crash reporting, no advertising identifiers. None exist in the Software or on the website. The Software has no accounts. The website has exactly one account system: the enterprise documentation portal at
oasisgui.com/docs/, which you use only if you ask for access to the enterprise documentation (Section 5.7). It stores your email address, name, a password hash, the times your account was created and last signed in, your company's name and web domain, the approval status of your company and of your membership in it, notes written by the approving administrator, your sign-in sessions with the IP address each was opened from, an audit log with IP addresses, and per-IP-address counters of failed or rejected requests. - By default, the desktop app contacts Varrock-operated infrastructure for exactly one purpose: checking
https://oasisgui.com/downloads/latest.jsonfor a new version. That request carries your IP address, the time and the fixed headerUser-Agent: tauri-plugin-updater/2.10.1— not your app version, operating system, machine identifier or any account. - The public website sets no cookies. It stores one preference key (
oasis-site-theme) in your browser only if you pick a theme. The documentation portal sets one strictly necessary cookie (oasis_portal_session): an anonymous, browser-session value when you open its sign-in or sign-up page (it carries the form's anti-forgery token; nothing about it is stored on our side), replaced by a sign-in token that lasts up to 30 days when you sign in — and nothing else (Section 5.7 and the Cookie and Local Storage Statement). - Web-server access logs may exist for page views and downloads; we do not claim otherwise (Sections 5 and 11).
- One optional action also reaches a Varrock host. Creating a virtual machine from the built-in "inference" NixOS template downloads the OasisNet binary from
https://start.oasis.cookingduring the image build on your own host (your host's IP address, the time and the fetch tool's user agent; nothing else — Section 5.5). - One third-party lookup is on by default. Whenever the Mesh view or the hover card over a server in the sidebar is shown, the desktop app sends the mesh peers' public endpoint IP addresses to
api.country.isto draw a country flag — including the addresses of other people's connections. It cannot currently be switched off (Section 8.2). [DECISION: as in 8.2 — add an off switch, remove, or keep and disclose.] - Everything else stays on machines you control, or goes to third-party services only when you enable a feature or enter your own credentials (Section 8.3).
3. Definitions#
"Personal data" has the meaning in Article 4(1) GDPR; "personal information" is used in Section 15 with its CCPA meaning. "Desktop app" means the OasisGUI application for macOS, Linux and Windows. "Mesh" means an OasisNet WireGuard network — nodes, coordinators and optional relays — run by the organization that created it. "Runner" means the oasis-runner daemon on each managed host. "Update manifest" means https://oasisgui.com/downloads/latest.json. "Website" means everything served under https://oasisgui.com, including /docs/, /downloads/ and /demo/. "Portal" means the account-gated part of the website that serves the enterprise documentation: the pages under /docs/ and the /signup, /login, /logout, /account and /admin routes (Section 5.7). "Tenant" means the company record a Portal user creates or joins, which an administrator approves before that company's users can read the documentation.
4. Scope of collection#
Sections 5 and 6 describe every path we have found by which data about you can reach infrastructure Varrock operates: page views (including the live demo, a same-origin frame running a fake fleet that makes no further requests), downloads, the update check, the account you create on the Portal to read the enterprise documentation (Section 5.7), the one-time download of the oasisnet binary from https://start.oasis.cooking when you build a NixOS virtual-machine image from the bundled "inference" template (Section 5.5), email to sales@oasisgui.com, the reports you choose to send us about misuse, security vulnerabilities and intellectual-property rights (Section 5.6), and — if ever enabled — mobile push. Choosing a website theme writes a value to your own browser and sends nothing.
5. What we collect, why, and on what legal basis#
5.1 Website visits — server access logs#
What. When you load a page, the web server can record your IP address, your browser's user agent string, the page or file requested, the referring URL if your browser sends one, and the time. The website is served by an nginx web server inside a container, which uses nginx's default access log for pages and assets; a host-level web server terminates TLS in front of it. Requests to the Portal (Section 5.7) pass through the same host-level web server, which forwards your IP address to the Portal so that it can rate-limit sign-in attempts and write its audit log; the Portal keeps those records in its own database, described in Section 5.7, not in a web-server log. [DECISION: confirm whether the host-level ("front") web server keeps access logs for oasisgui.com, in what format and for how long; the container configuration is in the repository, the host-level one is not.]
What the website does not do. It includes no analytics script, advertising pixel, third-party font, script or iframe. The only outbound links are to our profile on x.com and to mailto:sales@oasisgui.com. [DECISION: confirm the published site uses system fonts only — the committed version loaded Google Fonts; the working tree does not.]
Why and legal basis. To deliver the pages you request, keep the website secure and available, and diagnose faults. Article 6(1)(f) GDPR — our legitimate interest in operating a secure, reliable website. The data is limited to what any web server receives, is not combined with other data or used for profiling, and is kept only for the period in Section 11, so we consider that your interests do not override ours. [COUNSEL: confirm the legitimate-interest assessment once the retention period in Section 11 is set, and whether a written LIA should be kept on file.]
5.2 Downloads#
What. Installers (.dmg, .AppImage, .deb, .exe), signature files and the update manifest are served from https://oasisgui.com/downloads/. The container-level web server has access_log off for these file types, so at that layer a download is not logged; the host-level web server may log it. [DECISION: as in 5.1.]
Why and legal basis. To deliver the file you asked for and protect the download service. Article 6(1)(f) — our legitimate interest in delivering the file you requested and protecting the download service; and, where you download for your own use, Article 6(1)(b) — steps at your request before entering into the End User License Agreement under which the Software is supplied. [COUNSEL: most downloads of an administration tool are made by an employee for an employer that will be the licensee, so 6(1)(f) is led with; confirm.]
5.3 Desktop app update check#
What. The desktop app checks for a newer version by sending an HTTPS GET for the update manifest. We examined the updater library the app uses (tauri-plugin-updater 2.10.1) and the app's configuration. The request carries your public IP address and the time (inherent to any network request), the headers Accept: application/json and User-Agent: tauri-plugin-updater/2.10.1 (the fixed name and version of the library), plus the ordinary protocol headers any HTTPS client sends — and no other application data or identifier: no app version, operating system, CPU architecture, hostname, machine identifier, license key or account; the app picks the right download for its platform locally. If you accept an update, a second request downloads the installer (5.2). Updates are never installed silently.
When. At launch and, by default, every 10 minutes while the app runs. You can turn the periodic check off in the app; the launch check and a manual "Check for updates" still run. Installations managed by Nix skip the check. [DECISION: whether to add an administrator-level switch that also disables the launch check; none exists today.] The container-level web server does not log manifest requests. [DECISION: host-level logging, as in 5.1.]
Why and legal basis. To tell you that a security or feature update exists. Article 6(1)(f) — our legitimate interest, and yours, in keeping installed Software current and secure. [COUNSEL: confirm 6(1)(f) rather than 6(1)(b), given that the check is on by default and the EULA governs the supply of updates.]
5.4 Correspondence with us#
What. If you email sales@oasisgui.com (the only mailbox published on the website), we receive your email address, name and whatever you write, and we keep the thread. [DECISION: name the email provider hosting the mailbox — it is a recipient and belongs in the Sub-processor List.]
Why and legal basis. To answer you, to discuss and conclude a business license, and to keep a record of what was agreed. Article 6(1)(b) — steps at your request before a contract; Article 6(1)(f) — our legitimate interest in handling enquiries and keeping business records; Article 6(1)(c) where a legal obligation requires retention.
5.5 VM template builds — download of the OasisNet binary#
What. The desktop app bundles NixOS virtual-machine templates. When you create a VM from the bundled "inference" template, the image build — which runs on your own host — fetches a pinned, hash-checked copy of the oasisnet binary from https://start.oasis.cooking/oasisnet, a host Varrock operates. The request carries the building machine's public IP address, the time and the fetch tool's user agent; no account, machine identifier or template contents. Nothing is sent if you do not use that template. [DECISION: host-level access-log policy for start.oasis.cooking, as in 5.1; or serve the binary from oasisgui.com/downloads/ so one log policy covers it.]
Why and legal basis. To supply the component the template needs. Article 6(1)(f) — our and your legitimate interest in delivering that component on request; and, where you build the image for your own use, Article 6(1)(b) — performance of the End User License Agreement.
5.6 Reports you send us — misuse, security vulnerabilities and rights complaints#
What. If you report misuse of the Software, a mesh or a service we operate under the Acceptable Use Policy (its section 12), report a security vulnerability under the Vulnerability Disclosure Policy (its section 4), or send a copyright, trademark or open-source licence complaint under the Trademark and Copyright Notice (its sections 9 and 10), we receive your name or handle, your email address, any OpenPGP key you use, and the contents of your report. For a misuse report that is the date and time, the public IP address or domain involved and the logs or headers you include, which may identify a third party; for a security report, the technical details and any proof of concept; for a rights complaint, the statements and signature that 17 U.S.C. § 512(c)(3) or section 10.1 of that notice call for. Until dedicated mailboxes exist these reports arrive at sales@oasisgui.com. [DECISION: abuse, security and rights mailboxes — only sales@oasisgui.com exists today; the Acceptable Use Policy, the Vulnerability Disclosure Policy and the Trademark and Copyright Notice carry the same marker.]
Why and legal basis. To assess and act on the report: to stop or prevent misuse, to reproduce and fix a vulnerability and to ship and describe the fix, to handle a rights complaint, to communicate with you, and to keep a record of what was reported and what we did. Article 6(1)(f) GDPR — our legitimate interest, shared by users of the Software and the public, in secure software, in lawful use of the services we operate and in respect for intellectual-property rights. Article 6(1)(c) where a law obliges us to notify an authority or users: once Regulation (EU) 2024/2847 (the Cyber Resilience Act) applies to us, its Article 14 requires us to report an actively exploited vulnerability or a severe incident through the ENISA single reporting platform to the coordinating CSIRT and to inform affected users (Vulnerability Disclosure Policy, section 5.6). [COUNSEL: whether Article 14 of the Cyber Resilience Act binds Varrock now, as the Vulnerability Disclosure Policy (section 5.6) and the EU product-compliance memo (section 4.5) ask, and whether the authority notification rests on Article 6(1)(c) or 6(1)(f) until it does; confirm 6(1)(f) for the onward disclosure of misuse reports to third-party operators, providers and authorities.] Personal data of other people that reaches us in a proof of concept is used only to assess the issue and is deleted once the fix ships.
Recipients. In addition to Section 9.1: for a misuse report, where we decide to act under section 13.2(d) of the Acceptable Use Policy, the operator of the host or network concerned, its hosting provider, the third-party provider whose terms were circumvented, and law-enforcement authorities; for a security report, the upstream project when the defect is in third-party code we ship (Vulnerability Disclosure Policy, section 3.2), the coordinating CSIRT through the ENISA platform where Article 14 of the Cyber Resilience Act applies (its section 5.6), and the readers of a published advisory or of the credits page — which name you only by the name or handle you choose, and only if you choose to be credited (its section 6.5; tell us at any time if you want a credit removed, Section 18); for a rights complaint, our professional advisers and, where the complaint concerns a third-party component, that component's maintainers. [COUNSEL: whether publishing a chosen credit rests on the reporter's own request under Article 6(1)(f) or on consent under 6(1)(a), and the withdrawal mechanics in either case.]
Address blocklist. If we refuse to serve the website, downloads or the update manifest to a network address or range under section 13.2(b) of the Acceptable Use Policy, we keep that address, the date and the reason for as long as the refusal stands. No such list is maintained at the date of this draft; the web-server configuration in the repository contains no deny rules. [DECISION: retention and review period for any address blocklist, should one be created.]
Retention. Security reports and the log we keep of them (Vulnerability Disclosure Policy, section 10.2) for the support period of the product concerned [DECISION: the support period itself is undecided — Vulnerability Disclosure Policy section 8.4 — and fixes this retention period]; misuse reports and rights complaints for [DECISION: retention period for misuse reports and rights complaints, for example three years after the matter is closed, longer where a legal claim requires]; see Section 11.
5.7 Enterprise documentation portal — your account, your company and our approval#
What the Portal is. The enterprise documentation under oasisgui.com/docs/ is not public. To read it you create an account on the Portal, create (or join) a Tenant for your company, and wait for a Varrock administrator to approve that Tenant by hand. The public landing page at /docs/ shows only the titles of the documents and the sign-in and request-access buttons; it needs no account and sets no cookie. The rest of the website — the home page, downloads, the demo and /legal/ — remains public and does not use the Portal. (Every statement in this section was verified against portal/src/ on 2026-10-06; Section 20, 22e.)
What we collect.
| Data | Where it comes from | What it is used for |
|---|---|---|
| Account: email address, display name, password, the time the account was created and the time of its last sign-in | You, when you sign up; the two times are set by the Portal. The password is stored only as an Argon2id hash; we cannot read it and never log it. | Identifying you, letting you sign in, and letting the approving administrator judge whether you work for the company you name. |
Tenant: company name, company web domain, an optional message to us, the Tenant's status (pending, approved or rejected), the date, and the note or reason an administrator wrote when approving or rejecting |
You (or the colleague who created the Tenant), and the administrator who decides. | Deciding whether your company is an enterprise customer entitled to the documentation, and telling you the outcome on your account page. |
Membership: which account owns or belongs to which Tenant, whether that membership is confirmed (pending or active), and whether an account is a Portal administrator |
Created when you create a Tenant (you become its owner, confirmed at once) or when you enter a Tenant's join code — an eight-character code that only the Tenant's owner sees on their account page and passes to colleagues by whatever means they choose. Entering it attaches your account to the Tenant as a pending member; the owner (on their account page) or a Varrock administrator then confirms or removes you, and the owner can replace the code at any time. Until you are confirmed you see only the Tenant's name and status, and you cannot read the documentation even if the Tenant is approved. Administrator status is created only by Varrock's command-line tools (create-admin, or promote of an existing account); signing up with an administrator's address is refused. |
Granting or refusing access to /docs/ per company rather than per person, with the Tenant's owner vouching for each member. |
| Pre-sign-in cookie: an anonymous random value with its issue time, from which the anti-forgery token of the sign-in and sign-up forms is derived | Set in your browser when you open /login or /signup. Nothing is stored on our side — no record and no IP address — and it is a browser-session cookie that we stop accepting 24 hours after issue. |
Rejecting a sign-in or sign-up form that was not loaded by your own browser (anti-forgery). |
| Session: a random sign-in token, stored on our side only as a keyed hash (HMAC-SHA256 under a server-side secret), with its creation, last-use and expiry times, the IP address the session was opened from, and the per-session anti-forgery (CSRF) token | Created when you sign in or sign up; it replaces the pre-sign-in cookie. The token is sent to your browser in the oasis_portal_session cookie (strictly necessary; see the Cookie and Local Storage Statement, section 4A). |
Keeping you signed in for up to 30 days — or 7 days after your last request, whichever comes first — and rejecting requests that did not come from your browser. |
| Audit log: who did what to which record, from which IP address, when. Written for: successful sign-ins, sign-ups and sign-outs; failed sign-ins against an account that exists (one line per account and 15-minute window — an address that has no account is never written to the audit log); company registration, join-code entry, join-code replacement, member confirmation and removal; a form rejected for a missing or stale anti-forgery token while signed in; and every administrator and command-line action (approve, reject, confirm or remove a member, create or promote an administrator, set a password, delete). Each line names the acting account by email address, the action, the record acted on, the IP address and the time. | The Portal itself. | Security: detecting account misuse, reconstructing who approved which company and who confirmed which member, and investigating a complaint. Kept 180 days and at most 200 000 lines (Section 11). |
| Security counters: for each kind of failed or rejected request (a rejected anti-forgery token, a failed or rate-limited sign-in or sign-up, a sign-up with a reserved administrator address, a wrong join code), the IP address, a 15-minute window and a count | The Portal itself, on each such request, whether or not you have an account. No text you entered is stored with them. | Security: showing administrators the pattern of attempts without keeping one line per attempt. Kept 7 days. |
| Rate-limit records: the IP address and the email address used in sign-in and sign-up attempts, with a counter and a time window (ten attempts per fifteen minutes) | The Portal itself, on every attempt — including attempts with an email address that has no account. The front web server additionally limits each address to ten requests per second on the Portal's pages. | Security: slowing down password guessing and bulk sign-ups. Deleted when the window ends (Section 11). |
| Web-server access logs for Portal requests | The same host-level web server as every other page (Section 5.1). | As in Section 5.1. |
What we do not do. We do not verify your email address (no message is sent to it) and we send no email from the Portal at all in its first version — not on sign-up, not on approval, not for a forgotten password. The administrator's manual review replaces email verification: an administrator sees the name, email address, company name, company domain and message you entered and decides from those whether to approve. Because the address is unverified, do not enter an address that is not yours, and expect that we may contact you at sales@oasisgui.com to confirm it before approving. There is no password reset in the Portal; if you lose your password, ask us (Section 18) and an administrator sets a new one by a command-line tool, after confirming with you by other means. [DECISION: how an administrator confirms identity before resetting a password or deleting an account, given that email addresses are unverified — reply from the registered address, a call to the company's published number, or the Tenant owner's confirmation.] The Portal contains no analytics, advertising or third-party scripts; it loads only our own stylesheet, script and diagram renderer.
Who sees what. Portal administrators are Varrock personnel [DECISION: name the role or the people who hold administrator access, by role not by name in the published text; the list of administrators is set by an environment variable and a promote command]. On the administration pages they see every Tenant with its status, name, domain and message, and the email address and name of every account, including accounts that belong to no Tenant and accounts of rejected Tenants; they do not see passwords or session tokens. The administration page also shows the most recent 100 audit-log lines (with their IP addresses) and the security counters of the last 7 days; the rate-limit records and older audit lines are visible only with database access. Confirmed members of your Tenant see each other's names, email addresses and membership status on the account page; the owner additionally sees the join code and can confirm or remove members. A person who has entered the join code but is not yet confirmed sees only the Tenant's name and status. Nobody outside Varrock sees Portal data except the recipients in Section 9.1 (our hosting provider, and advisers or authorities where the law requires).
Why and legal basis. Account, Tenant, membership and session data: Article 6(1)(b) GDPR — taking steps at your request before entering into a contract, and performing the arrangement under which we make the enterprise documentation available to an approved company's users [COUNSEL: whether 6(1)(b) can carry the Tenant-approval processing when the person who signs up is an employee and the "contract" (the enterprise relationship) is with the employer; the alternative is 6(1)(f), our legitimate interest in giving enterprise customers and prospects access to detailed documentation while keeping it from the public, which should probably be stated alongside, as this draft does]. Audit log, rate-limit records and the administrator's review of a sign-up: Article 6(1)(f) — our legitimate interest in the security of the Portal and in disclosing enterprise documentation only to the companies it is intended for; the data is limited to what is needed to identify misuse and to decide an application, is not used for profiling or marketing, and is kept for the periods in Section 11 [COUNSEL: the legitimate-interest assessment for a security log that records the IP address of every sign-in, and for the manual review of a person's name and email address against a claimed employer; Recital 49 GDPR supports the security limb]. Password hash: Article 6(1)(b) and, as a security measure, Article 32. We make no solely automated decision about you: approval and rejection are always decided by a person (Article 22 does not apply).
Your choices. You decide whether to create an account at all; the public documentation on the home page and the /legal/ pages need none. Signing out (/logout, available on every documentation page and on your account page) invalidates your session on our side immediately. A Tenant's owner can remove members and replace the join code without asking us. You can ask us to change or delete your account and, if you are its owner, your Tenant (Section 13); [DECISION: self-service deletion (a "Delete my account" button on /account) versus deletion on request to the contact mailbox — the first version of the Portal has no self-service deletion, so this draft is written as "on request" and must change if the button is added]. Deleting an account removes the account, its sessions and its membership; the audit-log lines that name it are kept for the period in Section 11 because they also record what an administrator did [COUNSEL: whether audit-log lines that identify a deleted user by email address may be kept for the security-log period or must be pseudonymised at deletion]. Deleting a Tenant removes the Tenant record; member accounts remain unless also deleted.
Retention. See Section 11: sessions 30 days after sign-in, 7 days after the last request, or until you sign out, whichever is first (expired rows are deleted by a sweep that runs at start-up and every ten minutes); the pre-sign-in cookie is stored nowhere on our side; accounts and Tenants while the relationship lasts and then [DECISION: inactive-account retention — for example delete accounts that have not signed in for 24 months, and rejected Tenants and their lone accounts 12 months after rejection, after notice where an address is known]; audit log 180 days and at most 200 000 lines, the oldest deleted first [DECISION: confirm 180 days — the code's default, changeable by configuration; 12 months was the earlier proposal — which then becomes the longest period an IP address is kept anywhere by Varrock, against the shorter web-server-log period in Section 5.1]; security counters 7 days; rate-limit records are deleted when their window expires, by the same sweep.
5.8 Whether you must provide data#
You are never under a statutory or contractual obligation to provide personal data to us. Your IP address and request details are received automatically by any web server you connect to; if you do not want us to receive them, do not visit the website, download the Software from it, leave the update check on (Section 5.3), or build a VM from the "inference" template (Section 5.5). If you do not give us an email address and your message, we cannot answer you or discuss a business license. If you send a report under Section 5.6 without a way to reach you, we can still act on it but cannot reply to you or credit you. If you do not create a Portal account, or your company's Tenant is not approved, you cannot read the enterprise documentation under /docs/; everything else on the website stays open to you (Section 5.7). If you do not register a device for push notifications, you simply do not receive them.
6. Oasis Mobile push notifications (not currently live)#
6.1 The Oasis Mobile iOS app talks to your own machines over SSH and makes no HTTP requests of its own. It can optionally receive push notifications about agent sessions, routed through a gateway run by Varrock at https://push.oasis.cooking and on to Apple Push Notification service (APNs).
6.2 As of version 2.0.0 this feature is not operational: no APNs credential has been provisioned and the gateway rejects every request. The rest of this section describes what it would process if and when Varrock enables it. [DECISION: enable push with the Varrock-run gateway as default, ship it self-host-only, or omit this section until live.]
6.3 When live, each notification sent from one of your runners to the gateway would contain your device's APNs token; a title and body, the body being a cleaned excerpt of up to 240 characters of the terminal pane that triggered the event, which may contain whatever the agent printed; the session name; the originating hostname; and timestamps. Your device name stays on your own machines. The gateway is stateless — no database, no accounts, in-memory rate limiting — and in normal operation logs at most the last six characters of a device token. (A diagnostic dry-run mode that logs full notification requests exists for testing and is not used in service. [DECISION: confirm it is disabled on the production gateway and add that check to the deployment procedure.]) [DECISION: access-log policy of the web server in front of push.oasis.cooking.]
6.4 Legal basis. Where an organization enables notifications for its users, that organization is the controller and the gateway processing is governed by the Data Processing Addendum, with Apple Inc. as a sub-processor. Where you enable notifications for your own devices, we rely on [COUNSEL: Article 6(1)(a) consent, given by registering the phone and withdrawable by removing the registration, or Article 6(1)(b) performance of the feature you requested — choose one and confirm the withdrawal mechanics]. [COUNSEL: Apple's developer and APNs terms, and whether the gateway is a processor or a mere conduit.]
7. What stays on your machines — and why Varrock is not the controller#
7.1 The Software is a tool you run on your own computers and servers. The following exists only there, is never transmitted to Varrock, and is under your control: your server list (names, hosts, usernames), sessions, layouts and profiles in the desktop app's data directory (com.oasis.gui); UI preferences in the embedded web view's local storage; the app log (oasis.log, rotated at 8 MiB), which at debug level includes hostnames and usernames of your servers; SSH keys under ~/.ssh/; OAuth tokens for AI provider accounts you sign into; mesh private keys (root-only); hardware-key credentials; and, under ~/.oasis/ on each managed host, agent-session transcripts and their search mirror, the agent event journal (last 500 events), chat keys, backup configuration including S3 credentials, VM images, browser profiles and the runner log. Oasis Mobile keeps your server list in Application Support, passwords and SSH keys in the Keychain, and your person identity in the Secure Enclave.
7.2 OasisNet is self-hosted. The Software ships with no coordinator configured; your organization adopts or stands up its own and may run its own relays. A coordinator stores, per node, the name chosen when it joined, its mesh IP, WireGuard public key, observed public endpoint (IP and port), local interface addresses and role flags, plus the public keys and roles of the people who administer the mesh. A chat relay stores encrypted messages it cannot read, plus metadata (who talks to whom, room identifiers, timestamps, sizes); offline mailboxes are kept 30 days and unclaimed attachments 72 hours. A room's history on the hub is compacted to its newest 1,000 messages; there is no time-based expiry. [DECISION: whether to state an additional time-based retention period for room history, or "until the room or host is deleted".] Varrock has no access to any of this. Your organization is the controller of its mesh; Varrock is neither controller nor processor. [DECISION: confirm Varrock offers no hosted coordinators or relays to customers; the coordinators Varrock runs serve only its own fleet.]
7.3 Requests under Sections 13 and 15 concerning this data should go to the organization that operates the mesh or machines.
8. Third-party services the Software contacts at your direction#
8.1 The Software can connect your machines to services operated by others. In every case the connection is made from your machine directly to that service, bypassing Varrock; Varrock receives nothing. Each service is an independent controller under its own privacy policy.
8.2 One such connection is on by default. Whenever the Mesh view (including a mesh device's detail panel) or the hover card over a server in the sidebar is shown, the desktop app sends the public endpoint IP address of the mesh peer(s) displayed to api.country.is to draw a country flag. Private, loopback and carrier-grade-NAT addresses are filtered out and results are cached for the session. A peer's endpoint IP may identify another person's connection, not only yours. There is currently no setting to disable this. [DECISION: before publication, add an off switch (recommended), remove the lookup, or keep and disclose; the operator and privacy terms of api.country.is are not established.] [COUNSEL: whether a default-on lookup disclosing third parties' IP addresses needs a basis other than legitimate interest, and whether Varrock has a controller role as the designer of the feature.]
8.3 Every other connection happens only when you turn a feature on or supply your own credentials: Anthropic (Claude account sign-in and usage); OpenRouter and ElevenLabs (AI supervisor, overseer and voice features, with your API keys); install scripts from Anthropic, OpenAI, Moonshot (Kimi), OpenCode, Nous Research and Homebrew when you click Install…; OS image mirrors (Canonical, Alpine, Docker Hub, GitHub) when you create a VM or device session; public-IP and timezone probes (api.ipify.org, Cloudflare cdn-cgi/trace, ip-api.com, ipapi.co); your own S3-compatible storage for backups; recipients' mail servers if you run the built-in mail server; public DNS resolvers (Cloudflare, Quad9) while a mesh exit node is engaged; and, on Windows, Microsoft's WebView2 runtime. (The one user-initiated download that reaches a Varrock host — the oasisnet binary for the "inference" VM template — is described in Section 5.5, not here.) [COUNSEL: confirm the "independent controllers" characterization and whether any should be listed individually in a consumer-facing notice.]
9. Recipients and sub-processors#
9.1 We share personal data only with: our hosting provider, which operates the infrastructure for oasisgui.com, downloads, the update manifest, the Portal and its database (Section 5.7) and (when live) the push gateway [DECISION: name the hosting provider and the data-center country; the repository does not identify it]; our email provider for sales@oasisgui.com [DECISION: name it]; Apple Inc. (APNs), only for push notifications once live; the recipients of a report listed in Section 5.6 — the operator or hosting provider of a host or network concerned and the third-party provider whose terms were circumvented (misuse reports), the upstream project that owns a defect in third-party code we ship, the coordinating CSIRT through the ENISA single reporting platform where Article 14 of the Cyber Resilience Act applies, law-enforcement authorities, and the readers of an advisory or the credits page (by the name you choose, only if you choose to be credited); and professional advisers, successors and authorities where the law requires or permits — a court order, legal claims, or a merger or sale of Varrock, in which case this policy continues to apply.
9.2 We do not sell personal data, do not share it for cross-context behavioral advertising, and do not use it to train models. The current list is in the Sub-processor List.
10. International transfers#
10.1 Varrock is established in the United States. If you are in the European Economic Area, the United Kingdom or Switzerland, the data in Section 5 is collected directly by Varrock from your browser or device and processed in [DECISION: country of the hosting provider].
10.2 Collection directly from you by a controller outside the EEA is, in the European Data Protection Board's view (Guidelines 05/2021), not itself a "transfer" under Chapter V GDPR; nonetheless the data is then subject to US law, and Varrock is not certified under the EU-US Data Privacy Framework. Where we pass personal data to a provider in a country without an adequacy decision (for example to Apple Inc. for push delivery, or to our hosting or email provider), we rely on the European Commission's Standard Contractual Clauses (Decision (EU) 2021/914) with the UK International Data Transfer Addendum where applicable. You can obtain a copy of the clauses we have entered into by contacting us (Section 18). [COUNSEL: confirm the transfer analysis — under EDPB Guidelines 05/2021 a controller subject to the GDPR under Article 3(2) that discloses to a third-country importer makes a transfer, and the 2021 SCCs were not designed for a non-EEA exporter; confirm which instrument to cite and that executed SCCs exist with each provider named in Section 9.]
11. Retention#
| Data | Retention |
|---|---|
| Web-server access logs (page views, downloads, update checks) | [DECISION: log retention period — recommend a fixed short period such as 14 or 30 days, after which logs are deleted or reduced to aggregates without IP addresses] |
Web-server access logs for the oasisnet binary download at start.oasis.cooking (VM template builds, 5.5) |
Same as the first row [DECISION: as in 5.5 — confirm the host-level log policy for start.oasis.cooking, or serve the binary from oasisgui.com/downloads/] |
Correspondence with sales@oasisgui.com |
Duration of the relationship plus [DECISION: period, e.g. 3 years], or longer where a legal obligation or dispute requires |
| Push-gateway traffic (when live) | Not stored by the gateway; web-server logs per the first row |
| Security reports and the vulnerability log (5.6; Vulnerability Disclosure Policy section 10.2) | The support period of the product concerned [DECISION: the support period — Vulnerability Disclosure Policy section 8.4] |
| Other people's personal data received in a proof of concept (5.6) | Until the fix ships |
| Published credit for a security report (5.6) | Until you ask us to remove it (Section 18) |
| Misuse reports and copyright, trademark or licence complaints (5.6) | [DECISION: retention period for misuse reports and rights complaints, for example three years after the matter is closed, longer where a legal claim requires] |
| Address blocklist under section 13.2(b) of the Acceptable Use Policy (5.6) | While the refusal stands; none exists today [DECISION: review period] |
| Website theme preference | In your browser until you clear site data or choose "auto" |
| Portal pre-sign-in cookie (5.7) | In your browser only, until you close it or sign in; nothing on our side |
| Portal session (5.7): keyed-hash sign-in token, CSRF token, issue-time IP address | Until you sign out, 7 days after your last request, or 30 days after sign-in, whichever is first; expired rows are deleted by a sweep at start-up and every ten minutes |
| Portal account (5.7): email address, name, password hash, creation and last-sign-in times, Tenant membership and its status | While your company's relationship with us lasts; then [DECISION: inactive-account retention, for example 24 months after the last sign-in, with notice where an address is known]; or earlier on your request (Section 13) |
| Portal Tenant (5.7): company name, domain, message, status, administrator's note | Approved: while the relationship lasts. Rejected or never approved: [DECISION: for example 12 months after rejection or after creation, then delete the Tenant and any account that belongs to no other Tenant] |
| Portal audit log (5.7): actor, action, target, IP address, time | 180 days, and never more than 200 000 lines (oldest deleted first) [DECISION: confirm the 180-day default; lines naming a deleted user are kept for the same period — COUNSEL marker in 5.7] |
| Portal security counters (5.7): event kind, IP address, 15-minute window, count | 7 days, then deleted |
| Portal rate-limit records (5.7): IP address, email address attempted, counter, window | The length of the window (15 minutes), then deleted by the sweep |
12. Security#
Connections to oasisgui.com and the push gateway use TLS. On the Portal (Section 5.7) passwords are hashed with Argon2id, sign-in tokens are random 32-byte values stored only as keyed hashes (HMAC-SHA256 under a server-side secret), the cookie is marked HttpOnly, Secure and SameSite=Lax, every state-changing request must carry a per-session anti-forgery token and come from our own origin, sign-in and sign-up are rate-limited per address and per email (and the front web server limits each address to ten requests per second), the Portal believes the client address forwarded by the front web server only when the request carries a secret that proves it came through that server, administrator accounts can be created only from the command line, membership in a company requires the owner's or an administrator's confirmation, and the Portal serves documentation files only from its read-only copy of the documentation tree. The Portal runs on a single server with a single database file; there is no replication, and backups of that database are [DECISION: whether the Portal database is backed up, where, how often and for how long — a backup is a further copy of every account and audit-log entry and needs the same retention and access rules as the live database]. macOS releases are Developer ID signed and notarized by Apple. Linux and Windows installers are not code-signed; they carry only the minisign update signature described next (the Windows installer shows a SmartScreen prompt). Each update artifact is signed with a minisign key whose public half is embedded in the app; the app verifies the downloaded file against that key before installing, so it installs only updates Varrock signed. The manifest itself is served over TLS but is not separately signed. Within the Software, remote access uses SSH keys and short-lived certificates, the mesh uses WireGuard, and mesh chat is end-to-end encrypted so relays never hold keys; credentials are stored with owner-only permissions, root-only for mesh keys, and in the Keychain or Secure Enclave on iOS. Our enterprise Security document describes the model and its known limitations. We hold no security certification and claim none. Vulnerabilities can be reported under the Vulnerability Disclosure Policy. [DECISION: security contact mailbox.]
13. Your rights#
13.1 If the GDPR or UK GDPR applies to you, you may: access the personal data we hold about you (Article 15); have it rectified (16) or erased (17); restrict its processing (18); receive it in a portable format where processing rests on contract or consent and is automated (20); and withdraw consent at any time without affecting earlier processing (7(3)), for example by unregistering your phone from push. We make no solely automated decisions with legal or similarly significant effects (Article 22).
13.1a Your right to object. Where we process your personal data on the basis of our legitimate interests (Sections 5.1, 5.2, 5.3, 5.4, 5.5, 5.6 and, for the audit log, rate limiting and the administrator's review of your application, 5.7), you have the right to object at any time on grounds relating to your particular situation (Article 21(1) GDPR). We will then stop unless we can show compelling legitimate grounds that override your interests, rights and freedoms, or the processing is needed for legal claims. To object, contact us as described in Section 18. For the update check you can also simply turn the periodic check off in the app.
13.2 How to exercise your rights. Email [DECISION: contact mailbox for privacy requests — do not use sales@oasisgui.com unless the company so decides; do not publish privacy@ or legal@ unless the mailbox is created]. We may need to verify your identity; for access-log data we can usually match a request only if you tell us the IP address and approximate time of your visit; for Portal data (Section 5.7) we match on the email address of your account, and because that address is unverified we will confirm the request with you before changing or deleting anything [DECISION: as in 5.7 — the confirmation step]. A request to delete a Portal account is honoured by deleting the account, its sessions and its Tenant membership; see Section 5.7 for what remains in the audit log and for how long. We respond within one month, extendable by two further months for complex requests. Requests are free unless manifestly unfounded or excessive.
13.3 Practical limits. Most data about you that the Software handles is on your own machines or your organization's mesh (Section 7); we cannot access, correct or delete it. For the website theme preference, clear your browser's site data for oasisgui.com. For the Portal, you can change nothing yourself in the first version except by signing out; name and email changes, password resets and deletion are done by us on request (Section 5.7) [DECISION: whether to add self-service editing of name, email and password, and self-service deletion, to the Portal's account page].
14. Complaints#
You may lodge a complaint with a supervisory authority, in particular in the EU Member State of your habitual residence, place of work or the place of the alleged infringement (Article 77 GDPR), or with the UK Information Commissioner's Office. We would appreciate the chance to address your concern first (Section 18).
15. Residents of California and other US states#
15.1 Threshold statement. The California Consumer Privacy Act, as amended by the CPRA, applies to a "business" meeting one of three thresholds: annual gross revenue above the CPI-adjusted figure (about USD 26.6 million); buying, selling or sharing the personal information of 100,000 or more consumers or households a year; or deriving half or more of revenue from selling or sharing personal information. Varrock does not sell or share personal information and does not believe it meets any of these thresholds, so we do not believe we are a "business" under the CCPA. Whether or not it applies, we extend the practices in 15.2 to every California resident. [COUNSEL: confirm against actual revenue and visitor counts; the same conclusion is expected under the laws of Virginia, Colorado, Connecticut, Utah, Texas, Oregon, Montana and Delaware's 6 Del. C. §12D-101 et seq.]
15.2 What we do regardless. This policy discloses the categories of personal information we collect (identifiers such as IP address, email address and name; account credentials in hashed form; professional information such as your company's name and web domain and the status of its application; internet activity such as pages requested and sign-in events) and the purposes (Section 5). We do not sell or share personal information, use sensitive personal information, or knowingly collect from consumers under 16. Any California resident may ask us to disclose or delete their personal information via Section 18; we honor such requests on the terms in Section 13 as a matter of policy, without discrimination. The website performs no tracking, so Do Not Track and Global Privacy Control signals are honored by default. This policy is posted in compliance with the California Online Privacy Protection Act.
16. Children#
The website and the Software are tools for people who administer computers and are not directed at children. We do not knowingly collect personal data from anyone under 16 (under 13 in the United States). If you believe a child has provided us with personal data, contact us (Section 18) and we will delete it.
17. EU representative and Data Protection Officer#
17.1 Varrock has no establishment in the EU or the UK. Article 27 GDPR requires a controller outside the EU to designate an EU representative where Article 3(2) applies, unless the processing is occasional, involves no large-scale special-category data and is unlikely to risk individuals' rights. Today our only processing of data about people in the EU is ordinary web-server logs (Sections 5.1–5.3 and 5.5), correspondence and reports people choose to send us (Sections 5.4 and 5.6), and the accounts of the enterprise users who ask for documentation access (Section 5.7), so we have not designated a representative. We will revisit this if the push gateway (Section 6) goes live for EU users. [COUNSEL: Article 27 applicability — the exemption likely applies, but the conclusion changes if EU users are targeted more deliberately (EU-language pages, EU pricing) or if the push gateway goes live for EU users; UK GDPR Article 27 likewise.] [COUNSEL: whether the Portal changes the Article 27(2)(a) analysis — it is the first Varrock-held store of named EU individuals (employees of EU enterprise customers, with IP-addressed audit records kept for months) rather than transient logs; the processing is still small-scale and not of special-category data, but it is no longer "occasional" for each account holder.]
17.2 We have not appointed a Data Protection Officer because the conditions of Article 37 GDPR are not met.
18. Contact#
- Email: [DECISION: contact mailbox for privacy requests]
- Post: Varrock Inc., [DECISION: controller postal address]
- Sales and licensing enquiries only:
sales@oasisgui.com
19. Changes to this policy#
We may update this policy when the Software, the website or the law changes. The effective date above changes with every revision; material changes are also announced in the Software's release notes and on the website. The current version is always at [DECISION: canonical URL, e.g. https://oasisgui.com/privacy/]. The Software has no accounts, so we cannot notify its users individually; Portal account holders (Section 5.7) [DECISION: whether material changes are also announced to Portal account holders — a notice on the /account page at next sign-in is possible without email; an email notice is not, since the Portal sends no email and addresses are unverified]. Material changes take effect no earlier than 30 days after they are posted [DECISION: notice period] and do not apply retroactively to data collected under an earlier version without your consent where consent is the basis. Previous versions are kept at [DECISION: archive URL, e.g. https://oasisgui.com/privacy/archive/] or are available on request (Section 18). Each revision also carries a "last updated" date alongside the effective date.
20. Open decisions#
Every marker used in this draft; grep for [DECISION: and [COUNSEL: to find each in context.
Owner decisions
- [DECISION: effective date] — top of document.
- [DECISION: controller postal address] — 1.3, 18.
- [DECISION: whether this policy covers Oasis Mobile now, given it is supplied only by direct install or TestFlight at 2.0.0] — 1.1.
- [DECISION: host-level web-server access-log setting and retention for page views, downloads and update checks] — 5.1–5.3.
- [DECISION: host-level access-log policy for
start.oasis.cooking, or move theoasisnetbinary underoasisgui.com/downloads/] — 5.5, 11. - [DECISION: confirm the published site uses system fonts only] — 5.1.
- [DECISION: administrator switch for the launch-time update check] — 5.3.
- [DECISION: email provider hosting
sales@oasisgui.com] — 5.4, 9.1. - [DECISION: enable push with the Varrock gateway, ship self-host-only, or omit Section 6 until live] — 6.2.
- [DECISION: access-log policy in front of
push.oasis.cooking] — 6.3. - [DECISION: confirm the gateway's dry-run logging mode is disabled in production and add the check to the deployment procedure] — 6.3.
- [DECISION: whether to add a time-based retention period for hub chat-room history beyond the 1,000-message cap] — 7.2.
- [DECISION: confirm Varrock offers no hosted coordinators or relays to customers] — 7.2.
- [DECISION:
api.country.is— off switch, remove, or keep and disclose] — 2, 8.2. - [DECISION: hosting provider name and data-center country] — 9.1, 10.1.
- [DECISION: log retention period] — 11.
- [DECISION: retention period for sales correspondence] — 11.
- [DECISION: security contact mailbox] — 12.
- [DECISION: contact mailbox for privacy requests] — 13.2, 18.
- [DECISION: canonical URL of this policy] — 19.
- [DECISION: notice period for material changes] — 19.
- [DECISION: archive URL for previous versions] — 19.
22a. [DECISION: abuse, security and rights mailboxes — only
sales@oasisgui.comexists today] — 5.6. 22b. [DECISION: the support period that fixes the retention of security reports and the vulnerability log — Vulnerability Disclosure Policy section 8.4] — 5.6, 11. 22c. [DECISION: retention period for misuse reports and rights complaints] — 5.6, 11. 22d. [DECISION: retention and review period for any address blocklist under Acceptable Use Policy section 13.2(b), should one be created] — 5.6, 11. 22e. Resolved 2026-10-06: Section 5.7 verified againstportal/src/(db.tsschema;auth.tscookie, session and client-address handling;routes/auth.ts,routes/account.ts,routes/admin.tsaudit and counter calls;views/admin.tsandviews/pages.tspages;config.tslifetimes). Remaining: check the liveSet-Cookieheader after deployment — 5.7. 22f. Resolved by the code: a second person joins by entering the Tenant's join code (shown to the owner only) and is a pending member until the owner or an administrator confirms them; no domain matching, no disclosure of colleagues' accounts before confirmation — 5.7. 22g. Resolved by the code: failed sign-ins against an existing account are written once per account and 15-minute window; attempts with an unknown address are only counted per IP address (security counters, 7 days) — 5.7. 22h. [DECISION: how an administrator confirms identity before resetting a password, changing or deleting an account, given that email addresses are unverified] — 5.7, 13.2. 22i. [DECISION: name the role that holds Portal administrator access (published by role, not by name)] — 5.7. 22j. Resolved by the code: confirmed members see each other's names, email addresses and status; pending joiners see only the Tenant's name and status — 5.7. 22k. [DECISION: self-service account deletion versus deletion on request; self-service editing of name, email and password] — 5.7, 13.3. 22l. Resolved by the code: 7-day idle timeout (config.ts,sessionIdle); expired sessions, rate-limit rows, audit lines past retention and old counters are purged by a sweep at start-up and every ten minutes (db.ts,sweep) — 5.7, 11. 22m. [DECISION: inactive-account retention and rejected-Tenant retention] — 5.7, 11. 22n. [DECISION: confirm the audit-log retention of 180 days (the code's default,AUDIT_RETENTION_DAYS) and the 200 000-line cap] — 5.7, 11. 22o. [DECISION: Portal database backups — whether, where, how often, for how long] — 12. 22p. [DECISION: whether material changes to this policy are announced to Portal account holders on the account page] — 19.
Counsel decisions
- [COUNSEL: controller/processor split for the push gateway; household-use exemption for an individual's own traffic] — 1.2.
- [COUNSEL: whether Article 3(2) GDPR / UK GDPR applies to Varrock at all; consistency with Terms of Service §18.3] — 1.2.
- [COUNSEL: legitimate-interest assessment for access logs once the retention period is set; written LIA] — 5.1.
- [COUNSEL: 6(1)(f) led with for downloads because most downloaders act for an employer-licensee] — 5.2.
- [COUNSEL: legal basis for the default-on update check, 6(1)(f) vs 6(1)(b)] — 5.3.
- [COUNSEL: legal basis for an individual's own push registrations — 6(1)(a) or 6(1)(b), and withdrawal mechanics] — 6.4.
- [COUNSEL: Apple APNs terms; processor vs mere-conduit status of the push gateway] — 6.4.
- [COUNSEL: legal basis and Varrock's role for the default-on peer-IP lookup to
api.country.is] — 8.2. - [COUNSEL: "independent controllers" characterization of user-configured third-party services] — 8.3.
- [COUNSEL: Chapter V transfer analysis under EDPB Guidelines 05/2021 for an Article 3(2) controller; which instrument to cite; executed SCCs with each Section 9 provider] — 10.2.
- [COUNSEL: CCPA/CPRA and other US state thresholds against actual figures] — 15.1.
- [COUNSEL: Article 27 EU/UK representative applicability] — 17.1. 34a. [COUNSEL: whether Article 14 of the Cyber Resilience Act binds Varrock now; Article 6(1)(c) or 6(1)(f) for authority notifications until it does; 6(1)(f) for onward disclosure of misuse reports to operators, providers and authorities] — 5.6. 34b. [COUNSEL: legal basis for publishing a reporter's chosen credit — request under 6(1)(f) or consent under 6(1)(a) — and the withdrawal mechanics] — 5.6. 34c. [COUNSEL: whether Article 6(1)(b) carries the Portal account and Tenant-approval processing when the person signing up is an employee and the enterprise relationship is with the employer, or whether 6(1)(f) should lead] — 5.7. 34d. [COUNSEL: legitimate-interest assessment for the Portal audit log (IP address of every sign-in) and for the manual review of a person's name and email address against a claimed employer; Recital 49] — 5.7. 34e. [COUNSEL: whether audit-log lines that identify a deleted user by email address may be kept for the security-log period or must be pseudonymised at deletion] — 5.7. 34f. [COUNSEL: whether the Portal — the first Varrock-held store of named EU individuals — changes the Article 27(2)(a) "occasional processing" conclusion] — 17.1.
Repository facts relied on (verified 2026-10-06): src-tauri/tauri.conf.json (update endpoint); src/UpdatePrompt.tsx, src/updater.ts (cadence, opt-out); tauri-plugin-updater 2.10.1 src/updater.rs lines 44, 388–391, 451 (request headers); website/index.html, website/main.ts, website/build-docs.ts (storage key, no cookies, same-origin demo); deploy/k8s/oasisgui.yaml (access_log off scope); src-tauri/src/geoip.rs; src-tauri/src/mesh_manager/mesh_config.rs (no default coordinator); OasisMobile/Oasis/Notifications/NotificationModel.swift, runner/oasis-runner/src/notify/push.rs, push/README.md (push gateway); chat/chat-proto/src/limits.rs and oasisnet/src/chat_store.rs (chat room history cap); nix/vm-templates/lib/mesh.nix, src-tauri/src/vm_templates.rs (start.oasis.cooking fetch in the bundled "inference" template); src/ServerStats.tsx, src/MeshModal.tsx (api.country.is triggers); push/server/src/main.rs, push/README.md (dry-run logging); scripts/release.sh, docs/enterprise/02-security.md (signing: macOS only; minisign per artifact); tauri-plugin-updater 2.10.1 src/updater.rs line 712 (artifact signature verification); website/index.html (Oasis Mobile not on the App Store); deploy/k8s/oasisgui.yaml (no deny rules or address blocklist in the web-server configuration); owner statement of 2026-10-06 (company facts). Section 5.7 was verified against portal/src/ (same change set, 2026-10-06): db.ts (tables users with member_status, created_at, last_login_at; tenants with join_code; sessions with ip; admins; audit_log; security_events; rate_limits; sweep), auth.ts (issueAnonSession, sessionCookie — Max-Age 30 days for signed-in tokens, none for the anonymous one — loadSession, clientIp with the proxy token, mayReadDocs), config.ts (30-day absolute and 7-day idle session life, 24-hour anonymous-cookie validity, 180-day audit retention and 200 000-line cap, 7-day counter retention, 10 attempts per 15 minutes), routes/auth.ts, routes/account.ts, routes/admin.ts (which events are audited and which are counted), views/admin.ts (audit tail and counters on the administration page), views/pages.ts (join code shown to the owner only; member list only to confirmed members), cliCommands.ts (create-admin, promote, set-password, delete-user, delete-tenant, rotate-code, purge-test-data), deploy/nginx-portal-proxy.conf and nginx-portal-limits.conf (front-server rate limit and proxy token). No email sending, no email verification, no password reset page. The landing page at /docs/ lists document titles only, is public and sets no cookie. The processing in Section 5.6 is created by the Acceptable Use Policy (sections 12 and 13.2), the Vulnerability Disclosure Policy (sections 4.7, 5.6, 6.5 and 10.2) and the Trademark and Copyright Notice (sections 9.2 and 10.1), not by the code.
Source: docs/legal/privacy-policy.md in the repository · draft for attorney review · 83 [DECISION] markers and 37 [COUNSEL] markers on this page.