- See where your storage goes
- Security & Privacy
Sin Clean
Security & Privacy
The five statements on this page come from the in-product privacy notes verbatim; each is paired with a verifiable fact and a verification method you can perform yourself. Promises without factual basis do not appear on this page.
On this page
Five privacy statements with verifiable facts
Statement 1: no data is uploaded. Verifiable fact: apart from your deliberate click on "Check for Updates…" (fetching the update manifest) and the confirmed "Download and Install" (downloading the update package) — both connecting only to blacstar7.github.io — the app process holds no network sockets; network API calls exist only in the update-download implementation file.
Statement 2: scanning is read-only. Verifiable fact: the directory set and file metadata (allocated blocks, inode, link count, size, nanosecond modification time) show zero change before and after scanning; the source contains no write or delete calls.
Statement 3: the only action is moving the items you selected into the system Trash. Verifiable fact: the entire codebase has exactly one system Trash call site and no permanent-deletion entry for user files.
Statement 4: data is kept only on this Mac and can be cleared anytime. Verifiable fact: system health trends are stored in the app's own Application Support directory; Settings can clear them, after which the sample point count is 0.
Statement 5: no telemetry, no crash reporting, no third-party analytics. Verifiable fact: the codebase contains no reference to any telemetry, crash-reporting, or third-party analytics SDK; apart from manual updates there is no network endpoint.
How to verify yourself
Process-level test: without clicking "Check for Updates", get the running app's process ID, then run `lsof -a -p <PID> -i` in Terminal — the output should be empty.
Source search: search the source for network API names (URLSession, URLRequest, dataTask, URLComponents) and for telemetry, crash-reporting, and third-party analytics dependencies and API names. Network API hits should exist only in the update-download implementation file; telemetry-class hits should be 0.
Read-only verification: compare the file listing and `stat` results of the same directory before and after scanning, or search the source for write and delete API names.
Single-action verification: search the source for Trash and permanent-delete API names, and check call-site counts and ownership — there should be exactly one Trash call site.
Local data verification: open "Settings" to see the storage location and current sample point count, click "Clear Trend Data", and confirm the count returns to zero.
Each of these verifications is yours to perform — this page explains methods but does not replace them; the in-product "View Privacy Notes" expands the same facts and methods item by item.
Network behavior list
Only two behaviors touch the network; both are triggered by you, and both connect only to blacstar7.github.io.
Network behavior list 数据表
| Behavior | Purpose | Trigger |
|---|---|---|
| Check for updates | Fetch this channel's manifest.json (with version, size, and Ed25519 signature) | You click "Check for Updates…" on the About page |
| Download update | Download the update package ZIP | After a new version is found, you click "Download and Install" and confirm again |
- No background checks: update checks are triggered purely by clicking; the app does no automatic background checking and no silent retries.
- Update requests allow HTTPS only, with a single-host whitelist; any HTTP redirect (including same-origin) is refused; idle timeout is 30 seconds with no retry.
- Update requests use an ephemeral session with URL cache and cookie storage disabled, so network access leaves no cache or cookies on this Mac.
- This site's domain plays no part in update hosting and does no redirection; the update chain closes within the same origin on GitHub Pages (blacstar7.github.io).
- No telemetry, no crash reporting, no third-party analytics, no silent updates, and no data upload.
注意
Accordingly, this page uses no absolute phrasing that claims zero networking or denies an implemented action: this build does include two network actions triggered by you, and any claim falsified by those two actions is not written.
Permissions (two, both optional)
Permission 1: Full Disk Access is called "Read Protected Directories" in the app; the Notifications permission is called "Send Alerts". Neither is requested at launch or first use.
Permissions (two, both optional) 数据表
| Permission | Why it is needed | What it is used for | What if declined | When requested | How to revoke |
|---|---|---|---|---|---|
| Full Disk Access (in-app name "Read Protected Directories") | Some directories (protected locations such as Mail and Messages) are not readable by any app by default. | Used only to count these directories' capacity into Space Analysis, making statistics closer to real usage. | Everything works without it; protected directories are excluded from statistics, and the UI marks how many directories were not counted. | When scan results contain unreadable directories and you click "Learn How to Grant" yourself. | An in-app deep link goes straight to the Full Disk Access pane in Privacy & Security settings. |
| Notifications (in-app name "Send Alerts") | System health alerts need to notify you at the right moment. | Used only to alert you when disk space is tight, load stays high, memory is under pressure, or battery runs low. | Everything works without it; alerts do not pop up, but evidence cards and trends update as usual. | When you enable any alert category in Settings and the system has not yet granted permission. | An in-app deep link goes straight to the Notifications pane in system settings. |
Additional fact: the probe that checks whether Full Disk Access is granted only performs a read-only readability probe on the fixed protected system path /Library/Application Support/com.apple.TCC — it checks readability only and reads no content.
The Settings page states clearly that both permissions are optional, requested only for the relevant action, and that declining affects no other features.
Local data list and how to clear it
Local data list and how to clear it 数据表
| Data | Exact path | How to clear in the app |
|---|---|---|
| Operation History (cleanup + uninstall combined) | ~/Library/Application Support/SinClean/operation-history.json | "Clear History" on the "Operation History" page (deletes local records only; the Trash is untouched) |
| System health trends | ~/Library/Application Support/SinClean/system-health/trends.json | "Clear Trend Data" in Settings (second confirmation required; rewrites the trend document to zero sample points) |
| Space Change records | ~/Library/Application Support/SinClean/space-change-history.json | "Clear Space Change Records" in Settings (second confirmation required, irreversible; recording restarts from the next successful scan) |
| Space Change salt file | ~/Library/Application Support/SinClean/space-change-salt.txt | Cleared together with Space Change records |
| Ignore List | ~/Library/Application Support/Sin Clean/ignore-rules.json | "Clear All Ignore Rules" in Settings |
| Update rollback log | ~/Library/Application Support/SinClean/update-rollback.log | A locally appended text log — no networking, no upload; to clean it, handle the file at this path manually |
| Update staging | ~/Library/Caches/SinClean/Updates/<UUID>/ (the downloaded file is always named update-package.zip) | The staging directory is emptied automatically when the update flow ends, success or failure |
| Settings (refresh interval, scan scope, performance, etc.) | UserDefaults domain com.sinclean.app | Can be changed back in Settings; "Restore Default Settings" does not clear the Ignore List |
注意
Mind the directory names: the Ignore List lives under ~/Library/Application Support/Sin Clean/ (with a space), while everything else lives under ~/Library/Application Support/SinClean/ — they are not the same directory.
How clearing is implemented: in-app "Clear" rewrites the document as an empty one — it clears data, not the file itself; the verifiable criterion is that sample points are greater than 0 before clearing, 0 after, with no temporary copies left behind.
Leftover paths to check after uninstalling
After uninstalling by dragging the app to the Trash, there are four leftover locations to check.
- ~/Library/Application Support/SinClean/
- ~/Library/Application Support/Sin Clean/ (directory name contains a space)
- ~/Library/Caches/SinClean/
- the defaults domain com.sinclean.app (the local preference domain, viewable with the system command `defaults read com.sinclean.app`; clearing it is likewise done by you with system commands)
Note: in-app "Clear History" never moves or deletes files in the Trash; leftover checking is a filesystem-level operation — confirm before deleting anything yourself.
注意
Deleting leftover directories and the defaults domain is a system-level operation and cannot be undone; confirm you no longer need these records first.
Promises this page does not make
The product maintains a banned-word list for privacy copy: any phrasing amounting to an unverifiable absolute promise voids the statement and is never used on this page. Six kinds of claims are on the list — claims about never leaking, about absolute security, about encryption grades, about being one-hundred-percent safe, about zero networking, and about thorough anonymity.
That includes absolute claims that deny an implemented action: the second screen of the in-product first-run guide says "no networking" verbatim, which conflicts with the fact that this build includes two user-triggered network actions — so this site does not copy that absolute wording.
The hard rule of this page: every statement must pair with a verifiable fact and say how to verify it yourself; no unverifiable promises.
Policy change history
The dates and entries below are taken from the product's bundled changelog (Resources/CHANGELOG.txt) and release records; build 27 is the latest public release package as of 2026-10-12.
Policy change history 数据表
| Date | Change |
|---|---|
| 2026-09-17 | 1.0.0-beta.1 (build 7 series): first-use, permissions, and privacy pages landed; five verifiable privacy statements ship in the package. |
| 2026-09-18 | 1.0.0-beta.2 (build 8): offline core of the update mechanism, plus bundled license and changelog; update check was not yet included in that build. |
| 2026-10-01 | 1.0.0-beta.2 (build 13): wording fixes for privacy notes and Settings status messages. |
| 2026-10-01 | 1.0.0-beta.2 (build 19): notification permission wired for production — before requesting, it explains why it is needed, what it is used for, and what happens if declined. |
| 2026-10-02 | 1.0.0-beta.2 (build 20): fixed status routing after notification authorization requests — no longer always shown as denied. |
| 2026-10-02 | 1.0.0-beta.2 (build 21): fixed Space Analysis coverage wording — uncounted counts are now shown truthfully. |
| 2026-10-03 | Internal release package build 23 (internal channel): signed, notarized, and ticket-stapled internal package. That build's change highlights were never registered in the bundled changelog. |
| 2026-10-12 | 1.0.0-beta.2 (build 27): the Space Analysis page's two-column layout rebuilt (a scan can be started at any window size, result capacity bars adapt to window width); operating direction changed to permanently free + permanently open source (MIT License), with dual-channel public release via the GitHub repo and this site. |
提示
This page matches the bundled privacy notes; the in-product "View Privacy Notes" expands the same facts and verification methods item by item.