Privacy Policy

1-bit ("the app") is an iOS audio player developed by Arsenie Coseac. The short version: used on its own, or with a bridge you run, 1-bit sends us nothing — no analytics, no advertising, no tracking, no account. That has not changed. 1-bit Cloud is a separate, opt-in choice: ask us to host a library and we do run a server for you, so your music lives on a server we run in Switzerland, and so do the playlists, favourites and listening history the app backs up to it. We hold them to give them back to you — you can export everything and delete everything from inside the app — but we do hold them, and saying otherwise would be a word game. The other first-party servers are the optional Atlas metadata service (off by default), which serves public music information and, purely to prevent abuse, keeps your install's attestation key and the IP it was last seen from — not your identity, never used for tracking, and with no record of what you look up — and the optional demo music library at bridge.1-bit.app (added only if you tap "Add Demo Bridge"), a read-only server of generated sample music that collects nothing about you. If you never create a 1-bit Cloud library, nothing in this paragraph about it applies to you. Details below.

Regulatory note

In its default configuration 1-bit collects no personal data. 1-bit Cloud (v2.0) is the one exception, and it is opt-in: if you ask us to host a library, we do hold your music and your account — see "1-bit Cloud" below. If you turn on the optional Atlas metadata service (off by default — see below), a server operated by the developer records, for fraud-prevention and rate-limiting only, your install's attestation key and the IP address it was last seen from — not linked to your identity and never used for tracking, stored as a most-recent value rather than accumulated into a history, and deleted when the device's access is revoked or expires. Aside from that, 1-bit collects no personal data. This minimal-data design aligns with the GDPR (EU), the Swiss Federal Act on Data Protection (FADP), and the CCPA (California); the lawful basis for the Atlas anti-abuse data is the developer's legitimate interest in preventing abuse, and you can request its deletion (see "Your rights"). For 1-bit Cloud the lawful basis is performance of the contract you enter when you create a library — we hold what we need to give it back to you — and you can export or delete all of it from inside the app.

Data stored only on your device

• SMB credentials (server address, username, password) are saved in the iOS Keychain so you don't have to re-enter them. They never leave your device.
• Bridge tokens and TLS fingerprints for any 1-bit Bridge servers you have paired live in the iOS Keychain alongside the SMB credentials. They never leave your device.
• Music library metadata (track, album, artist, playback state, playlists) is kept in a local database on your device.
• Cached artwork and artist images are kept in the app's local Caches directory.
• Local files source (v1.1): files you place in the app's Documents folder play through the app's built-in local source. Nothing about them leaves your device.
• Offline downloads (v1.4): tracks you choose to download for offline playback are stored in the app's private Application Support folder. These files are hidden from the Files app, excluded from iCloud backup so they don't consume your iCloud quota, and removed when you delete the download, delete the share, or uninstall the app. They never leave your device.
• Diagnostic logs (v1.4, corrected v1.9): the app keeps a rolling record of recent diagnostic log lines, viewable in Settings → Diagnostics → Logs. It is held both in memory for the live view and in a small file in the app's private Application Support folder, so a problem that happened before the app restarted is still diagnosable. The files are size-capped (about 4 MB total across two rotating files), excluded from iCloud backup, removed when you uninstall the app, and cleared whenever you tap Clear logs on that screen. They stay on your device unless you explicitly export them from there (for example, to attach to a support email); an export includes your device model and app version, and can cover earlier app sessions.
• Device backup identifier (v1.5): if you turn on playlist backup or playback-history upload for a bridge (both off by default — see below), the app generates a random identifier so the bridge can keep each device's backups separate. It is stored in the iOS Keychain, is not linked to your Apple ID or any advertising identifier, is not shared with anyone other than the bridge you run, and is sent only to that bridge.
• On-device performance metrics (v1.5): the app keeps a small daily summary of its own performance (CPU/energy use, memory, playback runtime) from Apple's on-device MetricKit so it can be shown in the in-app diagnostics screen. This summary never leaves your device.
• Atlas attestation key (v1.7): if you turn on Atlas metadata enrichment (off by default — see below), the app creates an Apple App Attest key in your device's Secure Enclave so it can prove to Atlas that requests come from a genuine, unmodified copy of the app. The key's identifier is stored in the iOS Keychain. By Apple's design this key cannot be used to track you across apps and is not linked to your Apple ID or any advertising identifier.
• CarPlay recent searches and recently-played (v1.7): a short list of your recent searches and recently-played albums and playlists is kept on your device so CarPlay can show them again. It never leaves your device.
• Your own music folders (v1.8): you can now point 1-bit at music folders anywhere on your device or on an attached drive, instead of copying files into the app. When you pick a folder, iOS grants the app access to it and the app saves a bookmark — a reference iOS issues so it can reopen that same folder after a restart — alongside the source's other settings. The bookmark identifies a location on your device; it is not a copy of your files, and it never leaves your device. Removing the source removes the bookmark. Nothing about the folder or its contents is sent anywhere.
• Automatic offline cache (v1.8, off unless you enable a caching feature): if you turn on either of the optional offline features described below, the app keeps a temporary copy of recently-played or upcoming tracks in its private storage so playback starts instantly and survives a network drop. The cache is size-capped, reclaims itself oldest-first, is kept separate from the downloads you choose explicitly (so it can never delete those), and is removed when you uninstall the app. It never leaves your device. With both features off — the default — nothing is written to it.
• 1-bit Cloud session (v2.0, only if you create a cloud library): the token your device uses to talk to your hosted library is stored in the iOS Keychain, in its own namespace, with the same protection class as the bridge tokens above — available after first unlock, this device only, never synced to iCloud and never restored to a different device. It is removed when you delete the account and when you remove the source. The server keeps only a SHA-256 of it, so a copy of our database yields no working session.
• Lyrics cache (v2.0): lyrics read from your files' tags, from .lrc or .txt files beside them, from a paired bridge, or (only if you turn that on) from LRCLIB are kept in a small, size-capped cache in the app's Caches directory so they are not parsed or fetched again. It is emptied by Clear caches, removed when you uninstall the app, and never leaves your device.

