Privacy Policy

PicoOSS is a third-party client for Alibaba Cloud Object Storage Service (OSS) on macOS. It connects to storage that belongs to you. It ships with no cloud account and no credentials of its own.

This policy separates three things that are easy to conflate: what is stored on your Mac, what is sent to OSS when you use the app, and what external services you open yourself. "No telemetry" does not mean "no network traffic" — the app's core function is network traffic to your own storage.

1. Telemetry and third-party SDKs

The current application source and its project configuration contain no analytics, advertising, tracking or automatic crash-reporting SDKs, and make no calls to a developer-operated login, file-relay or telemetry service. The app uses Apple system frameworks for its interface, networking, signing, Keychain access and Quick Look.

The app writes unresolved cloud multipart-upload identifiers to the system log (OSLog) for diagnostics. This is not telemetry uploaded to the developer. If you choose to share logs, screenshots or feedback, check them first for account identifiers, object paths and signed links. Your operating system's own diagnostic settings and any external service's handling of data are outside this app's control.

2. Credentials and local account data

• Keychain. Saved AccessKey IDs, AccessKey secrets, optional STS Security Tokens and their expiry information are stored by the Security framework in the macOS Keychain, as separate items keyed by account UUID. These credentials are also held in memory while the app runs, in order to sign requests.
• Ordinary local preferences. UserDefaults holds account UUIDs, aliases, AccessKey IDs, buckets, regions, endpoints, per-bucket connection overrides, creation and last-used timestamps, the active account, and transaction-recovery metadata, along with appearance, transfer and interface settings. An AccessKey ID and connection parameters can identify your resources and should not be treated as wholly non-sensitive. The current metadata encoding does not store the secret or the STS token.
• Migration and recovery from older versions. When older-format account data is found, the app attempts to migrate it to the separated metadata/Keychain structure. If a write or verification fails, the old data or a Keychain recovery copy is retained so that the only copy of a credential is not destroyed. It is not possible to guarantee that a historical installation with a migration fault has had all old-format plaintext removed. If the interface reports a storage problem, follow the prompts and retry rather than manually clearing recovery records.
• Local retention. Account data is kept after you save it, for later use. There is no fixed-day automatic deletion and no automatic rotation of cloud credentials.

3. What OSS communication sends, and to whom

OSS data requests travel over HTTPS directly from your Mac to the OSS endpoint configured for your account. Automatic discovery uses Alibaba Cloud's official service and regional nodes; per-bucket and per-object operations use the official node for the bucket's region, or a custom endpoint or CNAME that you configure. Domain format validation does not prove that a custom domain is controlled by Alibaba Cloud or by you — only use configurations you trust.

• The AccessKey secret is used to compute OSS V4 signatures locally. The current request construction does not send the secret as a request field.
• The AccessKey ID, the signature and signature time or expiry are sent to the request destination. When STS is used, the Security Token is also sent, in a request header or as a query parameter of a presigned URL.
• Listing, previewing, downloading, uploading, copying, moving and deleting send the bucket, object key, query parameters, object metadata or file content as appropriate, and receive listings, files and server error information in return. Uploaded content is stored in the OSS resource you select; previews also require downloading content.
• Presigned links and account-configuration QR codes are generated locally; generating them requires no QR-code server. Opening a file link does contact its destination.

The operator of OSS or of your custom endpoint receives these requests and can also see network connection information such as your source IP. Their logging, billing, retention and data handling are governed by them. This app does not delete those server-side records when you delete a local account. Connections and file transfers may incur request, storage or traffic charges on your cloud account.

4. Account configuration sharing and file sharing

Account configuration sharing produces a picooss://import link, text or QR code containing the alias, AccessKey ID, bucket, region, endpoint and per-bucket connection overrides.

The share sheet includes the account's AccessKey secret in the link by default (and, for an STS account, the Security Token and its expiry), so that the recipient can import and connect without typing anything. In that mode the link is equivalent to the account credential — anyone holding it can connect and use the account. Base64 is not encryption, and the link can linger in chat history, the clipboard, a QR-code screenshot or browser history. The share sheet states this risk and offers a switch to turn it off; with the secret excluded, the link carries configuration only and the recipient supplies the secret themselves, which is safe to send over ordinary channels.

