Privacy Policy

The product and this policy

Dental Clinic Manager is an Arabic-first Windows desktop application for dental clinic operations. This policy covers the desktop application, its optional Google Drive backup connection, and this public information website. The clinic is responsible for the patient and operational information it enters into the software.

The publisher name and privacy contact are listed below. These technical disclosures reflect the desktop source audit and revocation update supplied by the product owner. The application remains in development. These disclosures do not claim Google verification or approval.

Information handled by the application

The application handles patient details and archives, appointments, visits, tooth-specific records, clinical notes and corrections, treatment plans and sessions, patient charges and payments, clinic reports, supplier information, invoices, returns, and related images or PDF attachments entered by the clinic.

When connected to Google Drive, the application obtains a stable Drive account identifier, an email address when Google supplies one, and available storage quota information. It also handles connection state and backup metadata needed to identify the account, display storage information, and upload, locate, download, or manage backups.

It does not request Gmail, Contacts, Calendar, unrestricted Drive access, profile photographs, or Google passwords. Google authorization credentials are handled as described below.

Local storage, encryption, and temporary files

The local clinical database uses SQLCipher, and stored clinical attachment containers are encrypted. Some technical metadata remains readable. The website is not a clinical portal and does not receive or store patient records.

In-app attachment previews can temporarily materialize decrypted content in protected local temporary files. Normal lifecycle cleanup removes these previews, but interruptions or cleanup errors may leave remnants. Original source documents selected by the user outside the encrypted vault remain the user’s responsibility.

Clinical database and attachment content is encrypted and authenticated locally before upload, using XChaCha20-Poly1305 with derived keys. Encrypted .dcb backups are uploaded to the clinic’s own Google Drive in the visible folder Dental Clinic Manager Backups.

Encryption does not cover every backup byte or all Drive metadata. Backup filenames, timestamps, sizes, application identifiers, file identifiers, hashes, and certain technical headers or metadata remain readable outside the encrypted clinical content. Patient names and plaintext clinical records are not included in Drive upload metadata. Encryption does not guarantee protection against every device compromise, loss, or misuse.

Optional Google Drive access and backup scheduling

The clinic chooses whether to connect its own Google account from inside the Windows application. The only requested scope is https://www.googleapis.com/auth/drive.file. It permits working with application-created files or files explicitly made available to the application; it is not unrestricted access to every file in Drive.

The integration creates backups locally, uploads their encrypted clinical content, finds and lists application backups, downloads selected .dcb files for restoration, and manages eligible backups, including permanent retention deletion described below. This website does not perform Google sign-in or the desktop authorization flow.

Automatic backup creation is disabled by default. When enabled, it runs only while the application is open, based on the first eligible daily launch or a configured clinic-local time. After a missed run, the next eligible run creates a current backup; it does not reconstruct a backup for every missed historical day.

Offline creation can succeed locally. Upload is attempted when connectivity permits; failed uploads have bounded retries and may require a manual retry. An enabled schedule or locally created file is not confirmation that a cloud upload succeeded.

Development and Production use separate Google OAuth projects. Backups created by the Development application may not be automatically discoverable by the Production application because Drive authorization and private metadata are application-specific. Changing the project does not automatically delete those files or invalidate their encryption, and seamless cross-project discovery or migration is not promised.

Authorization and local credential protection

Authorization opens in the Windows system browser and returns through a local loopback callback, with PKCE S256 and state verification. The desktop application communicates directly with Google’s OAuth and Drive services.

Access tokens are used temporarily in Rust memory. Refresh tokens are encrypted using Windows current-user DPAPI, and protected connection state is stored locally. No publisher-controlled token relay or cloud backup server was identified in the audited implementation.

This website does not request, receive, or store those tokens or Google passwords. Protect the Windows account and device. For removal of saved credentials and Google permissions, distinguish remote revocation from local-only disconnection as described below.

Google data purposes and Limited Use

Google account and API data is used to provide the visible connection, storage/quota, backup-management, and recovery features described here. It is not used for advertising, profiling, sale, credit decisions, or training generalized AI models.

Dental Clinic Manager’s use and transfer of information received from Google APIs will adhere to the Google API Services User Data Policy, including its Limited Use requirements. No routine human access to plaintext clinical backups was identified in the audited backup workflow. Any exceptional human access or transfer requires a basis permitted by that policy and must stay within the purposes disclosed to the user.

The implementation findings are not a Google compliance certification or approval.

