What AeroSpork stores, what it sends, and what this website sees. Short, because there is not much of it.
AeroSpork contains no analytics SDK, no crash reporter, and no usage tracking. It makes no network request of its own. The only outbound connection it can make is the update check described below, and that is off until you turn it on.
Managing windows is only possible through the macOS Accessibility APIs, which is why AeroSpork asks for that permission. It is a broad one: while it is granted, AeroSpork can read the title and owning application of every window on your Mac, and move them.
It uses that to lay windows out and to match your window rules. None of it is transmitted anywhere, stored beyond what is described below, or shared with anyone.
~/.aerospork.toml or under
$XDG_CONFIG_HOME — whichever you use. The settings window edits this file in
place..pre-v2 copy of a config written in the older schema, kept when the file is
migrated to the current one.~/Library/Caches/com.wbs.aerospork/workspace-memory.json, readable only by your
user account. It records which workspace each open window was on, along with the bundle
identifier of its application and an identifier for the monitor the workspace was on, so a
restart does not scatter your layout. It holds no window titles and no document contents.
Deleting it costs you one restart's worth of window placement.All of it stays on your Mac. Uninstalling the app leaves these files behind; delete them if you want them gone.
Automatic update checks are off when you install AeroSpork. Nothing is requested until you either allow them or choose Check for Updates… yourself.
When a check does run, it is an ordinary HTTPS request to aerospork.app for a small
file listing the current version. Like any web request, it necessarily tells this server your IP
address, the time, and a user-agent string naming the app and its version. That is the whole of it:
AeroSpork does not send a system profile, a machine identifier, or anything about your windows,
configuration, or the applications you run. Sparkle, the update framework, can send a hardware and
software profile — that feature is not enabled here.
If an update is available, the download comes from GitHub, and GitHub sees that request the same way any download host would.
These pages are static files on Azure Static Web Apps. Nothing is loaded from another host — no
third-party fonts, images, scripts, embeds or trackers — there are no cookies, and nothing follows
you between visits. That is not only a promise: the site sends a
Content-Security-Policy of default-src 'none' that permits no other
host anywhere — every allowance is 'self', plus inline styles on the documentation
pages, whose generator embeds its stylesheet in the page. Your browser refuses any off-site
request this site might make, including one added by mistake.
The only script on the site is a few lines on the front page that put the install command on your clipboard when you click the copy button. It sends nothing anywhere, and you can read it.
Azure receives the requests that serve these pages, which as with any web host includes IP addresses. That is infrastructure logging outside our control, and it is not collected, read, or combined with anything by this project.
AeroSpork can run shell commands you put in your own configuration, through
exec-and-forget and the event callbacks. Those are your commands, doing whatever you
wrote them to do, and anything they send is between you and them. Treat a configuration file from
someone else the way you would treat a shell script from someone else.
If this ever stops being accurate, the page changes with the release that made it inaccurate. Its history is in the repository, so you can see exactly what changed and when.