Privacy policy

1. Developer and current scope

CardLedger and CardLedger Backup are developed by CredoNomics Investment Solutions (“CredoNomics”). CardLedger is under development and private testing. It has not been publicly launched or approved for production financial use.

This policy describes the current product and Windows backup utility. The public information pages do not ask you to upload financial records or enter Google credentials. Website hosting may process standard request information, such as IP addresses and browser details; this static microsite follows your browser’s light or dark color preference. No analytics or financial-data collection is implemented in these pages. See the CredoNomics website privacy information.

2. Google account authorization and Drive access

When you explicitly authorize CardLedger Backup, Google handles account sign-in and consent. The utility requests only https://www.googleapis.com/auth/drive.file. This permits access to files created by the app or explicitly selected/shared with it through an authorized file-selection flow. Selecting a folder does not automatically establish access to all its existing contents.

The utility can read your account identity, available storage quota and metadata for the authorized folder/files to confirm the destination and integrity. Local diagnostic evidence may contain an account fingerprint, file identifiers, sizes, checksums and verification results. Tokens and passwords are not included in that evidence.

The scope can permit creating, reading, changing or deleting app-authorized files. Current controlled backup operations use newly named encrypted archives and verification readbacks; automatic deletion, overwrite and retention pruning are not enabled. No broader Drive scope is requested.

3. Financial records and encrypted backup data

CardLedger is designed to record card expenses, participant responsibilities, approvals, repayments, settlements and ledger history. Current backup validation uses synthetic financial data. Real financial-data backups and production deployment have not been activated.

Before cloud transfer, the backup archive is encrypted locally using AES-256-GCM. Authorized transfers include the encrypted archive and non-secret integrity/recovery metadata. Backup decryption keys, plaintext database dumps, database passwords and OAuth credentials are not uploaded to Google Drive by this workflow.

Encrypted files remain in the Google Drive account authorized by the operator. Google processes those stored files under its own service terms and privacy policy. Archive filenames, sizes and integrity metadata are visible to the storage provider; encryption does not hide every aspect of a file.

Google API information is used to provide the explicitly authorized backup, verification and recovery workflow. It is not sold or used for advertising. Use and transfer of information received from Google APIs must follow the Google API Services User Data Policy, including its Limited Use requirements.

4. Local OAuth tokens and recovery keys

OAuth access and refresh-token records are encrypted with Windows DPAPI CurrentUser and stored outside the project with restricted Windows permissions. Decryption is bound to the authorized user’s Windows profile. The Desktop OAuth client configuration also stays outside the project with restricted permissions.

Verified encrypted rollback records are retained locally to support controlled credential recovery. The named legacy plaintext token configs have been retired. This does not guarantee forensic erasure from earlier filesystem copies, snapshots or device history.

Backup decryption keys are held separately from Google Drive. Losing that key or the information needed to unlock it can prevent recovery. DPAPI protects local tokens at rest; it does not protect against software running with the authorized user’s access, and loss of that Windows profile can require Google reauthorization.

5. Retention and operational records

Scheduled backups and automatic retention pruning are not activated. A retention selection policy has been prepared, but it is not a promise of automatic deletion or a particular number of available recovery points. Existing encrypted archives remain until the account owner takes a separate deletion action.

Local token records, encrypted rollback records and diagnostic evidence remain on the operator’s PC until an authorized cleanup or replacement. No fixed deletion period or automatic cleanup service is currently offered. Messages you send to CredoNomics may be retained as needed to respond and maintain the related correspondence.

6. Your controls: consent, revocation and deletion

1. Choose the Google account and exact files/folder during authorization. Decline consent if the account, scope or destination is unexpected.
2. Revoke the app’s access in Google Account connections. The utility may then require fresh consent before it can access Drive again.
3. Revocation does not itself delete encrypted archives or local credential records. Delete cloud files through your Google Drive account only after considering which recovery copies you still need.
4. Stop local backup processes before arranging cleanup of local token and rollback records. The current public website has no account-data deletion form or remote credential-cleanup function; contact CardLedger support for revocation, deletion or cleanup guidance during private testing.
5. Keep backup keys and any unlock information independently. Do not send them to CredoNomics when asking for help.

7. Contact and policy updates

For CardLedger privacy questions or current private-testing revocation, deletion and cleanup guidance, contact CredoNomics Investment Solutions at credonomicsinvest@gmail.com. Do not include tokens, authorization codes, passwords, backup keys or financial records in your message.

This policy may be updated as the product develops. Material changes to data handling or Google permissions must be explained before the relevant new use is enabled. The version date above identifies this policy text.