Privacy Policy

Privacy Policy for Doctor Iota Applications

Effective date: 2026-08-30

This Privacy Policy explains what information Doctor Iota's applications ("our apps", "our services", "we", "us") process when you use them, why we process it, and the choices you have. We design for privacy and collect only what is necessary to provide the experience described in each app's documentation.

If you have questions or requests, contact: driota.xyz@gmail.com.

This policy describes features across our current and imminent releases, and our apps do not all have the same ones. So it is written in terms of what an app does rather than which app it is: a catalogue of names goes stale the moment one ships or changes, while the distinctions below stay true — and each of them is something you can check against the app in your hand rather than take on trust. Any feature described here as optional is opt‑in, always.

What our applications do

We make two kinds of application. Interactive apps for mathematical art, education and recreation — fractal explorers, geometry playgrounds, packing and sliding puzzles — some free, some with an optional rewarded‑ad choice or a one‑time purchase. And developer tools, which connect to machines you already own and browse or work on what is there.

Which apps exist, and what each one offers, is on our website and wherever you get the app — its store page, or its release page where we distribute it directly. This policy does not list them, because such a list is out of date as soon as an app ships or changes, and a policy that is out of date about its own catalogue is worse than one that never claimed to have it.

Three distinctions run through the rest of this policy, because our apps differ in what they do rather than in what we intend. Each is something you can check for yourself rather than take on trust:

• Apps with ads and apps without. Only some of our apps offer ads; they are always rewarded ads you choose to watch, never banners or interstitials; and the ad network is Google AdMob, which is the only one we use at present — if that ever changes, this policy changes with it. An app without ads loads no ad SDK at all. Whether an app has ads is stated wherever you get the app — its store page, or its release page where we distribute it directly — before you install it. How this pairs with buying something is set out just below.
• Apps that ask you to set credentials, and apps that never do. Some apps connect to a machine that is yours — a server you have a login for — and to do that they have to ask you for a username, a password or a key. What happens to those credentials is set out under Information stored on your device, and it is the same in every app of ours that asks: they stay on your device. An app that never asks you for a credential holds none, and none of that section applies to it. You can tell which kind you have by whether it ever asks.
• Apps that fetch something on launch, and apps that fetch nothing. Our interactive apps make two small one-way requests to our own hosting — an update check, and an optional "related links" feed for the side pane. That is us, not a third party. Our developer tools make no automatic request to our hosting at all, not even an update check. Where a build sells an unlock, the platform's store is a separate channel — not a request of ours — and when it is asked is under Ads and purchases below.

Ads and purchases: the three combinations

The first of those distinctions has a second half — whether a given build sells anything — and the two together make three combinations rather than four. Every native build of ours is exactly one of them. Where a store lists the app, it says which before you install it — whether it contains ads, and whether it offers in-app purchases, are both stated there by the store itself, not only by us. The same app can be a different kind on a different build: a desktop or web copy often has nothing to buy and no ads, even when the phone copy has one or both. The three differ in what reaches a third party, and they are listed so that each adds exactly one thing to the one before it:

1. Free, with nothing to buy. No ad network, no billing library, no purchase. Nothing in the app reaches any third party at all. Interactive builds of this kind still make the small requests already described — an update check and, where enabled, the links feed — and those go to our own hosting, not to a third party. Developer tools of this kind request nothing automatic at all.
2. Free, with no ads, and a purchase that unlocks features. Adds the store, and nothing else: no ad network, no advertising identifier, no ad SDK in the binary. The only third party is the one handling the payment. A developer tool that sells an unlock is this kind on the builds that carry the billing library (typically the phone copy); a desktop build of the same tool may have nothing to buy, and is then kind 1.
3. Free, with ads, and a purchase. Adds the ad network (Google AdMob) on top of the store, and this is the only kind in which an advertising identifier is ever involved. Ads are rewarded and never shown unless you choose to watch one. There is always a one-time purchase that makes watching ads unnecessary for the feature they were topping up, because we will not ship an app whose only way past an ad is to watch it — and that purchase may also unlock things that no amount of watching would: an ad refills an allowance, while some features are simply part of what you bought. An app of this kind may sell more than one such unlock; buying one drops the ads for that feature, not necessarily for every feature. So a kind-3 purchase is not only "remove the ads"; it is the same sort of unlock as kind 2, with watching ads no longer needed for what you bought.

