Legal

Master terms for excelano.com and its applications. Last updated September 5, 2026.

Terms of Service

1. About these terms

These Terms of Service ("Terms") govern your access to and use of excelano.com and any application operated by Excelano LLC ("Excelano," "we," "us"). By using the site or any Excelano application, you agree to these Terms. If you do not agree, do not use the site.

2. Who we are

Excelano LLC is a Texas limited liability company based in Houston, Texas. Excelano provides technology consulting services and operates one or more web applications under its own domains.

3. What this site provides

excelano.com is an informational site describing Excelano's services, work history, and contact information. The site is provided for general information only. Nothing on the site is an offer to provide services, and use of the site does not create a consulting, professional, or contractual relationship. Consulting engagements are governed by a separate written agreement.

4. Acceptable use

You agree not to use the site or any Excelano application to: violate any law or third-party right; transmit harmful code; attempt to interfere with, probe, or disrupt the site's operation; access accounts or data you are not authorized to access; or scrape, harvest, or aggregate content for resale. We may suspend or terminate access for any conduct that, in our reasonable judgment, violates these Terms.

5. Intellectual property

Content on excelano.com, including text, graphics, logos, and code, is owned by Excelano or its licensors and is protected by intellectual property law. You may view and link to public pages. You may not copy, modify, distribute, or create derivative works from the site's content for commercial purposes without prior written permission. Third-party trademarks belong to their respective owners; their appearance on the site does not imply endorsement.

6. Application-specific terms

Excelano operates separate applications (for example, xinglet.com) each with its own legal page. Those application-specific terms incorporate these master Terms by reference and add provisions specific to that application, including how user accounts work and what user content the application stores. Where the application-specific terms and these master Terms conflict, the application-specific terms control for use of that application.

7. Disclaimer of warranties

THE SITE AND ANY EXCELANO APPLICATION ARE PROVIDED "AS IS" AND "AS AVAILABLE," WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT. Excelano does not warrant that the site will be uninterrupted, error-free, secure against every threat, or that defects will be corrected.

8. Limitation of liability

TO THE FULLEST EXTENT PERMITTED BY LAW, EXCELANO AND ITS MEMBERS, OFFICERS, AND CONTRACTORS WILL NOT BE LIABLE FOR ANY INDIRECT, INCIDENTAL, CONSEQUENTIAL, SPECIAL, OR PUNITIVE DAMAGES, OR FOR LOST PROFITS, LOST DATA, OR LOSS OF GOODWILL, ARISING OUT OF OR RELATED TO YOUR USE OF THE SITE OR ANY EXCELANO APPLICATION, EVEN IF EXCELANO WAS ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Excelano's total aggregate liability arising out of or related to the site or any free-to-use application will not exceed one hundred U.S. dollars ($100). For paid services, liability is governed by the applicable written agreement.

9. Indemnification

