Privacy Policy

1. General Provisions

This Privacy Policy explains how the Aestory mobile application and related Aestory backend services process personal data.

Aestory is intended for specialists who keep work records in the Application and use Aestory services for account access, authentication, installation registration, subscription and entitlement checks, catalog/configuration delivery, and support communication.

The Aestory backend does not store patient cards, patient notes, patient photos, videos, 3D materials, before/after materials, or local backups by default. These working materials are intended to remain in the Application's local storage on the user's device unless the user intentionally exports, shares, uploads, or sends them to another service or to support.

If a specialist uses Aestory to process patient data, that specialist or the organization on whose behalf they act is responsible for having a lawful basis for processing patients' personal data, including patient consent, professional or medical confidentiality, records management, and other applicable legal requirements.

2. Data That May Be Processed

The Aestory backend may process the following categories of account, access, and technical data:

• installation data: installation identifier, platform, app version, installation status, creation time, last seen time, and installation credential state;
• account data: internal account identifier, account status, linked installation history, and timestamps;
• email authentication data: email address, email verification state, verification email send records, send status, and send and cooldown-reset timestamps;
• Yandex sign-in data, when the user chooses Yandex authentication: Yandex account identifier, client identifier, display name, first name, last name, and default email address if provided by Yandex;
• Google or Apple sign-in data, when enabled and chosen by the user: the provider's stable user identifier, optional email address and its verification status, and an optional name included in Google's signed identity token. Apple Hide My Email relay addresses are supported. Matching email addresses do not automatically link accounts from different sign-in methods;
• temporary Apple sign-in security records: installation identifier, a one-way digest of a single-use nonce, and creation, expiry and use timestamps. A nonce expires after five minutes; expired records are removed by authentication cleanup;
• session and token data: server session binding, access token claims, refresh token digest, expiry, rotation, revocation, and replacement timestamps;
• subscription and entitlement data: access tier, feature limits, entitlement status, validity period, transfer availability, installation binding history, and signed lease claims, including the full access end date and the owner's authentication user identifier;
• commercial catalog data shown to the client, such as plans, store offer identifiers, prices, currencies, and catalog revisions;
• administrative and audit data: staff/admin account data, administrative actions, target identifiers, before/after state, reasons, metadata, request identifiers, and timestamps;
• server request logs: request identifier, HTTP method, matched route, response status, and processing duration; Google/Apple token verification failures also record the provider and a technical failure category, without token contents, claim values, or exception text;
• reverse proxy access logs and infrastructure logs, which may include IP address, request URL, user agent, timestamp, response status, and similar technical metadata.

The Application may also process specialist workspace data locally on the user's device, depending on how the user uses the Application: specialist profile data, patient records, visit notes, procedures, photos, videos, 3D files, reminders, local analysis results, exports, and backups.

A signed access snapshot contains the access end date, the requesting account and installation identifiers, and the authentication user identifier of the owner for account-owned Plus. These fields identify the account to which the snapshot applies; they do not authorize use of another account’s subscription. Previously issued offline snapshots may remain valid until their signed expiry.

Active Plus access belongs only to the Aestory account that owns the purchase or account gift and works on its authenticated installations, for App Store and bank purchases. Another account or anonymous session on the same device does not inherit that Plus. Another account’s completed or unfinished purchase does not block a separate personal purchase. Aestory retains the originating installation and connection history for security and commercial history, not exclusive device ownership. Payment history and payment management remain account-specific. An unclaimed administrative device gift remains available only on its originating installation until claimed by an authenticated account; after claim it belongs only to that account.

Aestory does not ask users to enter passport details or bank card details into the Aestory backend. Payments, subscriptions, and app-store purchases may be processed by the relevant app store or payment provider under their own rules.

For payments through Tochka Bank, the backend stores the selected plan, amount and price version, receipt email, auto-renewal choice and consent time, bank identifiers, charge statuses and paid access periods. The receipt email, amount, payment purpose and technical purchase identifiers are sent to Tochka and the connected cash-register service to process payments and issue receipts. Aestory does not store bank card details or card tokens. Auto-renewal requires an explicit choice; cancelling it preserves paid access. Pending purchases must be resolved and auto-renewal cancelled before account deletion. Payment records and receipt email may be retained after account deletion for accounting, support and obligations.