The relationship runs one way only. Ads always come with a purchase that makes them unnecessary for the feature they were topping up; a purchase does not imply ads. Kind 2 is a real kind and not a quieter kind 3: an app that sells an unlock is not thereby carrying an ad network, and you can check that against the app in your hand — its store page lists ads and purchases separately.

In kinds 2 and 3 each purchase is a one-time payment: never a subscription, never an account, and never anything that expires. An app may offer one unlock or several; each is a single payment. What it involves is under Information stored on your device, and who handles it is in the third-party table.

What the store is asked. Where a build sells an unlock, the platform's store is spoken to only about that purchase — whether you own it, what it costs in your own currency, and buying or restoring it. It tells us nothing at all, because there is no server of ours anywhere in it: what the app on your device receives back is whether the unlock is owned, and the price to show you — never who you are, and never a card. A purchase you made before is therefore simply there on a new device of yours, and buying again is something the store will not charge you twice for.

A billing library is not an ad SDK: it is present only in kinds 2 and 3, and only on the builds that sell something.

In the future, we may add optional user accounts and multi‑user experiences (e.g., shared sessions or games) to our apps. We will continue to follow a strict data‑minimization approach across all our services.

Our apps are distributed in multiple forms:

• Native installations (mobile / desktop): available as published releases and preview builds, sometimes trailing the latest web version. Once installed, they run on your device and work fully offline. In the interactive apps, the only automatic network activity is a launch‑time update check and, where enabled, a small "related links" feed for the side pane, both downloaded from our own hosting (see Information processed automatically); any other network use happens only for features you explicitly invoke (e.g., share‑by‑link, or a rewarded ad you choose to watch). Our developer tools make no automatic request to our hosting at all — not even an update check — and connect only where you tell them to. Where a build sells an unlock, the store may be asked as described under Ads and purchases above.
• Web version, where we offer one: for the interactive apps it is usually the most up‑to‑date deployed form; a developer tool may be native‑only and have no web version at all. Served from our hosting provider over HTTPS, then runs in your browser. Standard web‑server logs may be retained by the hosting layer.

Some of our apps are free with an optional rewarded‑ad choice: an app with ads lets you choose to watch a short ad (via Google AdMob, the only ad network we use) to refill an in‑game allowance, as a free alternative to a one‑time in‑app purchase. Apps without ads — which includes all of our developer tools — load no ad SDK at all, though some builds of them do sell a one-time unlock of their own, which has nothing to do with advertising and brings no ad network with it. No ads are ever shown unless you actively choose to watch one — there are no banners, no interstitials, and nothing on launch — and the web versions have no ads at all. Buying the corresponding purchase removes the need to watch ads for that feature. On our website we use cookieless, privacy‑preserving analytics (Cloudflare Web Analytics) that counts visits in aggregate without identifying you. These practices are detailed in the Analytics and ads section below.

Summary

• We do not sell your data, serve targeted ads of our own, or share personal information with third parties for their own marketing.
• Our apps are fully functional without an account. Native installations run on your device and work offline — the interactive apps aside from a launch‑time update check and an optional side‑pane "related links" feed downloaded from our own hosting, and the developer tools with no automatic request to our hosting of any kind. The web version is loaded from our hosting provider and then runs in your browser, with no ongoing API calls of our own.
• We store settings locally on your device (e.g., theme, user-customized color schemes, and speaker/voice settings; a language setting is saved once you use that feature). Share links encode view parameters in the URL.
• We use a cookieless, non-identifying analytics service (Cloudflare Web Analytics) to measure aggregate traffic on our website. The apps themselves (native and in-browser) include no analytics of ours.
• Our apps with ads offer optional rewarded ads (Google AdMob) that play only when you choose to watch one, as a free alternative to an in-app purchase; no ads appear otherwise. Our apps without ads contain no ad SDK, so there is nothing to appear. Ad networks have their own data practices (see Analytics and ads). The web versions show no ads.
• Some of our apps sell one-time unlocks — no subscription, no account, nothing that expires. An app may sell one or more; each is a single payment. Where an app has ads, buying the corresponding unlock removes the need to watch them for that feature; where an app has none, a purchase unlocks a feature. A purchase is always optional, the platform's own store handles it, and nothing about it reaches us.
• We do not set our own cookies, and our analytics is cookieless. When you choose to watch an optional ad, the ad network (Google AdMob) may use device identifiers or on-device storage governed by its own privacy policy.