You agree to indemnify and hold Excelano harmless from claims, damages, and expenses (including reasonable attorneys' fees) arising out of your use of the site or an Excelano application, your violation of these Terms, or your violation of any third-party right.

10. Changes to these Terms

Excelano may update these Terms at any time. The "Last updated" date above reflects the current version. Material changes will be announced on the site or by email to registered users where applicable. Continued use of the site after changes take effect constitutes acceptance of the updated Terms.

11. Termination

You may stop using the site at any time. Excelano may suspend or terminate access to the site or any application at any time, with or without notice, for any reason, including suspected violation of these Terms. Provisions that by their nature should survive termination, including intellectual property, disclaimers, limitations of liability, indemnification, and governing law, will survive.

12. Governing law and venue

These Terms are governed by the laws of the State of Texas, without regard to its conflict-of-laws principles. Any dispute arising out of or related to these Terms or use of the site will be resolved exclusively in the state or federal courts located in Harris County, Texas, and you consent to the personal jurisdiction of those courts. The United Nations Convention on Contracts for the International Sale of Goods does not apply.

13. Miscellaneous

These Terms, together with any application-specific terms and any separately signed written agreement, are the entire agreement between you and Excelano regarding the subject matter. If any provision is found unenforceable, the remaining provisions remain in effect. Failure to enforce a provision is not a waiver of future enforcement. You may not assign these Terms without Excelano's written consent; Excelano may assign these Terms in connection with a sale, merger, or reorganization.

Privacy Statement

1. What this statement covers

This Privacy Statement describes how Excelano LLC handles information collected through excelano.com. Excelano applications (for example, xinglet.com) have their own privacy statements that describe the data those applications collect and store; see the application-specific legal page for details.

2. Information collected on excelano.com

Excelano.com is primarily an informational site. The only information you actively provide is through the contact form, which collects your name, email address, an optional company name, and the message you write. If you do not submit the contact form, the site collects only the standard request data described below.

The web server records request data for security and operational purposes: IP address, timestamp, user-agent string, requested URL, and HTTP response status. For contact-form submissions, the server also logs the timestamp, source IP, and the name, company, and email address you provided, alongside a delivery status code.

The site uses your browser's sessionStorage to remember which hero variant and photo were shown when you first arrived, so they do not change as you navigate. This data stays in your browser, is cleared when you close the browser, and is not transmitted to Excelano.

3. How information is used

Information you submit through the contact form is used to reply to your inquiry. Server logs are used to operate the site, diagnose problems, and investigate suspected abuse. Excelano does not use site data for advertising, profiling, or automated decision-making.

4. Third parties

Excelano uses Resend (resend.com) to send transactional email, including replies to contact-form submissions. When you submit the form, the message content and your email address are transmitted to Resend for delivery. Resend's privacy practices are described at resend.com/legal/privacy-policy.

The site is hosted by Namecheap. Standard hosting telemetry (request logs, basic resource metrics) is processed by the hosting provider in the course of operating the server. Namecheap's privacy practices are described at namecheap.com/legal/general/privacy-policy.

Excelano does not use third-party analytics, advertising trackers, social-network pixels, or session-replay services on excelano.com.

5. Cookies

Excelano.com does not set first-party cookies and does not load third-party cookies. The site uses sessionStorage for the variant selection described above, which is browser storage and not a cookie.

6. Data retention

Contact-form submissions are retained in Excelano's email and contact log indefinitely for record-keeping. Server access logs are retained for up to ninety (90) days. You may request deletion of your contact-form record at any time using the address in the Contact section below.

7. Your rights

You may request that Excelano confirm what personal information it holds about you, correct inaccurate information, or delete information that is no longer needed for the purpose for which it was collected. Send requests to the address in the Contact section. Excelano will respond within a reasonable period and will not charge a fee for routine requests. Some information (for example, server logs needed to investigate abuse) may be retained until its operational purpose is served.

8. Children's privacy

excelano.com is not directed to children under the age of 13 and Excelano does not knowingly collect personal information from children under 13. If you believe a child has provided information through the site, contact Excelano and the information will be deleted.

9. Security

Excelano uses HTTPS site-wide and applies reasonable administrative and technical safeguards to protect submitted information. No system is perfectly secure; Excelano cannot guarantee that information transmitted to or stored on the site will remain free of unauthorized access.

10. International users

Excelano is based in the United States. If you access the site from outside the United States, your information is transferred to and processed in the United States, which may have data-protection rules different from those in your country.

11. Changes to this statement

Excelano may update this Privacy Statement at any time. The "Last updated" date at the top of this page reflects the current version. Material changes will be noted on the site.

Applications

Excelano operates the following applications, each with its own legal page that extends the master Terms and Privacy Statement above:

Blick (iOS) — Privacy

Blick is an iOS app that reads from and writes to your Microsoft 365 account on your behalf. This section is the canonical statement of what Blick does and does not do with your data. The companion repository at github.com/excelano/blick is open source so that every claim here is independently verifiable.

What stays on your device

When you ask for your summary, Blick fetches calendar events, unread emails, and Teams chats from the Microsoft Graph API using your account's own credentials. The fetched data is held in memory long enough to render the summary on screen. When you swipe to mark read or flag, Blick also holds the target message ID in memory long enough to issue the write.

The Home Screen widget, the Control Center controls, the App Intents and the Watch companion run outside the app and cannot read its memory, so the summary they show is written to a container on your device that Blick and its own extensions share. That snapshot holds your presence and Out-of-Office state, your unread and chat counts, your next meetings with their subject, time, organizer and join link, and for each message and chat in the summary its sender, subject, preview line, time, and read and flag state. Beside it Blick keeps the senders you have starred, a Teams status you have pinned with the time that pin expires, and the message identifiers it uses to tell a new message from one you have already seen. The snapshot is replaced on each refresh, the rest changes only when you change it, none of it is readable outside Blick, and all of it goes when you delete the app. Your Microsoft sign-in token is held separately, in the iOS Keychain.

None of this is sent anywhere; what leaves the device is the next section.

What leaves your device

Microsoft Graph API calls. When you ask for your summary, Blick issues HTTPS requests to your Microsoft 365 service. These calls go to graph.microsoft.com (and regional equivalents) and login.microsoftonline.com. They carry your access token, which Microsoft uses to identify you, and they return the calendar, mail, and chat data your account has access to. When you act on something, Blick issues the corresponding write to the same destinations. Blick's Home Screen widget and Control Center controls are first-party processes on the same device; when you tap a presence pill in either surface they make the same kinds of calls to the same destinations, using the same token from the device's keychain. Nothing new leaves the device. This is the same traffic that any Microsoft Graph client makes; Blick does not add headers, identifiers, or analytics to it.

Nothing else. Blick makes no other network requests. No analytics, no crash reporting, no telemetry, no usage logging that leaves the device, no third-party SDKs that would. The Xcode project deliberately imports nothing of the sort, which is the point: this is enforced by the absence of code, not by a policy that depends on the developer behaving well.

Writes

Blick writes back to your Microsoft 365 account only in response to an action you take. From email you can mark messages read or unread, toggle the follow-up flag, and send a reply. From the calendar you can RSVP to an invitation (accept, tentative, decline) and remove an event. You can set your Teams presence and status message, turn Out-of-Office automatic replies on or off, and send or mark Teams chat messages. The same presence and Out-of-Office writes are also reachable from the Home Screen widget, from Control Center, and as App Intents that Siri and Shortcuts can invoke. Each write is the direct result of a gesture, a tap, or a voice command, and an optimistic update is reverted if the Graph call fails. Blick performs no writes on its own.

The Microsoft 365 scopes Blick requests reflect exactly that surface: Mail.ReadWrite and Mail.Send for reading and acting on email, Calendars.ReadWrite for the next-meeting view and RSVP, MailboxSettings.ReadWrite for the Out-of-Office toggle, Chat.ReadWrite and Chat.Create for Teams chats, and Presence.ReadWrite for showing and setting your Teams status. Sign-in also uses User.Read and the standard openid, profile, and offline_access.

Across your devices

Your Microsoft sign-in token is never moved, copied, or synced off the device that obtained it. The phone app, its Home Screen widget, and its Control Center controls share one token only because they run on the same device. The Apple Watch companion in this release is a read-only mirror: the phone fetches your status data and pushes it to the watch over Apple's on-device WatchConnectivity transport, which carries no token, and any action you take on the watch is relayed back to the phone for the phone to execute. The watch itself holds no Microsoft token and makes no Graph call. A future opt-in setting may let the watch sign in on its own and keep its own token on the watch, but a token is still never handed from one device to another, never placed on a server, and never synced through iCloud Keychain. This is enforced by how the code is built, not by a policy that depends on the developer behaving well.

What Blick does not collect

Blick does not collect Microsoft 365 content, query history, usage events, screen views, button taps, feature counts, crash reports, performance metrics, diagnostic logs, device identifiers, advertising identifiers, installation identifiers, or anything else. Its App Privacy declaration on the App Store is "Data Not Collected." This document and the open-source repository are the substance behind that label.

One thing outside the app's control

Apple aggregates anonymous crash logs at the iOS level from devices that have Share With App Developers turned on, and surfaces those aggregates to developers in App Store Connect. Blick neither collects this data nor processes it; the repository contains no code that touches it. But Apple may still surface aggregate, anonymized crash signatures to the developer account regardless of what the app itself does. If you do not want any of your device's anonymous crash data shared with any developer, including this one, the iOS-level control lives at Settings > Privacy & Security > Analytics & Improvements > Share With App Developers. Turning it off applies to all apps on your phone.

How to verify the claims yourself

The full source is at github.com/excelano/blick. To check the claims here independently:

  1. Search the project for URLSession. Every network call should target graph.microsoft.com, login.microsoftonline.com, or one of their regional equivalents.
  2. Search for analytics and crash-reporter SDK names: Firebase, Sentry, Crashlytics, Mixpanel, Amplitude, Segment, GoogleAnalytics. None should appear.
  3. Search for print( and os_log( and confirm there are no statements that emit user content.

If you would rather not depend on Excelano's published Azure App Registration at all, see SELF-HOSTING.md.

Updates to this section

This section changes as the design changes. The change history is the git log of PRIVACY.md in the Blick source repository.

Zirbe (iOS) — Privacy

Zirbe is an open-source iOS and iPadOS email client. It connects only to your own mail servers, keeps everything it holds on your device, and sends nothing about you anywhere. This section is the canonical statement of what Zirbe does and does not do with your data. The app is open source so that every claim here is independently verifiable, and the claims are enforced by how the code is built, not by a policy that depends on the developer behaving well. The companion repository is at github.com/excelano/zirbe.

The short version

Zirbe talks to two things and two things only: the IMAP server and the SMTP server you sign in to. There is no Zirbe server, no account to create with us, no analytics, no telemetry, and no third-party SDK. Your mail and your credentials stay on your device. Its App Privacy declaration on the App Store is "Data Not Collected," because the developer collects nothing.

What stays on your device

Unlike a summary tool that reads and forgets, an email client has to remember. So that your inbox opens instantly, works on a train with no signal, and does not re-download the same messages every time, Zirbe keeps a local copy of the mail it has synced. That copy lives in a private SQLite database inside the app's own container on your device, readable only by Zirbe. It holds your messages and their threading, the folders you have opened, cached message bodies and downsampled image thumbnails, and small pieces of local-only state you create in the app, such as which conversations you have pinned and which senders you have blocked. This is an on-device cache of your own mailbox. It is never uploaded, never backed up to any Zirbe service, and never shared with anyone. Signing out erases it: the app tears the database down and rebuilds it empty.

Your sign-in credentials are held separately in the iOS Keychain, device-bound. The email address and the app-specific password you enter are stored there so Zirbe can reconnect, and nowhere else. They are never written to the message database, never copied to another device, and never synced through iCloud Keychain. A credential obtained on one device stays on that device.

What leaves your device

Your IMAP and SMTP servers. When Zirbe syncs, it makes an encrypted connection to the IMAP host you configured and fetches the mail your account already holds. When you send, reply, save a draft, move a message, or set a flag, it makes the corresponding request to your IMAP or SMTP host. These connections carry the credentials you entered, which your mail provider uses to identify you, exactly as any standards-based mail client does. Zirbe adds no headers, identifiers, or analytics to that traffic. It requires transport encryption: TLS is implicit on the standard secure ports and demanded via STARTTLS otherwise, and a connection that cannot be secured fails rather than falling back to plaintext.

Nothing else. Zirbe makes no other network request. There is no analytics service, no crash reporter, no telemetry, no usage logging that leaves the device, and no third-party SDK that would do any of those things. The project imports none of that on purpose. Remote images in HTML mail are blocked by default, so simply opening a message does not reach out to a sender's web server or load a tracking pixel; images load only when you choose to load them.

Writes to your mailbox

Zirbe writes to your mailbox only in response to something you do. You can send and reply, save and discard drafts, mark messages read or unread, flag them, move them between folders, archive them, delete them, move mail to Junk, and block a sender. Each write is the direct result of a tap, a swipe, or a send, carried over the same authenticated connection to your own server. Zirbe performs no writes on its own.

Two features are worth naming explicitly because they touch the wire in a specific way. Blind carbon copy is transport-only: a Bcc recipient reaches the SMTP envelope so the message is delivered to them, but it is never written into a stored header, so the copy stays blind. Reactions (the tapback badges) are sent as ordinary email over your own SMTP: a reaction is a small reply carrying a Zirbe header, so another Zirbe user sees the badge while every other mail client sees a plain readable line. There is no separate reaction channel and no server brokering it.

Contacts

If you grant Contacts access, Zirbe uses it locally and for display only: to show a sender's photo as an avatar, and to suggest matching people as you type a recipient. The lookup happens entirely on your device, the address book is never transmitted, and denying access simply means no avatars and no suggestions. You can still type any address by hand.

Notifications

New-mail notifications are generated on your device. When the background refresh that iOS occasionally grants finds new mail, Zirbe itself posts the local notification. There is no push server, which is also why notifications arrive on the cadence iOS allows a background app rather than the instant a message lands; the app's Settings disclose that plainly. No notification content leaves your device.

What Zirbe does not collect

Zirbe does not collect the contents of your mail, your search queries, your usage, screen views, taps, feature counts, crash reports, performance metrics, diagnostic logs, device identifiers, advertising identifiers, installation identifiers, or anything else. It has no way to, because it has nowhere to send them. This section and the open-source repository are the substance behind the "Data Not Collected" label.

One thing outside the app's control

Apple aggregates anonymous crash logs at the iOS level from devices that have Share With App Developers turned on, and surfaces those aggregates to developers in App Store Connect. Zirbe neither collects this data nor contains any code that touches it, but Apple may still surface aggregate, anonymized crash signatures to the developer account regardless of what the app does. If you would rather no anonymous crash data from your device reach any developer, including this one, the control is at Settings > Privacy & Security > Analytics & Improvements > Share With App Developers. Turning it off applies to every app on your phone.

How to verify the claims yourself

The full source is at github.com/excelano/zirbe. To check the claims here independently:

  1. Search the project for the code that opens network connections. Every server connection targets the IMAP and SMTP hosts the user configured; the app defines no other destination.
  2. Search for analytics and crash-reporter SDK names: Firebase, Sentry, Crashlytics, Mixpanel, Amplitude, Segment, GoogleAnalytics. None appear. The package manifests list only the mail engine (SwiftMail), the local database (GRDB), and the content parser (Klartext), none of which phone home.
  3. Confirm there is no server component anywhere in the repository. There is nothing to self-host because Zirbe has no backend by design: your mail provider is the only server involved, and it is one you already chose.

Updates to this section

This section changes as the design changes. The change history is the git log of PRIVACY.md in the Zirbe source repository.

Slipcase Desktop (macOS, Windows, Linux) — Privacy

Slipcase Desktop is an open-source desktop application for Slipcase containers: a container is one file holding a document of any type together with metadata describing it. Slipcase Desktop opens a container, shows the metadata, lets you edit it, and hands the document to whatever application your computer has registered for that kind of file. It makes no network connection of any kind. This section is the canonical statement of what Slipcase Desktop does and does not do with your data. The application is open source so that every claim here is independently verifiable, and the claims are enforced by how the code is built rather than by a policy that depends on the developer behaving well. The repository is at github.com/excelano/slipcase-desktop.

The short version

Slipcase Desktop talks to nothing. There is no server behind it, no account to create, no analytics, no telemetry, no crash reporting, and no third-party SDK. It reads the file you open and writes where you tell it to. On the App Store its App Privacy declaration is “Data Not Collected,” because the developer collects nothing and has nowhere to put it.

What stays on your device

One line, and it is a folder name. So that the file dialog opens somewhere useful rather than at your home directory every time, Slipcase Desktop remembers the folder the last container you opened came from. That is one path in one file — slipcase-desktop/last-folder, inside the per-application state directory your operating system provides. It records a folder, never a filename, never the contents of anything. Deleting the file removes it and Slipcase Desktop makes a new one the next time you open a container. Nothing else is stored: no configuration directory, no history, no cache of what you have opened, no index.

On Linux, asking what opens a file writes two placeholders. To find out what would open a content file, Slipcase Desktop asks the desktop's own xdg-mime — and that tool answers about a file that exists, not about a name. So Slipcase Desktop briefly creates two empty placeholder files carrying the content file's name in a private temporary folder of its own, asks about them, and deletes the folder before it answers you. The placeholders hold one space and four zero bytes respectively; they never hold your content file. The folder is readable only by your account. macOS and Windows answer the same question from their own registries and write nothing.

A content file you press Open on is written to a private temporary folder, because handing a file to another application means there has to be a file. That folder is created for the running application, readable only by your own account, and removed when Slipcase Desktop exits. If Slipcase Desktop is killed rather than closed, the folder survives until your operating system clears its temporary directory, which is the same for every application that writes a temporary file.

What leaves your device

Nothing. Slipcase Desktop makes no network request. It has no update check, no license check, no analytics service, no crash reporter, and no remote logging. The project imports none of that on purpose, and the dependency list is short enough to read.

Except what you hand to another application. Pressing Open passes the content file to whatever your computer has registered for that kind of file, and from that moment the file is in that application's hands and subject to that application's behavior, not to this one's. That is the point of the button, and Slipcase Desktop does not vet what it hands over, and it makes no judgment about whether opening something is wise. What it does instead is tell you what it found.

What it tells you about a file

If a container arrived from elsewhere — downloaded, or received as an attachment — your operating system records that on the file, and Slipcase Desktop says so on screen. It also marks the content file you extract, so your computer treats it with the caution it gives anything that came from outside rather than opening it as though you had made it yourself. Editing and saving a container keeps the marking. This is the opposite of collection: it is Slipcase Desktop declining to launder a fact your system already knew, which is a property an application handling files people were sent has to have.

What Slipcase Desktop does not collect

Slipcase Desktop does not collect the contents of your files, the names of your files, what you opened, when you opened it, how often, which buttons you pressed, screen views, crash reports, performance metrics, diagnostic logs, device identifiers, advertising identifiers, installation identifiers, or anything else. It has no way to, because it makes no network connection. This section and the open-source repository are the substance behind the “Data Not Collected” label.

One thing outside the application's control

Both stores collect their own figures about installs and, on Apple's platforms, aggregate anonymous crash logs from devices where Share With App Developers is turned on. Slipcase Desktop neither collects that data nor contains any code that touches it, but the store may still show the developer account aggregate, anonymised numbers regardless of what the application does. On macOS the control is at System Settings > Privacy & Security > Analytics & Improvements > Share With Mac Developers; on Windows, under Settings > Privacy & security > Diagnostics & feedback. Either applies to every application, not only this one. A copy installed from the Excelano apt repository or built from source involves no store at all.

How to verify the claims yourself

The full source is at github.com/excelano/slipcase-desktop. To check the claims here independently:

  1. Search the project for anything that opens a network connection. There is nothing: no HTTP client, no TCP or UDP socket, no URL is contacted, and lsof -i against the running application lists nothing at all. What it does open are local sockets, because drawing a window and asking the desktop a question are done that way: on Linux, one to the display server and two to the session message bus, which is how Slipcase Desktop asks whether the desktop is set to light or dark and hears about that setting changing. Both stay on this machine, and what goes over them is a display setting and never your files. The dependency manifest lists a window toolkit, a file dialog, a way to ask the system to open a file, a D-Bus client for that setting, and the container library — none of which reaches the network.
  2. Search for analytics and crash-reporter names: Firebase, Sentry, Crashlytics, Mixpanel, Amplitude, Segment, GoogleAnalytics. None appears. Searching for segment alone does match unicode-segmentation, which splits text into characters and words for the on-screen layout and reaches nothing.
  3. Search for what is written to disk. Three things: the folder name described above, the two placeholders the Linux type question needs, and a content file extracted where you asked for it or into the temporary folder Open uses.
  4. Confirm there is no server component in the repository. There is nothing to self-host, because Slipcase Desktop has no backend by design.

Updates to this section

This section changes as the application changes. The change history is the git log of packaging/privacy-entry.html in the Slipcase Desktop source repository, which is where this text is maintained.

Slipcase Open (macOS, Windows, Linux) — Privacy

Slipcase Open is an open-source tool that makes a Slipcase container behave like the document inside it: double-click a .slpc and the content file opens in whatever application normally handles that kind of file; save there, and the edit is written back into the container. It is the companion to Slipcase Desktop above, which shows a container rather than opening through it. It ships for Linux, for Windows on the Microsoft Store, and for macOS through Homebrew, and this section names what each platform does where it differs. It makes no network connection of any kind. This section is the canonical statement of what Slipcase Open does and does not do with your data. The tool is open source so that every claim here is independently verifiable, and the claims are enforced by how the code is built rather than by a policy that depends on the developer behaving well. The repository is at github.com/excelano/slipcase-open.

The short version

Slipcase Open talks to nothing. There is no server behind it, no account, no analytics, no telemetry, and no crash reporting. Where it is listed on a store, its App Privacy declaration is “Data Not Collected,” because the developer collects nothing and has nowhere to put it. It does write more to your own disk than its siblings do, deliberately, because an edit you make in another application has to survive until it is back inside the container, and everything it writes is listed here.

What stays on your device

A session directory for every container you open. Opening a container extracts the content file into a directory of its own under your per-user state directory: $XDG_STATE_HOME/slipcase-open on Linux, which is ~/.local/state/slipcase-open unless you have set otherwise; %LOCALAPPDATA% on Windows; ~/Library/Application Support on macOS. The directory is readable only by your account. It holds a small record naming the container's path, the content file's name, when the session began and how many times it has been written back, and the content file copy itself in a content folder below that record. The directory lives for the life of the session and is removed when you close it. A session whose process died while the tool was not watching is kept rather than written back on its own, and offered to you on the next launch, because the tool cannot tell a complete save from a half-written one.

That location is a trade, and you should know it. The content file sits outside the temporary directory so that a reboot or a cleaner cannot delete an edit before it has been written back. The cost is that it sits somewhere backup and synchronisation software looks. A content file from a confidential container is in your state directory for as long as its session is open.

A socket, and two files it reads. The first instance opens a Unix domain socket under your runtime directory, which is cleared at logout, so that later double-clicks hand their container to the running instance; on Windows this is a named pipe restricted to your account. Which content file types may be opened, and how much the tool says, come from a machine policy at /etc/slipcase/open.toml and a user policy at $XDG_CONFIG_HOME/slipcase-open/policy.toml. It reads both and writes neither.

Trust marks are carried, not dropped. On Windows and macOS the operating system marks a file that arrived from elsewhere. Slipcase Open carries that mark from the container onto the content file copy, and back onto the container on write-back, and refuses a write-back that would lose it, so a marked container is never replaced by an unmarked one. Linux has no such mark. As with Slipcase Desktop, this is the opposite of collection: the tool declines to launder a fact your system already knew.

What it writes to your files

Every save the watched directory sees is repacked into a new container and swapped over the original in one step, never edited in place, so an interruption cannot leave a half-written container behind. Members of the container the tool does not recognize are preserved. If the container was moved or deleted while the session ran, the tool says so and offers to save the content file elsewhere rather than writing where it used to be.

What leaves your device

Nothing. Slipcase Open makes no network request. It has no update check, no license check, no analytics service, no crash reporter, and no remote logging.

Except the content file, which is the point. The content file is handed to whatever your desktop has registered for that kind of file, and from then on it is in that application's hands and subject to that application's behavior, not to this one's. The allowed list of content file types is a guardrail against mistakes and social engineering, and not a security boundary: a container is a plain ZIP archive and any user can extract it with ordinary tools.

Notifications stay on this machine. On Linux the tool reports and asks through your desktop's own notification service, over the session message bus. A notification names the container or the content file it is about, and your desktop's per-application notification settings govern it as they do any other.

What Slipcase Open does not collect

Slipcase Open does not collect the contents of your content files, the names of your containers, what you opened, when you opened it, how often, crash reports, performance metrics, diagnostic logs, device identifiers, advertising identifiers, installation identifiers, or anything else. It has no way to, because it makes no network connection. This section and the open-source repository are the substance behind the “Data Not Collected” label.

One thing outside the tool's control

Both stores collect their own figures about installs and, on Apple's platforms, aggregate anonymous crash logs from devices where Share With App Developers is turned on. Slipcase Open neither collects that data nor contains any code that touches it, but the store may still show the developer account aggregate, anonymised numbers regardless of what the tool does. On macOS the control is at System Settings > Privacy & Security > Analytics & Improvements > Share With Mac Developers; on Windows, under Settings > Privacy & security > Diagnostics & feedback. Either applies to every application, not only this one. A copy installed from the Excelano apt repository or built from source involves no store at all.

How to verify the claims yourself

The full source is at github.com/excelano/slipcase-open. To check the claims here independently:

  1. Search the project for anything that opens a network connection. There is nothing: no HTTP client, no TCP or UDP socket, and no URL is contacted. On Linux, lsof -i against the running instance lists nothing, and ss -xp shows the one Unix socket in your runtime directory. The dependency manifest lists the container library, a filesystem watcher, a TOML parser, a D-Bus client for notifications, and a command-line parser, none of which reaches the network.
  2. Search for analytics and crash-reporter names: Firebase, Sentry, Crashlytics, Mixpanel, Amplitude, Segment, GoogleAnalytics. None appears.
  3. Run slipcase-open policy. It prints where sessions are kept and which policy files it reads, as this machine resolves them. Run slipcase-open sessions for what is open and what was left behind.
  4. Confirm there is no server component in the repository. There is nothing to self-host, because Slipcase Open has no backend by design.

Updates to this section

This section changes as the tool changes. The change history is the git log of packaging/privacy-entry.html in the Slipcase Open source repository, which is where this text is maintained.

Segler (macOS, Windows, Linux) — Privacy

Segler is an open-source desktop application for reviewing and correcting DocLang documents, the structured markup a converter such as Duckling writes from a PDF or an Office file. It opens a .dclg or .dclx, renders it, validates it, lets you correct what the converter misread, and saves. It makes no network connection of any kind. This section is the canonical statement of what Segler does and does not do with your data. The application is open source so that every claim here is independently verifiable, and the claims are enforced by how the code is built rather than by a policy that depends on the developer behaving well. The repository is at github.com/excelano/segler, and the segler command-line tool in the same repository is covered by the same statement.

The short version

Segler talks to nothing. There is no server behind it, no account to create, no analytics, no telemetry, no crash reporting, and no third-party service. It reads the document you open and writes it back where you tell it to. Where it is listed on a store, its App Privacy declaration is “Data Not Collected,” because the developer collects nothing and has nowhere to put it.

What stays on your device

Nothing between runs. Segler keeps no settings file, no recent-documents list, no remembered folder and no cache. Your undo history lives in memory for the life of the window and is gone when it closes.

Save writes the document you opened, or the path you choose, and nothing else. The write goes to a temporary file that is then swapped into place whole, so an interrupted save leaves the old file as it was rather than half-written. On Linux and Windows that file waits beside the document; on macOS it waits in the place the system provides for a replacement on the document's own volume, because the App Sandbox does not let a program write beside a file you chose. Markup you did not touch is written back byte for byte, including comments and whitespace; an archive's page images and assets are carried across untouched; a document you did not change is not rewritten at all. No backup copy is kept, and nothing is created beside your document except, on Linux and Windows, the file that becomes it.

What leaves your device

Nothing. Segler makes no network request. It has no update check, no license check, no analytics service, no crash reporter, and no remote logging. It hands nothing to another application either: there is no Open button and the window draws no web links. The project imports none of that on purpose, and the dependency list is short enough to read.

What Segler does not collect

Segler does not collect the contents of your documents, the corrections you make, the names of your files, what you opened, when you opened it, how often, which buttons you pressed, screen views, crash reports, performance metrics, diagnostic logs, device identifiers, advertising identifiers, installation identifiers, or anything else. It has no way to, because it makes no network connection. This section and the open-source repository are the substance behind the “Data Not Collected” label.

One thing outside the application's control

Both stores collect their own figures about installs and, on Apple's platforms, aggregate anonymous crash logs from devices where Share With App Developers is turned on. Segler neither collects that data nor contains any code that touches it, but the store may still show the developer account aggregate, anonymised numbers regardless of what the application does. On macOS the control is at System Settings > Privacy & Security > Analytics & Improvements > Share With Mac Developers; on Windows, under Settings > Privacy & security > Diagnostics & feedback. Either applies to every application, not only this one. A copy installed from the Excelano apt repository or built from source involves no store at all.

How to verify the claims yourself

The full source is at github.com/excelano/segler. To check the claims here independently:

  1. Search the project for anything that opens a network connection. There is nothing: no HTTP client, no TCP or UDP socket, no URL is contacted, and on Linux lsof -i against the running application lists nothing at all. What it does open are local sockets, to the display server and to the session message bus, which is how the file dialog is shown and how Segler asks whether the desktop is set to light or dark. Both stay on this machine. The dependency manifest lists a window toolkit, a file dialog, an image decoder for an archive's page images, a D-Bus client for that setting, and the DocLang library, none of which reaches the network.
  2. Search for analytics and crash-reporter names: Firebase, Sentry, Crashlytics, Mixpanel, Amplitude, Segment, GoogleAnalytics. None appears.
  3. Search for what is written to disk. One thing: the document you saved, by way of the temporary file that becomes it. There is no configuration file, no cache and no recent-files list.
  4. Confirm there is no server component in the repository. There is nothing to self-host, because Segler has no backend by design.

Updates to this section

This section changes as the application changes. The change history is the git log of packaging/privacy-entry.html in the Segler source repository, which is where this text is maintained.

Duckling (macOS, Windows, Linux) — Privacy

Duckling is an open-source desktop application that converts documents: Word, PowerPoint, Excel, PDF, HTML, EPUB and some forty other formats, into DocLang, Markdown, docling JSON, a DocLang archive or LaTeX. The converter is docling.rs, the open-source Rust port of IBM's Docling, and Duckling is the window around it. It makes no network connection of any kind. This section is the canonical statement of what Duckling does and does not do with your data. The application is open source so that every claim here is independently verifiable, and the claims are enforced by how the code is built rather than by a policy that depends on the developer behaving well. The repository is at github.com/excelano/duckling.

The short version

Duckling talks to nothing. There is no server behind it, no account to create, no analytics, no telemetry, no crash reporting, and no third-party service. It reads the files you give it and writes the converted result where you tell it to. The layout, table and text-recognition models that read a scanned page ship inside the package, which is why the download is large and why nothing is fetched afterwards: a scanned page is read on your own machine. Where it is listed on a store, its App Privacy declaration is “Data Not Collected,” because the developer collects nothing and has nowhere to put it.

What stays on your device

Nothing between runs. Duckling keeps no settings file, no history of what you converted, no recent-files list and no remembered folder. Close the window and the only trace of a session is the output you asked for. It writes nothing to a temporary directory either: a conversion goes from the source file to the result in memory.

What it writes is the result, where you said. Beside each source file, or into one folder you chose. A bare DocLang document gets its pictures in an assets folder beside it, and a DocLang archive carries them inside. Duckling never replaces an existing file: a name already taken gets a number, so a second report.md becomes report (1).md and the first is untouched.

What leaves your device

Nothing. Duckling makes no network request. It has no update check, no license check, no analytics service, no crash reporter, and no remote logging. The converter library's dependency tree does contain a way to download models over HTTP, and Duckling compiles it out: the models come in the package, and the built application carries no HTTP client. On Windows this was checked against the packaged executable, whose import table names no networking library.

Except what you hand to another application. The preview pane's Open button passes a converted file to whatever your computer has registered for that kind of file, and Show in folder reveals it in your file manager. From that moment the file is in that application's hands and subject to that application's behavior, not to this one's. That is the point of the buttons, and Duckling does nothing else with them.

What Duckling does not collect

Duckling does not collect the contents of your documents, the text the models read off a scanned page, the names of your files, what you converted, when you converted it, how often, which buttons you pressed, screen views, crash reports, performance metrics, diagnostic logs, device identifiers, advertising identifiers, installation identifiers, or anything else. It has no way to, because it makes no network connection. This section and the open-source repository are the substance behind the “Data Not Collected” label.

One thing outside the application's control

Both stores collect their own figures about installs and, on Apple's platforms, aggregate anonymous crash logs from devices where Share With App Developers is turned on. Duckling neither collects that data nor contains any code that touches it, but the store may still show the developer account aggregate, anonymised numbers regardless of what the application does. On macOS the control is at System Settings > Privacy & Security > Analytics & Improvements > Share With Mac Developers; on Windows, under Settings > Privacy & security > Diagnostics & feedback. Either applies to every application, not only this one. A copy installed from the Excelano apt repository or built from source involves no store at all.

How to verify the claims yourself

The full source is at github.com/excelano/duckling. To check the claims here independently:

  1. Search the project for anything that opens a network connection. There is nothing: no HTTP client, no TCP or UDP socket, and no URL is contacted. cargo tree on the repository lists what is compiled in, and the inference library's download feature is not among it. On Linux, lsof -i against the running application lists nothing at all. What it does open are local sockets, to the display server and to the session message bus, which is how the file dialog is shown and how Duckling asks whether the desktop is set to light or dark. Both stay on this machine, and what goes over them is a dialog and a display setting, never your files.
  2. Search for analytics and crash-reporter names: Firebase, Sentry, Crashlytics, Mixpanel, Amplitude, Segment, GoogleAnalytics. None appears.
  3. Search for what is written to disk. One thing: the converted output, with its assets folder where a format has one, at the destination you chose. There is no configuration file, no cache and no temporary file.
  4. Confirm there is no server component in the repository. There is nothing to self-host, because Duckling has no backend by design.

Updates to this section

This section changes as the application changes. The change history is the git log of packaging/privacy-entry.html in the Duckling source repository, which is where this text is maintained.

Tommy Flyleaf (Linux, macOS, Windows, Web) — Privacy

Tommy Flyleaf is an open-source TOML editor: it shows a file as a tree, lets you edit every value by its kind, and saves a file with everything you did not edit left as it was. It runs as a desktop application and as a page in a browser, and this section names where the two differ. It makes no network connection of any kind. This section is the canonical statement of what Tommy Flyleaf does and does not do with your data. The application is open source so that every claim here is independently verifiable, and the claims are enforced by how the code is built rather than by a policy that depends on the developer behaving well. The repository is at github.com/excelano/flyleaf.

The short version

Tommy Flyleaf talks to nothing. There is no server behind it, no account to create, no analytics, no telemetry, no crash reporting, and no third-party SDK. It reads the file you open and writes where you tell it to, and it remembers nothing from one session to the next.

What stays on your device

Nothing but what you save. Tommy Flyleaf keeps no configuration directory, no history, no list of recent files, no cache, and no record of the folder you last opened; the file dialog opens beside the file that is already open, which it knows without writing anything down. The one thing it writes is a save, and a save replaces the file in one step, so an interruption leaves either the old file or the new one, not a half-written one. On Windows and Linux the edited file is written beside the original under a temporary name and renamed over it. On macOS the application runs in Apple's App Sandbox, where your permission covers the file you chose and not the folder around it, so the edited file is staged in the place macOS provides for exactly this, on the same disk as the original, and macOS swaps it in. A read-only file is refused rather than replaced.

On macOS, the open dialog remembers where it was. The Open and Save dialogs are macOS's own, and macOS records their size and the last folder they showed in the application's sandbox container, under ~/Library/Containers/com.excelano.flyleaf. That is written by the dialog and not by Tommy Flyleaf, it holds a folder and never a file's contents, and it is the whole of what the container holds. Tommy Flyleaf itself writes nothing there.

In the browser, the file stays in the tab. The browser version is the same application compiled to WebAssembly and served as static files from excelano.com. Opening a file goes through the browser's own file picker and the contents are read into the page's memory; saving hands the result back to the browser as a download. Nothing is uploaded, because there is nothing to upload to: the page has no server side. The page uses no cookies, no local storage, and no session storage, so closing the tab is the end of it.

What leaves your device

Nothing. Tommy Flyleaf makes no network request. It has no update check, no license check, no analytics service, no crash reporter, and no remote logging. The project imports none of that on purpose, and the dependency list is short enough to read. The web page is served by excelano.com like any other page on the site, and the site's own statement above covers what a web server records when a page is fetched.

The one exception is a link you click. The About box has two links, to this application's page and to its source. Clicking one hands the address to whatever browser your system opens links with, and that browser fetches it the way it fetches anything else you ask for. Tommy Flyleaf does not fetch it, and sends nothing along with it.

What Tommy Flyleaf does not collect

Tommy Flyleaf does not collect the contents of your files, the names of your files, what you opened, when you opened it, how often, which buttons you pressed, screen views, crash reports, performance metrics, diagnostic logs, device identifiers, advertising identifiers, installation identifiers, or anything else. It has no way to, because it makes no network connection.

How to verify the claims yourself

The full source is at github.com/excelano/flyleaf. To check the claims here independently:

  1. Search the project for anything that opens a network connection. There is nothing: no HTTP client, no TCP or UDP socket, and no URL is contacted. What the desktop application does open on Linux are local sockets, because drawing a window and showing a file dialog are done that way there: one to the display server, one to the desktop's own file-dialog service. Both stay on this machine. On Windows there are not even those, and what can be checked there is stronger: packaging/windows/check-imports.ps1 reads the import table of the executable that ships and refuses any library that is not part of Windows. It finds nineteen, every one of them Windows' own, and not one of them is a networking library — no ws2_32.dll, no winhttp.dll, no wininet.dll. A program that cannot resolve a name or open a socket cannot phone home whatever its code says. On macOS the check is the strongest of the three, because it is the operating system's: the application is sandboxed, and codesign -d --entitlements - on the installed copy shows exactly two entitlements, the sandbox itself and read-write access to files you select. There is no network entitlement, so the kernel refuses a connection whatever the code says; lsof -i against the running application lists nothing. The dependency manifest lists a window toolkit, a file dialog, and the TOML library, none of which reaches the network.
  2. Search for analytics and crash-reporter names: Firebase, Sentry, Crashlytics, Mixpanel, Amplitude, Segment, GoogleAnalytics. None appears.
  3. Search for what is written to disk. One thing: the file you save, replaced in one step. On macOS, look in the sandbox container as well; after opening and saving a file it holds the open dialog's own preferences and nothing else.
  4. In the browser, open the page with the network panel of the browser's developer tools showing. After the page and its two files have loaded, nothing further is fetched, whatever you open or save.
  5. Confirm there is no server component in the repository. There is nothing to self-host, because Tommy Flyleaf has no backend by design.

Updates to this section

This section changes as the application changes. The change history is the git log of packaging/privacy-entry.html in the Tommy Flyleaf source repository, which is where this text is maintained.

Odox — Privacy

Odox is a suite of three open-source desktop applications for OpenDocument files: Odox Text for text documents, Odox Grid for spreadsheets and Odox Deck for presentations. Each opens a file, draws it, lets you change what is in it, and saves it back when you ask. None of them makes a network connection of any kind. This section is the canonical statement of what Odox does and does not do with your data. The applications are open source so that every claim here is independently verifiable, and the claims are enforced by how the code is built rather than by a policy that depends on the developer behaving well. The repository is at github.com/excelano/odox, and the xodt, xods, xodp and odox commands in it are covered by the same statement.

The short version

Odox talks to nothing and writes only what you tell it to. There is no server behind it, no account to create, no analytics, no telemetry, no crash reporting, and no third-party service. It reads the file you open, and it writes that file when you press Save, or the file you name when you press Save As, and nothing else. Where it is listed on a store, its App Privacy declaration is “Data Not Collected,” because the developer collects nothing and has nowhere to put it.

What stays on your device

The document, when you save it. A file you open is opened for reading and is not touched until you press Save, and then it is replaced whole by what is in the window. On Linux and Windows the new contents go into a temporary file beside it that is then renamed over it, so a crash mid-write leaves the original as it was; on macOS the file is rewritten in place, because the sandbox permits nothing beside it. No backup copy is kept. Before anything is written, what is about to be written is read back and compared with what is in the window, and a difference refuses the save rather than writing a document that would not come back the same.

One preference, when you change it. The applications keep a single setting, whether a document opens ready to edit, in one small file: odox/settings.toml under your configuration directory (~/.config on Linux, Library/Application Support on macOS, AppData on Windows). It is written only when you change that setting in the menu, so an installation nobody has configured has no file, and it holds that one line. There is no recent-documents list, no remembered folder and no cache. What you were looking at, how far you had scrolled and which sheet or slide you had picked live in memory for the life of the window and are gone when it closes.

The clipboard, when you ask. Selecting text and pressing Ctrl+C puts that text on your clipboard, and each window has a command that copies the whole document or the current sheet as plain text. That is your clipboard on your machine, it happens only when you press the key or the button, and Odox never reads the clipboard except to paste into a text box you are typing in.

What leaves your device

Nothing. Odox makes no network request. It has no update check, no license check, no analytics service, no crash reporter and no remote logging. There is no HTTP client, no socket and no URL anywhere in the dependency tree. It hands nothing to another application either: the windows draw no web links and open nothing.

What it does open on your own machine are the things any window opens: the display server, so there is something to draw on; the session message bus, which is how the file dialogs are shown and how Odox asks whether your desktop is set to light or dark; and your installed font files, read so that a document asking for a typeface gets one. All of that stays on the machine.

What Odox does not collect

Odox does not collect the contents of your documents, the names of your files, what you opened, when you opened it, how often, which buttons you pressed, screen views, crash reports, performance metrics, diagnostic logs, device identifiers, advertising identifiers, installation identifiers, or anything else. It has no way to, because it makes no network connection and writes nothing but the document you save and the one preference you set. This section and the open-source repository are the substance behind the “Data Not Collected” label.

One thing outside the application's control

Both stores collect their own figures about installs and, on Apple's platforms, aggregate anonymous crash logs from devices where Share With App Developers is turned on. Odox neither collects that data nor contains any code that touches it, but the store may still show the developer account aggregate, anonymised numbers regardless of what the application does. On macOS the control is at System Settings > Privacy & Security > Analytics & Improvements > Share With Mac Developers; on Windows, under Settings > Privacy & security > Diagnostics & feedback. Either applies to every application, not only these. A copy installed from the Excelano apt repository or built from source involves no store at all.

How to verify the claims yourself

The full source is at github.com/excelano/odox. To check the claims here independently:

  1. Search the project for anything that opens a network connection. There is nothing: no HTTP client, no TCP or UDP socket, and no URL is contacted. On Linux, lsof -i against a running window lists nothing at all. The dependency manifest lists a window toolkit, a file dialog, a font database, an image decoder for the pictures inside a document, a ZIP reader, an XML parser and a translation catalogue reader, none of which reaches the network.
  2. Search for analytics and crash-reporter names: Firebase, Sentry, Crashlytics, Mixpanel, Amplitude, Segment, GoogleAnalytics. None appears.
  3. Search for what is written to disk. Outside the test suite there are two places: the shell's save, which writes the document you asked it to, and the settings module, which writes the one preference. There is no cache, no recent-files list and no output of any other kind.
  4. Confirm there is no server component in the repository. There is nothing to self-host, because Odox has no backend by design.

Updates to this section

This section changes as the applications change. The change history is the git log of packaging/privacy-entry.html in the Odox source repository, which is where this text is maintained.

Filebase (macOS, Windows, Linux) — Privacy

Filebase is an open-source desktop application for Slipcase containers: a container is one file holding a document of any type together with a short text description of it. Filebase opens a folder of them, runs a query over those descriptions, and shows what answered as rows; selecting a row shows that container's description, and one button hands its document to whatever application your computer has registered for that kind of file. It makes no network connection of any kind. This section is the canonical statement of what Filebase does and does not do with your data. The application is open source so that every claim here is independently verifiable, and the claims are enforced by how the code is built rather than by a policy that depends on the developer behaving well. The repository is at github.com/excelano/filebase.

The short version

Filebase talks to nothing and remembers nothing. There is no server behind it, no account to create, no analytics, no telemetry, no crash reporting, and no third-party SDK. It reads the folder you point it at and writes nothing back to it. On the App Store its App Privacy declaration is “Data Not Collected,” because the developer collects nothing and has nowhere to put it.

What stays on your device

Nothing that outlives the window. Filebase has no configuration file, no recent-folders list, no history of what you have asked, and no cache. It keeps no index and no library of your documents: every query is a fresh scan of the folder, which is why there is nothing stored to go stale and nothing stored to leak. Closing the application leaves your disk as it found it.

A content file you press Open on is written to a private temporary folder, because handing a file to another application means there has to be a file. That folder is created for the running application, readable only by your own account, and removed with its contents when Filebase exits. Where inside it the document lands is decided by the container library rather than by the name recorded inside the container, so a container naming its content file something like ../elsewhere cannot place a file outside that folder. If Filebase is killed rather than closed, the folder survives until your operating system clears its temporary directory, which is the same for every application that writes a temporary file.

What leaves your device

Nothing. Filebase makes no network request. It has no update check, no license check, no analytics service, no crash reporter, and no remote logging. The project imports none of that on purpose, and the dependency list is short enough to read.

Except what you hand to another application. Pressing Open passes the document to whatever your computer has registered for that kind of file, and from that moment it is in that application's hands and subject to that application's behaviour, not to this one's. That is the point of the button, and it is worth saying plainly: Filebase does not vet what it hands over and makes no judgement about whether opening something is wise. What it does instead is show you the document's own description first, and show the content file's name escaped, so that a name written to read backwards cannot disguise what kind of file you are about to open.

What Filebase does not change

It never writes a container. There is no Save in the application and no code path that rewrites one. The description you can read in the pane is drawn by the same editing widget Slipcase Desktop uses, handed a rule that marks every key read-only — so the thing that could edit your file is told not to, rather than merely not being asked. Nothing is ever written beside the container you are reading, including the temporary copy described above. If you want to change a description, Slipcase Desktop is the application that does that.

What Filebase does not collect

Filebase does not collect the contents of your files, the names of your files, what you opened, what you asked, when you asked it, how often, which buttons you pressed, screen views, crash reports, performance metrics, diagnostic logs, device identifiers, advertising identifiers, installation identifiers, or anything else. It has no way to, because it makes no network connection and writes no state. This section and the open-source repository are the substance behind the “Data Not Collected” label.

One thing outside the application's control

Both stores collect their own figures about installs and, on Apple's platforms, aggregate anonymous crash logs from devices where Share With App Developers is turned on. Filebase neither collects that data nor contains any code that touches it, but the store may still show the developer account aggregate, anonymised numbers regardless of what the application does. On macOS the control is at System Settings > Privacy & Security > Analytics & Improvements > Share With Mac Developers; on Windows, under Settings > Privacy & security > Diagnostics & feedback. Either applies to every application, not only this one. A copy installed from the Excelano apt repository or built from source involves no store at all.

How to verify the claims yourself

The repository is public. That it makes no network connection is checkable by reading its dependency list, which names no HTTP client, no analytics library and no crash reporter; on Linux you can also watch it with strace -f -e trace=network and see it open no socket. That it writes nothing is checkable the same way, with strace -f -e trace=openat, or simply by looking for a configuration directory afterwards and finding none. That it never writes a container is checkable by reading src/policy.rs, which is short enough to read in a sitting and is the whole of the rule. The temporary folder and its permissions are in src/main.rs, in the function that makes it.

Umwandler (Windows) — Datenschutz / Privacy

Umwandler wandelt Office-Dateien beim Öffnen nach OpenDocument um. Die Anwendung ist quelloffen, damit jede Aussage in diesem Abschnitt nachprüfbar ist: sie wird nicht durch eine Zusage gehalten, sondern dadurch, wie das Programm gebaut ist. Der Quelltext liegt unter gitlab.opencode.de/excelano/umwandler.

Kurz gefasst

Umwandler sendet nichts. Es gibt keinen Server dahinter, kein Konto, keine Nutzungszählung, keine Telemetrie, keine Absturzmeldung und keinen Dienst eines Dritten. Umgewandelt wird auf dem Arbeitsplatz selbst. Im Store lautet die Angabe zur Datenerhebung deshalb „Keine Daten erhoben“, denn der Anbieter erhebt nichts und hätte auch nirgends hin damit.

Auf dem Arbeitsplatz schreibt Umwandler dagegen durchaus: die umgewandelte Datei, ein Protokoll und, sofern eingerichtet, eine Kopie der Ursprungsdatei. Das Protokoll ist der Punkt, auf den es in einer Behörde ankommt, und steht deshalb weiter unten ausführlich.

Was auf dem Gerät bleibt

Die umgewandelte Datei. Sie entsteht neben der Ursprungsdatei und trägt denselben Namen mit neuer Endung. Liegt die Ursprungsdatei an einem flüchtigen Ort — einem E-Mail-Anhang, einem temporären Ordner — wird sie in einen dauerhaften Ordner geschrieben, weil eine Bearbeitung am Ursprungsort verloren ginge.

Die Ursprungsdatei. In der Voreinstellung bleibt sie unverändert liegen. Die IT kann stattdessen einrichten, dass sie für eine bestimmte Zeit in einen Haltebereich verschoben und danach entfernt wird. Der Haltebereich liegt je Benutzerkonto unter %LOCALAPPDATA%\Umwandler\Quarantaene; neben jeder Datei steht eine Begleitdatei mit dem ursprünglichen Pfad, damit sie zurückgeholt werden kann.

Das Protokoll. Je Vorgang eine Zeile, je Tag eine Datei, rechnerweit unter %PROGRAMDATA%\Umwandler\Protokoll. Eine Zeile hält fest: Zeitpunkt, Kontoname, Pfad der Ursprungsdatei, Pfad des Ergebnisses, Dateiart, Ablageort, verwendete Umwandlungsmaschine samt Fassung, Dauer, Ergebnis und, wo zutreffend, den Grund für ein Überspringen. Wie lange aufbewahrt wird, legt die IT fest; abgelaufene Dateien entfernt Umwandler selbst.

Die eigenen Einstellungen. Was die angemeldete Person selbst ändern darf, steht unter HKCU\SOFTWARE\Excelano\Umwandler. Was die IT festlegt, steht im Richtlinienzweig und gehört der Gruppenrichtlinie.

Ein eigenes LibreOffice-Profil unter %LOCALAPPDATA%\umwandler, damit eine offene LibreOffice-Sitzung nicht gestört wird. Es enthält keine Dokumentinhalte.

Das Protokoll und die Mitbestimmung

Ein vollständiges Protokoll hält fest, welche Dokumente eine namentlich bekannte Person zu welcher Zeit geöffnet hat. Das ist eine Verhaltens- und Leistungsaufzeichnung im Sinne der Personalvertretungsgesetze und in aller Regel mitbestimmungspflichtig. Wir sagen das hier deutlich, weil es vor einer Verteilung mit dem Personalrat zu klären ist und nicht danach.

Für diesen Fall gibt es den Umfang Anonymisiert. Er lässt Kontonamen, Pfade und Klartextmeldungen weg und behält Dateiart, Ablageort, Maschine, Dauer und Ergebnis. Damit bleibt beantwortbar, ob die Umwandlung im Bestand funktioniert, ohne etwas über eine einzelne Person festzuhalten. Das Protokoll lässt sich auch ganz abschalten.

Ist die Ereignisquelle eingetragen, schreibt Umwandler dieselbe Zeile zusätzlich in das Windows-Ereignisprotokoll. Dort gelten die Aufbewahrung und die Weiterleitung, die die IT für dieses Protokoll eingerichtet hat.

Was das Gerät verlässt

Nichts. Umwandler stellt keine Netzverbindung her. Es gibt keine Aktualisierungsprüfung, keine Lizenzprüfung, keine Nutzungszählung, keine Absturzmeldung und keine entfernte Protokollierung. Dienste, die eine Umwandlung im Netz anbieten, wurden erwogen und genau deshalb verworfen: sie würden Verwaltungsdokumente an Dritte übertragen.

Auf dem Gerät selbst startet Umwandler die Programme, die umwandeln und öffnen: Microsoft Office oder LibreOffice, je nachdem, was vorhanden und eingerichtet ist. Übergeben wird ein Dateipfad. Was diese Programme ihrerseits tun, richtet sich nach deren eigenen Bestimmungen und nach dem, was die IT für sie eingerichtet hat.

Bezug über den Microsoft Store

Wird Umwandler über den Microsoft Store bezogen, erhebt Microsoft als Vertreiber die dabei anfallenden Daten — etwa dass eine Installation stattgefunden hat. Das geschieht zwischen der Person und Microsoft; der Anbieter erhält daraus nur eine zusammengefasste Zahl und keine Angaben zu einzelnen Geräten oder Personen. Wer das vermeiden will, baut das Paket aus dem Quelltext und verteilt es selbst; das ist ausdrücklich vorgesehen.

Verantwortlich

Excelano LLC. Fragen zu diesem Abschnitt über das Kontaktformular auf excelano.com. Für die Verarbeitung auf den Arbeitsplätzen einer Behörde ist die Behörde selbst verantwortlich; Umwandler ist dort ein Werkzeug, das sie einrichtet und betreibt.

English

Umwandler converts Office files to OpenDocument as they are opened. It is open source so that every claim here can be checked independently, at gitlab.opencode.de/excelano/umwandler.

Nothing is sent anywhere. There is no server, no account, no analytics, no telemetry, no crash reporting and no third-party service. Conversion happens on the workstation. The store declaration is “Data Not Collected”, because nothing is collected and there is nowhere to put it.

On the device it does write. The converted file, beside the original or in a configured folder for attachments and temporary locations. Optionally the original itself, moved to a per-user holding area at %LOCALAPPDATA%\Umwandler\Quarantaene with a sidecar recording where it came from; by default the original is left alone. A log, one line per operation and one file per day, machine-wide at %PROGRAMDATA%\Umwandler\Protokoll, recording time, account name, source and target paths, file type, location, converter and version, duration, outcome and the reason where a file was skipped. Settings the signed-in person may change, under HKCU\SOFTWARE\Excelano\Umwandler. And a private LibreOffice profile, which holds no document content.

The log records which documents a named person opened. Under German staff-representation law that is a record of conduct and performance, and in a public body it is ordinarily subject to co-determination — something to settle with the works council before deployment rather than after. An anonymised scope omits account names, paths and free-text messages while keeping file type, location, converter, duration and outcome, which still answers whether conversion is working across an estate without recording anything about an individual. Logging can also be switched off entirely.

It makes no network connection at all — no update check, no licence check, no usage count, no crash reporting, no remote logging. Network conversion services were considered and rejected for exactly this reason: they would transmit government documents to third parties. On the device, Umwandler starts Microsoft Office or LibreOffice and hands over a file path; what those programs do is governed by their own terms.

Obtained through the Microsoft Store, Microsoft as distributor collects the data that attaches to that transaction. That is between the person and Microsoft; the publisher receives only aggregate counts, never per-device or per-person detail. Building the package from source and distributing it yourself avoids this, and is expressly provided for.

Controller: Excelano LLC; questions through the contact form at excelano.com. Where the software runs on an authority's workstations, that authority is the controller; Umwandler is a tool it configures and operates.

For legal or privacy questions, including requests under the Your Rights section above, contact Excelano at hello@excelano.com or by mail at:

Excelano LLC
Houston, Texas, USA

For a mailing address suitable for legal service, request it by email and one will be provided.