Sharing, service providers, and support

The audited desktop implementation communicates directly with Google. Encrypted clinical backup content, readable backup metadata, and the information required for the authorized connection are processed through Google’s OAuth and Drive services in the clinic’s chosen account. Google operates those services under its own terms and privacy policy. Google authorization alone does not decrypt the clinical content.

No publisher-controlled patient-data backend, advertising SDK, analytics/tracking implementation, automatic crash-report uploader, or routine plaintext patient-record network-upload path was identified in the audited desktop source. No publisher-managed Recovery Key escrow was identified. These are source-audit observations, not guarantees about every operating-system, browser, website, or third-party action.

This static website is hosted on Render at https://dentalclinicmanager.page. Hosting providers process connection information such as IP addresses and request details to deliver and secure the site under their own practices. Website fonts and visual assets are self-hosted; the website source includes no advertising trackers or third-party analytics.

If you email the publisher, the email providers process that correspondence. Use the public contact below for privacy questions or concerns, without sending patient records, tokens, passwords, or Recovery Keys.

Retention, permanent deletion, and disconnection

The default managed backup retention target is 7; the interface offers 1, 3, 7, 14, or 30. The selected count is a cleanup target, not an unconditional hard maximum: pending or failed copies may remain longer. Changing the setting does not guarantee immediate cleanup. Manual .dcb exports are outside managed automatic retention.

Cloud retention cleanup runs after a verified successful upload and applies to eligible backups for the relevant clinic. It can PERMANENTLY delete older eligible cloud backups through Google Drive’s delete API, without moving them to Trash. Do not rely on Trash to recover an automatically deleted backup. Manage independently kept local copies and manual exports separately.

On explicit Google disconnect, the application attempts official Google OAuth revocation over HTTPS. After successful revocation, it removes saved local connection credentials and upload capabilities. A specifically recognized invalid-token response can allow removal of the unusable local credential, but does not establish successful revocation of all permissions.

If revocation times out or fails, credentials are preserved for retry. The interface offers Retry, Cancel, or explicitly confirmed local-only disconnection. Local-only disconnection removes the local connection without revoking permissions on Google’s servers; Google account permissions can be managed separately through the account-connections link below. Remote revocation may affect other installations using the same Google account and OAuth project.

Disconnecting does not delete clinical records, local backups, or previously uploaded Drive backups, and preserves enabled daily local backup scheduling. A disconnection attempt is not a guarantee that Google permissions have been successfully revoked; the outcome depends on the revocation response and the option selected.

Restoration, Recovery Keys, and clinic responsibilities

Google authorization is not sufficient to decrypt an encrypted clinical backup. On another Windows device or profile, a compatible .dcb file and its applicable offline Recovery Key are normally required. Restoration replaces current clinic data with the selected backup.

Losing both compatible local key access and the applicable Recovery Key can prevent recovery. No publisher-managed Recovery Key escrow was identified; do not assume that the publisher can recover a lost key or decrypt a backup. Keep recovery material separately and safely, maintain suitable copies, and test supported restoration procedures.

Clinics are responsible for lawful handling of patient information, accurate records, authorized staff access, device security, passwords, source documents outside the encrypted vault, and recovery material. No software or online service guarantees absolute security or continuous availability.

Your choices and privacy requests

You can choose not to connect Google Drive; local features do not require that optional connection. You can request disconnection within the application, distinguish its remote and local-only outcomes, and manage Google account permissions through Google’s account-connections settings. Existing backup files must be managed separately from connection permissions.

Manage clinic records and local copies with the controls available in the application and your storage. Patients should direct requests about clinic-held medical records to their clinic. The publisher cannot erase or disclose records it does not possess.

Use the official contact below for questions about information the publisher actually holds, such as support correspondence, or to report a privacy concern. Applicable rights and identity checks depend on the circumstances and applicable law.

Website storage and external links

The website uses local browser storage only to remember a language selection when browser settings allow it. Clear that preference through your browser’s site-data controls. The website source installs no analytics or advertising cookies.

External Google, Render, and other links lead to services governed by their own policies. Visiting a link does not upload the clinic’s local database or backups through this website.

Policy updates and contact

The date above is the effective date of this policy. Material changes must be reflected in the policy and relevant in-app disclosures before changed processing begins. Obtain renewed consent before new Google-data uses where Google requires it.

Use the official contact below for questions without sending confidential clinical information or credentials.