Information we process

We collect no personal information for our own use. Native installations run on your device once installed and work offline — the interactive apps aside from a launch‑time update check and an optional side‑pane "related links" feed downloaded from our own hosting, and the developer tools with no automatic request to our hosting whatsoever. Where a build sells an unlock, the store may be asked as described under Ads and purchases. Only our apps that offer the optional-ad choice include a third-party ad SDK (Google AdMob), which requests an ad only when you choose to watch one; an app without ads carries no ad SDK at all. The web version is loaded from our hosting provider and runs in your browser, with no analytics of ours; our informational website separately uses cookieless, aggregate visitor analytics. The subsections below describe what is stored locally and what is processed automatically across these forms.

Information stored on your device

• App preferences and parameters: When you adjust controls (e.g., theme, color schemes, speaker/voice, and language), that information is stored locally in the app or in your browser for the web version. This information is not transmitted to us. URLs you choose to share in the web version may contain parameters that describe the view.
• Game progress and content: Some apps store gameplay state locally — for example, puzzle progress, saved boards, and in‑app allowance counts ("meters"). This stays on your device and is not transmitted to us.
• In‑app purchases: Where an app offers a one‑time purchase, we store only a local flag recording that you own it, so the feature stays unlocked. An app may have more than one such flag. Payment is handled entirely by the platform's own store — Google Play or the Apple App Store — and we do not receive or store your payment details (see Data sharing).
• Optional feedback or support messages: If you contact us via email, we will receive the information you include in your message.

If an app asked you for credentials

Some of our apps connect to a machine of your own and have to ask you for the details to get in. Today those are our SSH tools: they browse folders on a machine you have a login for and give you a terminal on it, which cannot be done without your credentials for that machine. Anything similar we ship later works the same way, whatever protocol it speaks. For those apps, and only those:

Credentials for your own machine are stored on your device and never sent to us. There is no server of ours to send them to. Specifically:

• Connection bookmarks: the host, port, username, the path to your key, the folder to open, and the other connection settings you choose — such as a terminal type, a command to run on connecting, or environment variables you want set on the far end. Never a password or a passphrase — those are kept apart from the bookmark by design. The rest of a bookmark is stored as you typed it, so a value you put in one yourself is worth the same care as anything else you would leave in a settings file.
• Passwords and key passphrases: stored only if you say so — the app asks before remembering one, and says how this platform will keep it. Where the operating system has a credential store — the Apple Keychain on macOS and iOS, Windows Credential Manager, or a Linux Secret Service — that is where it goes. On Android, which offers no such store, a secret you agree to remember is written to a file in the app's own private storage, readable by that app alone and excluded from backup and device transfer. Decline, and the secret is kept in memory for the session only and is gone when the app exits. On a desktop system that has no credential store either, nothing is written down at all and you are not offered the choice — the secret lasts the session and no longer.
• Keys: a key the app generates for the device, or one you import into it, is stored in the app's own private storage, readable only by the app. The public half is what goes to your server.
• Machine identities: the fingerprints of the machines you have chosen to trust, kept the way any careful client of that protocol keeps them, so a machine whose identity has changed is refused rather than trusted silently.
• Folders you grant on a mobile device: mobile platforms hand an app one folder at a time rather than a filesystem, and choosing a folder grants read access to exactly that folder and nothing else. The system remembers the grant and you can revoke it in system settings at any time. No broad or all-files permission is ever requested, on any platform.
• Recently opened folders, folders you pinned, and view preferences: paths, bookmark names, theme, and which folders are expanded.
• Copies you asked for: where such an app can save a file from the machine you connected to, the copy goes where you choose — on a mobile device, into the app's own storage, because there is nowhere else it may write. One is made only when you ask for it.