Whether or not the secret is included, the recipient should verify the connection destination, especially a custom endpoint or CNAME. If a link containing the secret reaches the wrong person, rotate that AccessKey in the Alibaba Cloud console and verify the rotation took effect.

File sharing produces an authenticated OSS V4 presigned download URL, which is different from account-configuration sharing. Anyone holding it can reach the object without entering the secret, as long as the link is valid, the credential is valid, the object exists and server-side permissions allow it; with STS the link also carries the token. Copying it to the clipboard, into a QR code, a chat, a browser or feedback material can all widen its exposure. Signing out, deleting the local account or closing the share window does not actively revoke URLs already issued. To limit access quickly, handle object permissions or credentials on the OSS/RAM side and verify the effect.

5. Download directory, bookmarks and preview cache

User files and directory authorisation

Uploading reads files or directories you select or drag in. Downloads go to the system Downloads folder by default, or to a custom directory you choose in Settings. A custom download directory's path and its security-scoped bookmark data are stored in a separate local UserDefaults suite (com.picooss.download-directory) so the app can try to restore access later. They are not uploaded as OSS request fields.

"Restore default" in Settings removes the custom directory path and bookmark record, so later downloads return to the default directory. It is not a system-wide permission revocation or a file deletion: it does not delete files you already downloaded, and an operation already started may still hold an access lease. If a bookmark becomes invalid or authorisation fails, you must choose the directory again. The source declares the corresponding sandbox entitlements; the actual authorisation boundary still has to be verified in a properly signed sandboxed build.

Quick Look cache and retention

• The preview cache currently lives under the app's available user cache directory, in PicoOSSPreviewCache-v2. It is not the content-hash cache in NSTemporaryDirectory described by older documentation.
• Cache names are hashed from identity information: account UUID, bucket, endpoint, region, object key, and the ETag (or size and modification time when the ETag is missing), with a restricted set of extensions preserved. The hash-based naming does not encrypt file content, and is not a hash of the file content itself.
• The current cache budget is 256 MiB. Loading a preview evicts evictable entries in least-recently-used order. Objects known to be too large are refused for preview; when the size is unknown a more conservative download budget is used. This is an implementation strategy, not an absolute ceiling on all of the app's temporary files or disk usage.
• Closing a preview, switching account or switching directory releases the active preview state, but does not guarantee immediate deletion of cache files. There is no day-based expiry and no in-app "clear preview cache" action; if you stop previewing, cached files may remain until the system or you clean them up.
• To clean up manually, quit the app first and make sure you only touch PicoOSSPreviewCache-v2 inside that app's cache directory. Do not remove account recovery data or your download directory. Caches from older versions and files left behind by an abnormal exit are not covered by a comprehensive cleanup guarantee.

Downloaded files are ordinary local files that you keep. They are not deleted automatically when you sign out, delete an account, clear the preview cache or restore the default download directory; you manage them yourself.

6. Sign-out, account deletion and withdrawing cloud access

Signing out keeps the local account record, so you can switch back later. Deleting an account in Settings requests removal of that account's local metadata and Keychain credential. If the store fails, you may need to retry or recover, and an error message should not be read as a completed deletion. Deleting a local account is not the same as deleting your Alibaba Cloud account, buckets, cloud files, previous versions, incomplete multipart uploads, preview cache or downloaded files.

This app does not close cloud service accounts, revoke RAM permissions or rotate AccessKey or STS credentials. To withdraw cloud access, use the Alibaba Cloud console or the appropriate service provider's administrative channel. Uninstalling the app should not be treated as proof that all Keychain items and local data have been deleted.

7. External links and support

The app's help, privacy policy and support links contact this website when you open them, and the file-sharing interface lets you open the URLs it generates. It is therefore not accurate to say that all network access from the device goes only to OSS. External sites may log visits, use cookies or process information you voluntarily submit, under their own privacy policies.

• Support and general feedback: the support page, or email support@ronn.fun.
• Never send AccessKey secrets, STS tokens, working presigned URLs or private file contents through any support channel.

8. Basis and scope of this policy

This policy reflects the behaviour of the current app source, including credential storage, account management, request signing and the preview cache. A source audit is not a substitute for runtime packet capture, deletion verification, acceptance in a properly signed sandboxed build, or App Store privacy-label review. Where this policy describes something that still has to be verified in a signed build, it says so.

If you have any questions or concerns about this Privacy Policy, please reach out via our Support page.