Network requests the app makes

• SMB connections to the servers you configure. These are used to browse and stream your own music files. Requests only go to the servers you specify.
• 1-bit Bridge connections (optional, v1.1): if you pair a 1-bit Bridge server (a companion server you run on your own machine), the app talks to it over HTTPS with a bearer token and a pinned TLS certificate fingerprint captured at pairing time. On the wire the app sends relative paths, byte ranges, and MusicBrainz IDs — never your account info, device ID, or any third-party identifier. When the bridge handles enrichment, the artist-name lookups described below happen on your bridge server, not from your iOS device. See the bridge's own policy at 1-bit.app/bridge/privacy.
• Local-network discovery (Bonjour + SSDP): the app browses for SMB servers and 1-bit Bridge instances (Bonjour) and, since v1.5, for DLNA renderers such as a Chord 2Go (SSDP multicast on your local network). v1.6 extends the same SSDP discovery to UPnP/DLNA media servers so they can be added as music sources. No data leaves your network.
• UPnP/DLNA media server sources (v1.6): if you add a UPnP/DLNA media server (such as a NAS media server or a Chord 2Go's built-in library) as a music source, the app sends standard UPnP browse requests to that server and streams your music from it over your local network. Requests go only to the server you added; nothing leaves your network and nothing is sent to us or any third party.
• DLNA renderer playback (v1.5): if you choose to play to a DLNA renderer on your network, the app sends that renderer a standard UPnP control message containing the track's metadata (title, artist, album, and similar tag fields) and a link to the audio file on your own 1-bit Bridge — or, from v1.6, on the UPnP/DLNA media server the track came from. The renderer then fetches the audio directly from that server over your local network — the audio does not pass through any server we operate, and nothing is sent to a third party.
• Playlist backup to your bridge (optional, v1.5, OFF by default): if you turn on "Back up playlists to this bridge" for a paired bridge, the app uploads your playlists (names and the list of tracks they contain) to that bridge so they survive a reinstall or move to another device. This goes only to the bridge you run; it is never sent to us or any third party. You can turn it off per bridge in Settings.
• Playback history to your bridge (optional, v1.5, OFF by default): if you turn on "Send playback history" for a paired bridge, the app uploads what you played to that bridge — the track, how long you listened, the audio format, and the output device used. It contains no account or personal identity information and goes only to the bridge you run, never to us or any third party. You can turn it off per bridge in Settings.
• Deezer artist-image lookup (sources other than a 1-bit bridge, optional, OFF by default): if you turn on "Fetch artist images from Deezer" in Settings, the app sends the artist name from your music library to Deezer's public API (api.deezer.com) to retrieve a public artist photo — but only for artists with music on a source other than a 1-bit bridge: an SMB share, a UPnP/DLNA media server, or a folder on this device. 1-bit bridge sources are unaffected by this toggle: their artist images come from the bridge server itself, and the iOS app never contacts Deezer for an artist whose music is only on a bridge. No user identifier, account info, device ID, or other personal data is sent — only the artist's name. You can disable this at any time in Settings. Deezer's own privacy policy: deezer.com/legal/personal-datas.
• Atlas metadata enrichment (optional, v1.7, OFF by default): if you turn on "Enrich with Atlas metadata" for a paired bridge (Sources → its Edit sheet), the app contacts Atlas, a music-information service operated by the developer, to fetch public artist and album information (biographies, descriptions, genres) for the item you are viewing and — when an album's cover is not square — a higher-quality square cover for it. There is no separate switch for the cover art: it is part of that per-bridge setting. On the wire the app sends the MusicBrainz identifier of that item and an access token for these lookups, which Atlas issues in return for an Apple App Attest assertion proving the app is a genuine, unmodified install (where App Attest isn't available, you can paste in a token yourself); the token stays on your device, and your bridge never sees it. The app sends no account, no name, no device identifier linked to your Apple ID or any advertising identifier, and nothing about the rest of your library — the one exception is the separate bulk harvest described next, which stays off unless you turn it on. To prevent abuse and apply rate limits, Atlas keeps a record of your install's attestation key and the IP address and app version it was last seen from; this is not linked to your identity, is stored as a most-recent value (not accumulated into a history), is never used for tracking or advertising, and is deleted when the device's access is revoked or expires. Atlas does not keep any record of which artists or albums you looked up. What comes back is public music metadata, and a copy is cached on your own bridge so your other devices can reuse it without contacting Atlas again. Atlas has no user account. You can turn it off per bridge at any time, which also stops the cover-art upgrades. How Atlas handles requests on the server side is described in the companion policy at 1-bit.app/bridge/privacy.
• Atlas bulk harvest (optional, v1.7, OFF by default): with Atlas enrichment on, the same Edit sheet offers "Bulk-harvest the whole library", which has your bridge fetch that information for your whole library at once instead of album by album. It works only when the bridge's operator has also enabled the harvest on the bridge. When you turn it on, the app mints a second Atlas credential with App Attest — usable only for the harvest's lookups, and expiring on its own — and sends it to your bridge together with the Atlas address and the credential's remaining lifetime. Unlike the access token above, this credential does reach your bridge, which keeps it and uses it while the app is closed; the app renews it while the switch stays on. The bridge then connects to that Atlas server itself and sends it the MusicBrainz identifiers of every artist and release in your library — public catalog identifiers, not file names, folder paths or listening history, though together they do describe which artists and albums your library holds, which is why this stays off unless you choose it. In return it receives biographies, descriptions, cover references and, where one exists, the album's PDF booklet, all of which it keeps on your own machine. If the bridge's operator has also turned on its lyrics option, the bridge uses the same credential to ask Atlas for lyrics for tracks that carry none of their own, sending the release identifier with the track's title, number and duration. Atlas keeps no record of which identifiers it was asked about; the anti-abuse record described above covers this credential too, except that for the harvest's requests the address Atlas sees is your bridge's, not your phone's. Turning the switch off stops the app renewing the credential and asks your bridge to delete the one it holds. A bridge older than version 0.2.1, or one the app cannot reach at that moment, keeps it, and it stays usable until it expires — to be sure the harvest stops at once, turn it off on the bridge. Metadata the bridge has already fetched stays in its cache. The server-side detail is at 1-bit.app/bridge/privacy.
• Automatic mixes on the Home screen (v1.7): the Home screen can show automatic mixes (such as "Drive Mix" and "On Repeat") generated by your own paired bridge from the playback history you chose to share with it (the optional, off-by-default feature added in v1.5). Fetching these mixes is a standard request to the bridge you run; nothing is sent to us or any third party.
• Waveforms and album booklets (v1.8): if the bridge you run has audio analysis or booklets enabled, the app fetches the waveform drawn behind the progress bar, and the PDF booklet shown on an album, from that bridge. These are ordinary requests to the same paired bridge the app already streams your music from — a new kind of content over a connection you already had, not a new destination. Nothing is sent to us or any third party. If your bridge doesn't offer them, the app simply doesn't ask.
• Preloading the next tracks (optional, v1.8, OFF by default): if you turn on "Prefetch upcoming tracks on Wi-Fi" in Settings, the app downloads the next few tracks in your queue ahead of time so playback doesn't stall. It only does this on Wi-Fi while the device is charging, never on cellular, and it fetches from the same source the track came from. Nothing new is sent anywhere — this changes when the app downloads, not what or to whom.
• Favorites backup to your bridge (optional, v1.9, OFF by default): if you turn on "Back up favorites to this bridge" for a paired bridge, the app uploads which tracks and albums you have hearted — as references to those items, not as files — so your favorites survive a reinstall or a move to another device. This goes only to the bridge you run; it is never sent to us or any third party. It works the same way as the playlist backup described above, uses the same random per-device identifier so the bridge can keep each device's backups separate, and you can turn it off per bridge in Settings.
• Caching your smart mixes overnight (optional, v1.8, OFF by default): if you turn on "Cache smart mixes overnight", the app asks iOS to wake it while the device is charging on Wi-Fi so it can download the tracks in your smart mixes for offline listening. iOS decides whether and when to run it; the app may go days without being woken. The downloads come from your own paired bridge over the connection already described above, and nothing is sent to us or any third party. You can turn it off at any time in Settings.
• Lyrics from a paired bridge (v2.0): when a track comes from a 1-bit Bridge you run, its lyrics are read by that bridge from your own files (embedded tags and sidecar files) during the bridge's scan and fetched by the app over the bridge connection you already have. Nothing is sent anywhere else.
• LRCLIB lyrics lookup (optional, v2.0, OFF by default): if you turn on "Search LRCLIB for lyrics" in Settings → Lyrics, the app asks LRCLIB's public API (lrclib.net) for the lyrics of the track you are playing — only when your files and any paired bridge had none — sending that track's title, artist, album and duration. No user identifier, account info, device ID, file path, or other personal data is sent; but because each request names the track being played, LRCLIB (and the content-delivery network in front of it) can see which tracks you play while the switch is on, so leave it off if that matters to you — the app itself keeps no such history. Like any internet server, LRCLIB momentarily processes your IP address to deliver the connection. What comes back is community-contributed text that may contain mistakes; it is kept in the on-device lyrics cache described above and never re-transmitted. You can turn this off at any time in Settings. LRCLIB's website: lrclib.net.