Uninstalling removes all of it. Deleting a bookmark removes the secret and the key that belonged to it.

What such an app reads. Files and folders you open, in order to show them to you: names, sizes, modification times, and the contents of the file on screen. Nothing is indexed, nothing is scanned, and nothing is read that you have not navigated to — on a mobile device it can reach only the folders you granted, and its own private storage. What it reads is displayed to you and is not sent anywhere; the only traffic from reading it is to the machine you connected to. (A build that sells an unlock may also talk to the store as described under Ads and purchases — that is about the purchase, not about the files.)

None of this applies to an app that never asked you for a credential. Our math and puzzle apps hold no password, no key and no host of yours, because they never ask for one and have nowhere to connect to.

Information processed automatically

What is processed automatically depends on how you use the app:

• Native installations (mobile / desktop): Once installed, run on your device with no analytics of ours and work fully offline. On launch the interactive apps make up to two one-way content requests to our own hosting: an update-availability check (<app>-versions.json) and, where the side "related links" pane is enabled, a small links feed (aux-pane-links.json). Our developer tools make neither request. These downloads send no personal data and are skipped silently when you are offline; they are requests to us, not to a third party, though the hosting layer may see your device's IP address and User-Agent on each request, as with any web request. Where a build sells an unlock, the platform's store is spoken to about that purchase (see Ads and purchases); that is not a request to our hosting. Our apps with ads include the Google AdMob SDK so you can choose to watch a rewarded ad. The SDK may initialize when a screen that can offer an ad first appears (a wallet, a game, a refill prompt); an ad is requested only when you tap to watch one, and at that point AdMob may collect data such as IP, device/advertising identifiers, ad interactions, and coarse location per Google's privacy policy (see Analytics and ads). If you never watch an ad (or you own the corresponding purchase), no ad is requested. Our apps without ads load no ad SDK. A billing library is present only in kinds 2 and 3, and only on the builds that sell something.
• Web version: Delivered as static files from our hosting provider over HTTPS. The hosting infrastructure may retain standard web-server logs (IP address, request URL, timestamp, User-Agent) for delivery and abuse prevention. The web versions contain no ads and no analytics of ours. Once loaded, the app runs in your browser and we make no further API calls of our own. (Our informational website separately uses cookieless visitor analytics — see Analytics and ads.)

Our apps may read device/runtime capabilities (e.g., WebGL features) locally to adapt rendering. This information stays on-device.

We use your device's or browser's local storage to save your settings; this data is not transmitted to us.

Future features (accounts and multiplayer)

If we introduce accounts or multi‑user experiences in any of our apps, we will process only the minimum data required. These features would require a server connection.

• Account identifiers: For example, an email address or an OAuth provider identifier, plus authentication tokens. We will not request profile details beyond what is necessary to authenticate and provide the service.
• Display name (optional): If shown to other users in multiplayer contexts.
• Personal sync (preferences, history, saved views): if you sign in, the app may store your preferences, in-app history, and saved views on our servers so they follow you across devices. This data exists to serve you; we do not analyze account contents for advertising, profiling, or sale.
• Shared session state: Parameters needed to synchronize a session between participants (e.g., the current view, and room or session identifiers). This may be visible to other participants you explicitly join.
• Moderation/anti‑abuse signals: Minimal metadata strictly needed to keep the service safe (e.g., rate limiting data, rule violations where applicable).
• Basic service logs: Our hosting and security systems may log standard metadata such as IP address, request headers, timestamps, error details, and basic performance metrics. This is used for operations (e.g., troubleshooting, abuse prevention) and kept for a limited retention period.

We will update this policy and, where required, request consent before launching such features.

How we use information

• Provide and improve our apps, including rendering, performance, and reliability.
• Offer requested features such as share‑by‑link; links may contain parameters that reveal your current view/choices to anyone with the link.
• Communicate with you about our apps if you reach out to us.

