Privacy.

Weather

Off unless you turn it on. When it is on, Hangly asks Open-Meteo what the weather is in one city, every thirty minutes, so the charm can take on the sky.

• The city is a name you can see and change in Customize → Appearance. It is guessed from your Mac’s time zone, not from your location.
• Hangly does not use Core Location and asks for no location permission.
• Open-Meteo requires no account and no API key, so there is nothing to identify the request with beyond an IP address, as with any web request.

Anonymous analytics

On by default, and switchable off in Customize → Appearance → Privacy. Turning it off stops collection immediately and discards the installation identifier.

Events are sent to PostHog (US region). They are batched and sent in the background; if the network is unavailable they are queued, and if the queue fills, the oldest are dropped. Nothing about analytics can delay, block or change what the app does.

What is sent

• Installation identifier. A random UUID made on this Mac the first time anything is sent. It is not derived from your hardware, account, network or anything else, and it is used for nothing but counting installs.
• Build and system. App version, build number, macOS version.
• Lifecycle. First launch, launch, quit.
• Charms. Added, removed, reordered, imported, saved, selected. Built-in charms are named; a charm you made is reported as custom.
• Rope. Count changed, style changed.
• Settings. The name of the setting that moved, never its value.
• With every event. How many charms are hanging, which ones, the rope style, and whether analytics is on.

What is never sent

• Your name, email address, or any account. Hangly has no accounts.
• Images you import, or anything about them — not the file, its name, or its size.
• Charms you make. They are reported as the word custom.
• Your location. The weather city is never sent here.
• Where your charm sits, how large it is, or anything else describing your desktop.
• Keystrokes, screen contents, other applications, or what you are doing.

Turning it off

Customize → Appearance → Privacy → Anonymous Analytics. Switching it off stops capture at the source rather than filtering it later, and throws away the installation identifier. If you switch it back on, a new identifier is made, so the two cannot be joined.

Updates

Hangly checks once a week whether a newer version exists, and installs it quietly when there is one. The check is a request for one file on this site, /products/hangly/appcast.xml, and the download that may follow comes from the same place.

• Nothing about you or your copy goes with the check. It carries no identifier, no system profile, and nothing about your charms or settings; the server sees a request for a file, with an IP address, as with any web request.
• Every update is signed, and Hangly installs nothing whose signature does not match the key built into the copy you already have.
• Customize → About has a Check for Updates button for anyone who would rather ask than be asked.

Permissions

Hangly asks for none, and this is a design constraint rather than a happy accident.

The optional full-screen auto-hide reads two things the system publishes to any process: the bounds of on-screen windows, and which applications are holding a display-sleep power assertion — the same information pmset -g assertions prints. Neither needs Accessibility, Screen Recording, or any entitlement. Window names and contents would need Screen Recording, and Hangly reads neither.

Beyond the weather, analytics and the update check, Hangly makes no network requests. It loads no remote content and contacts no other service.

Checking what your copy is doing

Customize → About → Analytics shows, for this machine: whether sharing is on, whether a destination is configured and which, the installation identifier masked, and the last event sent with when it went.

It is in the app rather than behind a developer flag, because the argument for collecting anything at all is that it can be inspected.