You can cancel an unfinished one-off purchase after the backend checks its bank status. The backend records the cancellation time and an audit event, retains the purchase and bank identifiers and payment link for reconciliation, and allows a new purchase. This cancels the local checkout; a previously saved external bank link may remain payable. A later confirmed payment is still recorded and grants its paid access period. Cancelling a checkout does not issue a refund.

For regional subscription pricing, the Application reads the country of the connected App Store or Google Play storefront and sends the normalized country code and purchase channel to the Aestory backend to select offers. The price may include seller details and other seller information published by the merchant. This optional copy is stored in price-region configuration and translations; changes are recorded in the administrative audit. The price region has a separately configured payment gateway: Tochka for Russia, or the relevant app marketplace for other countries. Russian offers require an explicit RU price; a missing Russian price is not replaced with a Default price. Marketplace payments remain unavailable until their purchase integration is enabled. The store SDK may contact the relevant store to retrieve product prices and subscription periods. The backend retains the country used for a Tochka checkout with the commercial purchase record under the same retention rules. This does not use device location or send patient data. Reading store metadata does not itself start a purchase or enable recurring payments.

3. Purposes of Processing

Aestory processes data to provide and protect the Application and backend services:

• registering and recognizing an Application installation;
• creating accounts and authenticating users by email, Yandex, Google or Apple sign-in;
• sending email verification codes and service emails;
• issuing, refreshing, rotating, and revoking access sessions and tokens;
• linking accounts to installations and protecting account access;
• checking subscription status, issuing signed entitlement leases, and supporting account access across devices;
• providing catalog, pricing, feature, and configuration information;
• operating the administration interface and recording audit events;
• monitoring service health, diagnosing errors, preventing abuse, and securing the service;
• responding to support and legal requests.

Aestory does not use account, installation, patient, or entitlement data for advertising, sale to third parties, third-party ad targeting, or tracking the user across other applications and websites.

4. Legal Bases and Special Categories of Data

If Aestory is used in the Russian Federation, personal data processing must comply with Federal Law No. 152-FZ "On Personal Data" and other applicable requirements. If Aestory is used in the European Economic Area or in relation to persons covered by the GDPR, processing must have an applicable legal basis and be accompanied by the required information notices to data subjects.

For account, authentication, installation, subscription, and support data, the legal basis may include the user's consent, performance of a contract, legitimate interests in operating and securing the service, and compliance with legal obligations.

Patient data entered into the specialist workspace may include special categories of personal data, including health, appearance, procedures, and photo or video materials. The specialist or organization using Aestory determines the legal basis for such processing and is responsible for obtaining necessary consents and complying with applicable professional, medical, storage, and deletion requirements.

This Policy describes how Aestory works as an application and backend service. It does not replace the personal data processing policy of a clinic, office, sole proprietor, or other operator providing services to patients.

5. Local Storage and Data Sharing

Patient cards, photos, videos, notes, 3D materials, reminders, and backups are intended to be stored locally in the Application's storage and file area on the user's device.

The Aestory backend stores account, installation, authentication, session, entitlement, catalog, audit, and service log data needed to operate the service. The backend does not automatically receive local patient workspace materials.

3D creation, import, viewing, uploads, retries and automatic result downloads have been removed from the current Application. Previously saved 3D files remain on the device and retain backup compatibility. Automatic cancellation of system transfers left by older versions is disabled in the current Application. The backend no longer provides processing-job or storage-link endpoints.

Earlier versions could upload user-selected photographs or videos directly to private S3-compatible storage to create 3D images through a separate processing component. Previously issued storage links may remain valid until they expire. After the retirement migration, workers cannot claim further jobs. Already claimed jobs may finish or stop. Their input materials and PLY or GLB results remain private; administrative cancellation and automatic cleanup continue.

Data may leave the user's device when the user performs an action, for example:

• registers an installation or signs in to an account;
• uses email verification or Yandex, Google or Apple sign-in;
• checks subscription status or requests an entitlement lease;
• imports, exports, shares, or saves files through operating system tools;
• creates a backup and shares it through the system share sheet;
• sends a file, screenshot, backup, log, or issue description to support.

When the user shares data through a third-party application, cloud storage, messenger, email, operating system service, or app store, that sharing is governed by the terms and privacy policies of the selected service.

6. Device Permissions

The Application requests permissions only when they are needed for specific features:

• camera: to take photos and videos;
• microphone: to record videos with audio or dictate notes, if this feature is used;
• speech recognition: to convert speech into note text, if this feature is used;
• media library/files: to add materials to records and save selected materials;
• notifications: for local reminders;
• run after device restart on Android: to restore scheduled local notifications;
• internet access: to communicate with Aestory backend services and external services used for authentication, email, subscriptions, updates, or support.

The user may revoke permissions in device settings. After permissions are revoked, some features may become unavailable or work with limitations.

7. Backups, Exports, and Support Materials

The user may create local backups or exports. A backup or export may include specialist profiles, patient records, notes, media files, and other local workspace materials.

The user independently chooses where to store backups and exported files and with whom to share them. Aestory does not automatically receive these files and cannot control copies saved outside the Application.

If the user sends a backup, export, screenshot, log, or other file to support, Aestory may process the supplied material to diagnose the issue, answer the request, and protect the service. Do not send patient data to support unless there is a lawful basis and the data is necessary for the request.

8. Security

Aestory uses technical and organizational safeguards appropriate to the current service architecture. Installation credentials and refresh tokens are stored on the backend as cryptographic digests rather than as plain tokens. Entitlement leases are signed with server-side keys. Production traffic is served through HTTPS.

Server-side authentication includes access tokens, refresh token rotation, installation credential checks, session binding, rate limits for sensitive authentication routes, and account/session revocation mechanisms.

Local Application protections, such as a workspace PIN or protected backup, do not replace device-level security. The user is responsible for securing the phone or tablet, including device passcode, biometrics, screen lock, operating system updates, backup protection, and access control.

App Store subscription verification

When App Store purchases are enabled in a compatible application, Apple processes payment. Aestory creates a random account link (appAccountToken) for the signed-in account and purchase environment, and sends it to Apple with the purchase. When TestFlight support is enabled, the same server-issued account link may be authorized in Sandbox and Production for that same account. Test and real purchase histories retain their separate environment; Sandbox purchases provide temporary test access and are not real payments. This link is separate from Sign in with Apple and contains no email, patient data or installation credential. The backend records purchase intentions, their installation, product and timing, and account/installation request counters to limit abuse. Old counter buckets are removed after one day by subscription reconciliation.

For verification and restoration, the application sends a transaction identifier to the backend. The backend contacts the App Store Server API and verifies Apple’s signed records and certificate status using OCSP. Retained commercial data includes transaction and originalTransactionId identifiers, product and subscription group, environment, the account link, purchase/expiry/grace/revocation dates, renewal and billing status, and Apple’s price in thousandths of a currency unit and currency when supplied. These records link purchases to access sources and preserve other valid access when one purchase is refunded.

Apple may send signed subscription notifications. Aestory retains notificationUUID, type, environment, transaction references, signed and received timestamps, a one-way payload digest, and processing/retry results. Raw signed purchase and notification payloads and private signing keys are not stored in the database or application logs. Requests to Apple and certificate-status services contain technical purchase or certificate information, not patient workspace data. Apple handles its data under its own privacy policy.

Deleting an Aestory account or uninstalling the application does not cancel Apple billing. Manage cancellation separately in Apple subscription settings. Deletion asks for acknowledgement of this warning when purchase history or an unfinished native purchase is known, without requiring cancellation or a waiting period. Commercial purchase, notification, account-link and access-history records may be retained for accounting, security, reconciliation, disputes and legal obligations under the retention purposes below. Later Apple events do not restore a deleted account or its access, including if the same sign-in identity creates a new account.

9. Retention and Deletion

Local workspace data is stored on the user's device until the user deletes it in the Application, deletes the Application, clears Application data through the operating system, or deletes externally saved copies.

Backend account, installation, authentication, entitlement, audit, and log data is retained for as long as needed to provide the service, secure accounts, maintain subscription and access records, comply with legal obligations, resolve disputes, and enforce agreements.

For previously accepted jobs, input photographs or videos are deleted as soon as processing is complete or otherwise reaches a final status. A successful PLY or GLB result is kept for no more than two hours under the existing retention policy. Physical deletion may take longer while automatic cleanup retries a temporary storage error. Technical job metadata and queued records remain for audit and possible restoration; retirement does not erase these records. Local patient files and backups are unaffected.