Legal bases (EEA/UK users)

Where applicable, we rely on the following legal bases:

• Performance of a contract: To provide our apps and requested features.
• Legitimate interests: For security, fraud prevention, service reliability, and aggregate, cookieless website analytics that does not identify you.
• Consent: Where required (e.g., an optional rewarded ad you choose to watch, obtained through Google's UMP consent flow in the EEA/UK; or new server-side features). You can withdraw or change your choice at any time — in an app with ads, from Privacy choices for ads on its Wallet page.

Third parties and SDKs at a glance

The table below summarizes every party our apps or website may reach and what each one sees. Our own hosting is listed because the hosting layer may retain standard delivery logs; it is not an ad network or a store. Details follow in Analytics and ads and Data sharing.

Analytics and ads

Website analytics (cookieless). On our website we use Cloudflare Web Analytics, a privacy-preserving service that measures aggregate traffic (e.g., page views, referrers, approximate country, device type) without cookies and without building profiles of individuals. It does not track you across sites and collects no information that identifies you; its handling is governed by Cloudflare's privacy policy. We use it only to understand overall usage and reliability. Native installations include no analytics of ours.

Third-party ads (optional, user-initiated). Our apps with ads let you choose to watch a rewarded ad via Google AdMob (the Google Mobile Ads SDK), the only ad network we use, as a free alternative to a one-time in-app purchase. An app without ads does not include the SDK, so none of this paragraph applies to it. Ads are never shown automatically: there are no banners, no interstitials, and nothing on launch — an ad loads only when you tap to watch one, and if you own the corresponding purchase the watch-ad option isn't offered at all. The SDK may initialize when a screen that can offer an ad first appears, so that a watch is possible; that is not the same as showing an ad. When you do choose to watch, AdMob loads that ad on-device and may collect data such as IP, device/advertising identifiers (the Android Advertising ID, or Apple's IDFA where you have allowed tracking), ad interactions, and coarse location, and may use on-device storage — all governed by Google's privacy policy and Google's advertising/partner policies. We configure AdMob to serve age-appropriate ads for a general audience. Depending on your consent choice, a rewarded ad may be personalized (tailored using the identifiers above) or non-personalized (chosen only from context, such as the app and the ad's surroundings). In the EEA/UK, a Google-certified consent (UMP) message is shown as required. On iOS, using those identifiers additionally requires your permission through Apple's App Tracking Transparency prompt, and declining it means an ad is chosen without them. You can change either choice at any time, in the app or in system settings. The web versions contain no ads.

Data sharing

We do not sell personal data. We share data with third parties only as follows:

• Hosting provider (web version): standard web-server delivery; the provider may retain access logs as described above.
• Cloudflare Web Analytics (informational website only): receives cookieless, aggregate traffic measurements; no personal profiles and no cross-site tracking. It is not present in the apps themselves (native or in-browser).
• Google AdMob (native apps with the optional-ad choice): the SDK may initialize when a screen that can offer an ad appears; it receives data for an ad only when you choose to watch a rewarded ad, as described in Analytics and ads, per Google's privacy policy. If you never watch an ad, no ad is requested. The web versions share no data with ad networks.
• The platform's app store (in‑app purchases): Google Play or the Apple App Store processes payment for one‑time purchases and reports ownership status to the app so it can unlock the feature, and supplies the localized price it displays. We receive no card or payment details. Governed by that store's own privacy policy.
• Service providers (future server-side features): e.g., error logging, under agreements that restrict their use of data to our instructions.
• Legal and safety: If required by law or to protect the rights, property, or safety of users or the public.

Data retention

• Local preferences: Stored on your device until you clear them.
• Server logs/diagnostics (future): If we introduce server features, logs will be retained only as long as necessary for operations and security, then deleted or anonymized.
• Account and multiplayer data (future): Retained for as long as your account or session is active and for a reasonable period thereafter for backup, security, or legal compliance.

International transfers

Currently, we do not transfer personal data across borders — we collect none of our own. Third-party providers we use (e.g., Google AdMob for optional rewarded ads, the platform's app store for one‑time unlocks, Cloudflare for cookieless web analytics) may process data internationally under their own privacy policies and safeguards. If we introduce server-based features in the future that involve transferring user data across borders, we will use appropriate safeguards (e.g., Standard Contractual Clauses) where required by law.

Your rights

Depending on your location, you may have rights to access, correct, delete, or export your information, and to object to or restrict certain processing. As we do not currently hold any of your personal information, these rights are not applicable at this time. To exercise these rights in relation to future services or for any privacy-related questions, contact us using the details above. We will honor these requests as required by applicable law.

Children, schools, and education contexts

COPPA (United States, under 13)

Our applications are directed to a general audience (13 and older), not to children under 13 (or the minimum age required by your jurisdiction), and we do not knowingly collect personal information from children under 13. We keep no accounts and run no analytics of our own in native apps; our web analytics is cookieless and non-identifying. Our apps with ads use Google AdMob configured for general audiences — ads (shown only when a user chooses to watch one) are limited to age-appropriate content and the app is not flagged as child-directed — so we do not knowingly permit child-directed data collection.

If we introduce features that would collect personal information (e.g., accounts, multiplayer rooms, classroom mode), we will either verify users are 13 or older at sign-up, or, where features are expressly directed to under-13 users, obtain verifiable parental consent as required by COPPA before enabling those features for that account. We will not enable child-directed features by default.

If you believe a child under 13 has provided personal data to us, contact us at driota.xyz@gmail.com and we will delete it.

FERPA (United States schools)

We are not, by default, a "school official" with a legitimate educational interest under FERPA — schools do not need to give us access to student education records to use our apps as they ship today. The apps run locally (native) or in the browser (web) and do not require accounts.

If a school adopts a future classroom feature that involves processing student records on our behalf (e.g., per-class progress tracking, teacher-led sessions tied to student rosters), we will operate as a school official under the school's direct control, under a written data-handling agreement, and only for the educational purposes the school authorizes. We will not use student records for advertising, profiling, or sale.

What to evaluate

For schools or districts evaluating our apps:

• Our apps do not require accounts and collect no personal information for our own use. The web is delivered through standard hosting logs (IP, User-Agent, request URL, timestamp) plus cookieless, non-identifying Cloudflare Web Analytics; native apps include no analytics of ours.
• Future classroom features will be opt-in per school and governed by a written data-handling agreement; details will be disclosed before activation.
• Apps with ads let a user watch a rewarded ad only by choice (Google AdMob, general-audience content; see Analytics and ads); nothing is shown otherwise. For classroom use with no ad-network involvement, use the web versions (no ads), a one-time in-app purchase, or simply don't use the watch-ad option.

Schools or parents with questions: driota.xyz@gmail.com.

Security

We use reasonable administrative, technical, and organizational measures to protect information. Our apps are designed to be secure by default, with minimal privileges. Native installations function fully offline once installed: the interactive apps make no automatic network calls of their own beyond a launch‑time update check and an optional side‑pane "related links" feed to our own hosting (see Information processed automatically), and the developer tools make none to our hosting at all — such an app connects only where you tell it to, by whatever protocol that tool uses, and the connection is encrypted by that protocol. Where a build sells an unlock, the store may be asked as described under Ads and purchases. Credentials go to your operating system's own credential store where the platform has one — on Android, which has none, a credential you agree to remember is kept, like the keys, in the app's private storage that only it can read, and where a desktop has none either nothing is written down at all — and in every case they stay on the device (see Information stored on your device). Where a remote machine's identity can be checked, it is, and a machine whose identity has changed is refused rather than trusted silently. The web version requires loading from our hosting provider but does not contact our servers thereafter. Any external links are opened in your device's default browser, not within the application itself. No system is 100% secure; we encourage you to use current software and secure your devices.

Changes to this policy

We may update this policy to reflect changes in our apps or law. We will post the updated version here and revise the effective date. Material changes will be highlighted within the relevant app(s) where appropriate.

Contact

Questions or requests: driota.xyz@gmail.com