Desktop tools · Consent policy 2
Optional usage sharing
No tracking by default. Share usage only with your permission.
Availability
Current desktop development builds keep usage sharing disabled. The information below describes the reporting policy for builds that enable it after verification. Those builds ask for your permission before collecting any counts.
What is shared
- Rinse: how many cleaned results you explicitly copy.
- Spool: completed rename batches, files renamed and batches undone.
- Thimble: exported image batches, images exported and images that failed to export.
Each summary also includes the app’s identifier and version, operating system, processor architecture, schema and consent-policy versions, and a random report ID used to avoid counting a retry twice.
Reports do not contain your text, images, filenames, paths, clipboard contents, raw error messages, location, account information or a persistent device identifier. There is no session recording.
Your choice
Sharing is off until you review the disclosure and choose Share usage. Declining is remembered. Every feature remains available without sharing. Consent applies independently to each app.
Use Settings → Privacy & usage to inspect unsent counts or turn sharing off. Turning it off or resetting preferences clears unsent counts and stops future reports. A request already received cannot be recalled from your computer. Importing preferences never grants consent. Material changes require renewed consent.
Delivery and retention
While an opted-in app is open, it sends at most one acknowledged summary per day, starting at least 24 hours after consent. Failed deliveries retry no more than hourly. Unsent counts expire after seven days, including when you next open the app. No background sender runs after the app closes.
Amito combines accepted counts into daily totals by app, metric, version, operating system and architecture. Totals are retained for 12 calendar months. Raw report bodies are not archived. Random report IDs and payload hashes are retained for eight days for retry handling.
Daily database backups have a seven-day retention schedule. A backup can therefore contain information for up to seven additional days after it expires from the live database. Object-storage expiry runs asynchronously; deletion can take longer than its scheduled expiry. Restores undergo retention cleanup before use.
Recipient and infrastructure
Summaries are sent over HTTPS to reports.amito.dev, operated by Jan Arvin Mito (Amito) on a privately managed VPS. Cloudflare R2 stores private database backups. GitHub provides sign-in for the owner’s dashboard; app users do not sign in or send reports to GitHub.
The receiving infrastructure necessarily sees connection metadata such as your IP address. The reporting design excludes IP addresses, user agents and report bodies from its database and collector request logs. Temporary connection information may be used in memory to limit abuse. The feature remains disabled until the deployed handling is verified; it is not described as anonymous.
Website download handoffs
When a verified installer becomes available, the website may count requests handed to its download destination. The reporting event contains only the release identifier and a random retry receipt. It does not forward visitor cookies, IP addresses, referrers or user agents. A counting failure does not prevent downloading.
Handoffs are not completed downloads or installations, and repeated requests or bots can affect counts. These server-side totals are separate from optional in-app sharing and any existing website visitor analytics.
Why collect totals?
They help Amito understand which tools and outcomes receive use. They cannot measure exact user counts, individual retention or satisfaction. There is no user profile with which to locate one person’s contribution after aggregation.
For questions, corrections or privacy requests, contact mito.jan.arvin@gmail.com.