When the user deletes an account from an authenticated app session, Aestory closes the backend account, revokes its active sessions and refresh tokens, removes or de-identifies email, Yandex, Google and Apple sign-in identifiers stored by Aestory, and revokes active account entitlements. Apple account deletion requests a fresh Apple authorization to revoke the app's authorization with Apple before completing local deletion. If this authorization is unavailable, the user may contact support to request deletion. Limited installation, session, entitlement, audit, and log records may be retained without direct sign-in identifiers where needed for security, accounting, dispute resolution, legal compliance, or proof that deletion was handled.

Access tokens and refresh tokens have limited lifetimes. Refresh token records may be retained as digests with rotation, expiry, and revocation timestamps for security and replay protection. Audit and infrastructure logs may be retained for security, diagnostics, and accountability.

Backups, exported files, and materials shared through other applications are stored wherever the user saved or sent them. Such copies must be deleted separately.

10. User and Data Subject Rights

The user may view, edit, export, and delete local workspace data using the Application and operating system tools where the relevant feature is available.

If the user's app version supports account deletion, the user may delete the backend account from the authenticated account or settings area. After deletion, the previous account tokens stop working. The same email address for password sign-in, or the same Google, Apple or Yandex provider identity, may be used to create a new account without an account-deletion waiting period. The deleted account, its sessions and access rights are not restored. Successful deletion of an email account resets the short verification-email resend delay for that email address; verification-email send records and daily limits are retained, and a new send starts the delay again. The reset time is recorded with prior sends. Deleting a social sign-in account does not reset a separate email account's resend delay. Other authentication rate limits still apply. The backend no longer creates or checks sign-in identity reservations for deleted accounts; previously stored reservation fingerprints are removed when this change is applied.

For backend account, authentication, installation, subscription, or support data, the user may contact Aestory to request access, correction, deletion, restriction, or other actions available under applicable law.

If you are a patient and your data has been entered into Aestory by a specialist, please contact that specialist or the organization providing services to you. They determine the purposes and legal bases for processing patient data.

For questions related to the Application, backend services, or this Policy, contact: privacy@aestory.space.

11. Children

Aestory is not intended for independent use by children and is not directed at children as an audience. If data of minor patients is entered into the Application, the user must ensure that there is a lawful basis and the required consent from the child's representatives in accordance with applicable law.

12. Third Parties and Processors

Aestory may use third-party services and infrastructure providers to operate the Application and backend services. This includes Yandex OAuth for Yandex sign-in, Google Sign-In and Sign in with Apple when enabled and chosen, and Yandex Postbox for sending email verification and service emails.

The backend and its PostgreSQL database are hosted on Timeweb Cloud virtual servers. The hosting infrastructure processes the technical, account, subscription and security data described in this Policy. Patient cards, medical notes, photographs and videos remain in the user's local workspace and are not transferred to these backend servers.

For Google and Apple sign-in, the Application sends the selected provider's identity token to the Aestory backend over an encrypted connection. The backend retrieves public signing keys from that provider to verify the token. When deleting an Apple account, the backend also exchanges a fresh authorization code with Apple and sends the returned token to Apple's revocation service. Provider identity tokens, authorization codes and provider access/refresh tokens are processed temporarily, are not stored in the backend database and are not included in application logs. Provider requests do not include patient workspace data. Google and Apple independently process sign-in data under their own privacy policies.

The Application also uses iOS and Android platform capabilities and technical libraries required for features such as camera, media library, local notifications, video playback, file handling, speech recognition, local image analysis, networking, and backups.

App stores, payment providers, cloud storage providers, messengers, email services, operating systems, and other third-party services selected by the user may process data independently under their own terms and privacy policies.

In the current version, Aestory does not use advertising SDKs, analytics SDKs, or third-party SDKs for user tracking.

13. Cross-Border Transfers

Aestory backend services, infrastructure providers, email providers, authentication providers, app stores, and support tools may process data in jurisdictions different from the user's location.

Patient workspace materials are not automatically uploaded to the Aestory backend. A cross-border transfer of such materials may occur if the user intentionally sends, exports, backs up, or shares them through third-party services, cloud storage, messengers, email, support channels, or other applications.

14. Changes to This Policy

This Policy may be updated when Application features, backend behavior, data processing practices, third-party providers, or legal requirements change. The English version is published at https://dev.aestory.space/privacy-policy and https://dev.aestory.space/privacy-policy/en. The Russian version is published at https://dev.aestory.space/privacy-policy/ru.

If changes materially affect data processing, the user will be notified in a reasonable way, for example through an updated policy page, release notes, or an in-app notice if such a feature is available.

15. Contacts