1-bit Cloud (v2.0, optional — you have none of this unless you create one)

1-bit Cloud is a private 1-bit Bridge that we run for you, instead of one you run at home. Everywhere else in this policy "the bridge" is a machine you own and we never see. Here it is ours, and that is the whole difference — so this section describes it separately rather than folding it into the bridge paragraphs above.

What we hold. Your uploaded music, on a virtual machine we rent from Microsoft Azure in its Switzerland North (Zürich) region, with its disks encrypted at rest. The Apple account identifier (sub) that Sign in with Apple gives us — the only thing tying a person to a library. Your library's name, its storage quota and its state. A SHA-256 of each session token, never the token itself, so a copy of our database yields no working session. Any invite code you used, also hashed. The names and timestamps of the devices you sync from. And, because creating the library switches them on, the playlists, favourites and listening history the app backs up (see the next paragraph).

What creating a library switches on, and why we say so here. Adding 1-bit Cloud turns on playlist backup, favourites backup, listening-history upload and artwork enrichment for that source. On every other bridge these default OFF, because that server is yours and defaulting them on costs you nothing either way; on this one the server is ours, so it is a real disclosure and the app states it on the sheet before you sign in. Each is switchable per source afterwards under Sources, and everything they send is covered by the export and deletion described below.

We do not have your email address. The app requests no scopes from Sign in with Apple, so Apple gives us an account identifier and nothing else. If you write to support from your own mail client we obviously see that address, but the service never receives one.

One account, one library, and no field in which to name someone else's. Your library is derived from your session; no route accepts a library identifier. Storage is strictly private per user, there are no sharing features, and files are never deduplicated across accounts — each library is its own dataset. We do not scan, analyse or match your uploaded audio against any catalogue.

What leaves our server. To fetch artwork and artist information, the server sends the artist and album names read from your own files to our own Atlas service, and the artist name to Deezer's public API; cover art is then fetched from Cover Art Archive (Internet Archive) by the release identifier those lookups return, not by name. Never the audio, and never a track title. These lookups go out from the Swiss server, so those services see its address and not yours. Whether the names identify you depends on the files: a commercial album's tags are shared by millions, but an unreleased mix or a personal recording carries tags unique to you, and those go out too — so we describe this rather than claim metadata is anonymous. Acoustic fingerprinting is off. You can turn artwork enrichment off for the source at any time.

Logs. The web front end logs each request, and the service's own output is kept by the system journal. These records include IP addresses, which are personal data. They exist to run and debug the service, are not used for analytics or profiling, and are not linked to your library's contents.

Getting it back, and getting rid of it. Your library's web page has an Export button that returns your playlists, favourites, listening history and device names as a single file — deliberately without any credentials in it. Every music file is individually downloadable, bit-exact, at any time. Delete 1-bit Cloud Account in the app removes the whole thing: the data directory, the storage dataset, the account row and every session. It asks you to sign in with Apple again first, so a stray tap or a stolen session cannot destroy a library. Deletion is immediate and there is no grace period, no soft-delete and no retained snapshot — keeping a copy of something you asked us to destroy would be the opposite of honouring the request. That also means it cannot be undone, which is why we ask twice.

Retention. We do not currently expire your playback history or device registrations; they stay until you delete them or the account. If that changes we will say so here before it takes effect.

Sub-processors. The service runs on a virtual machine we rent from Microsoft, in Azure's Switzerland North (Zürich) region. Microsoft hosts the machine, its disks and its network, so formally it is a sub-processor for everything the service stores — under Microsoft's data-processing terms, and never handed anything beyond what sits on those disks. Our DNS provider (deSEC) and our certificate authority (Let's Encrypt) are named for completeness; neither receives your music.

What we do not do

• We do not collect analytics.
• We do not track you across apps or websites.
• We do not use advertising identifiers.
• We do not sell your data, and we do not share it for advertising or cross-app tracking. The optional requests to Deezer, LRCLIB, Apple, and Atlas described above are limited to delivering the specific feature you turned on.
• We do not run an analytics, advertising, or tracking server, and we never have. We do run an account server for 1-bit Cloud, described in its own section above — it exists to host the library you asked us to host, and for nothing else. If you do not create a cloud library you have no account with us and we hold nothing about you. Atlas serves public music information, has no user account, keeps only anti-abuse data (your install's attestation key and last-seen IP) that is not linked to your identity, and keeps no record of what you look up; the demo library serves read-only sample music and keeps no per-user records at all.
• We do not knowingly collect data from children. 1-bit Cloud requires you to be at least 16; the app itself has no account and no age gate because it collects nothing.

iOS permissions the app requests

• Local Network: required to discover SMB servers, 1-bit Bridge instances, DLNA renderers (v1.5), and UPnP/DLNA media servers (v1.6) on your network and connect to them. v1.5 added the multicast networking capability so the app can find DLNA devices via standard SSDP discovery on your local network.
• Background audio: required to continue playback when the app is in the background or the screen is locked.
• CarPlay (v1.4): the app uses Apple's CarPlay Audio entitlement so it can display your library and Now Playing controls on a CarPlay-equipped vehicle's head unit. The CarPlay surface reads the same on-device library used in the iOS app; no additional information is sent over the network for CarPlay, and what's shown on the head unit (track titles, artists, albums, playlists, artwork) is the same content already shown on your phone.
• Siri & voice (v1.7): the app requests permission to handle Siri media requests so you can ask Siri to play albums, artists, playlists, and downloads from your library by voice — at home, on the Lock Screen, and in CarPlay. Apple's Siri processes your voice under Apple's own terms; the app receives only the resolved request (which album, artist, or playlist you asked for) and plays it from your on-device library. No voice data or new personal data is sent to us or any third party for this feature.
• Choosing your own music folders (v1.8): picking a music folder uses the standard iOS file picker, which asks for no permission and grants the app access only to the folder you chose — not to the rest of your files. v1.8 adds no new iOS permission prompts.
• Motion & Fitness (v1.9, only if you turn on head tracking): spatial audio can keep the sound stage fixed in place as you turn your head. Doing that requires reading the motion sensors in your AirPods, which iOS gates behind the Motion & Fitness permission — so the first time head tracking actually starts, iOS asks. The readings are used only to rotate the audio image as it is played: they are never written to storage, never included in diagnostic logs or exports, and never sent anywhere. They are read only while spatial audio is genuinely running on AirPods, and not at all if you leave head tracking off (it is a separate switch under Settings → Audio) or decline the permission — in which case spatial audio still works, and only the head-locked part is unavailable.

Third-party components

• Deezer public API: used if you enable the optional artist-image lookup described above, and also contacted by the 1-bit Cloud server (not by your device) for artist photos when enrichment is on for that source.
• LRCLIB public API: used only if you enable the optional lyrics lookup described above.
• AMSMB2 (open-source SMB2 client library embedded in the app): does not transmit data to its developers.
• 1-bit Bridge (optional companion server you run on your own machine, not operated by us): see its separate privacy policy at 1-bit.app/bridge/privacy.
• Demo music library (optional server operated by the developer, used only if you add the "Add Demo Bridge" source): a read-only library of generated sample music at bridge.1-bit.app, so you can try bridge features without running a server. It is a 1-bit Bridge running in demo mode: playback-history, playlist and favorites uploads are disabled on the server and their switches are locked off in the app for this source; it registers no devices and keeps no per-user records; and its request logs record what was requested, not who — no client addresses, no accounts. Like any internet server it momentarily processes your IP address to deliver the connection; nothing is kept or linked to you. Remove the source at any time under Sources.
• Apple App Attest (DeviceCheck): used only if you enable Atlas metadata enrichment, to prove the app is a genuine, unmodified install. This is Apple's own anti-fraud service and is governed by Apple's privacy terms; the attestation key it creates is not a cross-app tracking identifier and is not linked to your Apple ID or any advertising identifier.
• Sign in with Apple (used only if you create a 1-bit Cloud library): Apple is the identity provider. The app requests no scopes, so Apple returns an account identifier and no email address. Governed by Apple's own privacy terms.
• Cover Art Archive (Internet Archive infrastructure, contacted by the 1-bit Cloud server, not by your device): supplies cover art for the album names read from your files.
• Atlas (metadata service operated by the developer, used only if you enable Atlas enrichment for a bridge): serves public artist/album information by MusicBrainz ID; keeps only anti-abuse data (attestation key + last-seen IP), not linked to your identity and never used for tracking. Server-side handling: 1-bit.app/bridge/privacy.

Your rights

If you have a 1-bit Cloud library, you can exercise access, portability and erasure yourself and without asking us: Export on your library's web page returns your playlists, favourites, listening history and device names in one file; every music file is downloadable bit-exact at any time; and Delete 1-bit Cloud Account in the app destroys the library, the account and every session immediately. To correct something we hold, or to ask anything else about it, write to the address below.

If you enabled Atlas, the anti-abuse data tied to your install (its attestation key and last-seen IP address) is deleted when that device's access is revoked or when it expires; to request revocation, contact us at the address below.

Otherwise — with no cloud library and Atlas off — the app collects no personal data, so there is nothing for us to access, correct, or delete. To remove locally-stored credentials, metadata, and caches, delete the app from your device.

Changes to this policy

If this policy changes, the updated version will be posted at 1-bit.app/privacy with a new "Last updated" date, and the in-app copy will be updated in the next app release.

Version history

Contact

support@1-bit.app