handyREADERSilkIdea s.r.o.Privacy Policy
Table of contents
At a glance
- Local reading does not send the book to our cloud.
- Selected cloud jobs use Hetzner, Google Cloud and OpenAI.
- The account and credit history use pseudonymous identifiers.
A brief overview. See the full text below for the scope and details.
Applies from version 4.00
This text, dated 4 October 2026, is for handyREADER version 4.00 and later and its related cloud services. It applies from the availability of version 4.00 on the relevant platform; the document date alone does not introduce new terms for older versions. Existing contracts change only through a valid procedure preserving statutory rights.
Controller and contact
SilkIdea s.r.o., company number 07990073, VAT ID CZ07990073, registered office: Kosova 1242/1c, Suchdol, 165 00 Praha 6, Czech Republic. Registered in the Commercial Register maintained by the Municipal Court in Prague, Section C, File 311152. Contact: info@silkidea.com; telephone +420 724 672 400.
SilkIdea is responsible for the processing described here. Send privacy questions and requests to privacy@silkidea.com or our registered office.
App support: handyreader@silkidea.com.
Scope and local data
This policy describes handyREADER from version 4.00 on Apple platforms and Android and its related cloud features. Local reading and listening do not send the book to SilkIdea’s cloud; synchronisation, backup, sharing and selected cloud jobs follow the rules below. On Apple devices, iCloud may synchronise reading state, unlocks and the cloud account identifier. Copies for Apple Watch are transferred between your devices. Synced data is also subject to your Apple account settings and terms. SilkIdea has no operational access to data in the user’s private iCloud.
The cloud account uses a random identifier instead of requiring name-and-email registration. It still links devices, jobs and credit history, so we treat these records as pseudonymous personal data rather than irreversibly anonymous data. Text you submit to cloud processing or support may itself contain identifying information. The account and device registration are created when the app first needs our server: on iPhone and iPad, version 4.00 already does this at its first launch with an internet connection; on Android, when you first open app information (i), a conversion or translation form, or credit purchasing. The server receives identifiers, app version, device language and region, and store environment; the network connection also involves the IP address used in abuse-prevention counters. This registration does not send book text and is not permission to send it. Text is sent only after your permission for the relevant cloud feature.
Android: backup and account restoration
With Android backup enabled, the device backup in your Google account includes library records such as reading and listening positions, settings and the list of unlocked books. Book files themselves are excluded from this app cloud backup; direct device-to-device transfer may also include local files. SilkIdea cannot access your private Google backup. Its availability and restoration depend on device and Google service settings.
The account is created without name-and-email sign-in; Scope and local data explains when registration occurs. Its identifier is stored locally and, where available, in Google Play services’ Block Store for restoration after reinstallation or transfer. The app enables cloud backup of this identifier in Block Store only when the service confirms end-to-end encryption is available; a screen lock alone does not guarantee successful backup. The device identity and its secret are not transferred through this app backup. The Android account and credits are separate from the iPhone and iPad account. Block Store also stores the list of unlocked books even if you do not use cloud conversions or translations.
Google Play handles purchases, restoration, sample-audiobook delivery and any app-rating prompt. Google operates these services under its own policy: https://policies.google.com/privacy. We do not receive payment-card details. These system services do not give SilkIdea access to books on your device.
Data, purposes and retention
The periods in this table describe the live system. Earlier backup copies, including text and outputs, follow the deletion cycle explained under Backups and completion of erasure.
| Data | Purpose / legal basis | Retention |
|---|---|---|
| Random account and device identifiers, access-secret hash, app version, device language and region, platform and production or test purchase environment | Technical registration and account-state restoration; contract for cloud features you request, legitimate interest for necessary service protection. Registration alone does not order a cloud job | For the account lifetime; deletion and necessary exceptions are described below |
| Push-notification token or installation identifier | Delivering status messages about your job; contract. Notification display follows system permissions | On our server while registered, until deregistration, detection of invalidity or valid erasure; Firebase retention is described below |
| Chapter text, book and chapter titles, translation context | Your requested conversion or translation; performance of contract after cloud permission | Text is deleted after chapter processing; context after job completion. Cleanup also covers cancelled and failed jobs |
| Resulting audio or translation | Delivering the ordered result; contract | Until confirmed download, up to 14 days after completion; on your device until you remove it |
| Job data without text: book and chapter titles, language, voice, quality and speed, status, times, character counts, credit price and device link | Operation and troubleshooting; contract and legitimate interest in remedying defects | 90 days after the last update of the terminal status following download, expiry, cancellation, deletion or failure; deleting a job in the app removes its titles from the live system immediately |
| Transactions, credits issued, reservations and consumption | Balance, purchase delivery and refunds; contract, protection of claims and specific accounting obligations | For as long as needed to substantiate the valid balance and settle claims; separate from the 90-day job history |
| Apple: App Store transaction and original transaction identifiers, product, credit quantity, purchase date, environment, pseudonymous account token, refund date and reason; App Store notifications and consumption-information requests including type, transaction reference, result and time | Verifying, crediting and settling a purchase; contract, legitimate interest in preventing duplicate credits, and specific legal duties | For the account lifetime and purchase settlement; afterwards only evidence necessary for a legal duty or specific claim |
| Android: purchase-token hash, Google Play order number, product, quantity, purchase date and country, refund or cancellation notifications and balance movements | Verifying, crediting and settling a purchase; contract, prevention of duplicate credits and specific legal duties | For the account lifetime and purchase settlement; afterwards only evidence necessary for a legal duty or specific claim |
| Android: redeemed credit-code reference linked to the account, credited amount and redemption time; the code itself is recorded as a hash | Granting free credits and preventing reuse of the same code by the account; contract | For the account lifetime and settlement of related claims; not a reason to retain other data after account erasure |
| IP address in abuse-prevention counters; operational identifiers and errors | Abuse prevention and diagnostics; legitimate security interests | IP counters approximately 61 minutes; operational logs rotate by volume. They do not intentionally contain book text |
Android: purchase verification
The app sends the purchase token to our server for verification with Google Play; the database stores a hash rather than the original token. The purchase carries a pseudonymous account token so the right balance is credited. When Google reports a refund or cancellation, the server deducts the corresponding credits; the Terms of Use explain negative balances and challenges. The same verified purchase is not credited repeatedly.
Cloud-job notifications
On Apple platforms we use Apple’s push-notification infrastructure. On Android the app registers with Firebase Cloud Messaging (FCM) when you first submit a conversion or translation. Google receives the installation identifier and necessary app and device technical data; our server links the identifier to the device. Status messages may include the job identifier, book title, status, chapter counts and result size, but not chapter text. This delivers the status of your requested service on the basis of the contract.
Displaying notifications depends on system permission. On Android, disabling their display does not necessarily cancel the technical FCM registration. Our server removes an invalid identifier when Google reports it or handles it during account erasure. Removal from our database does not itself delete the Firebase installation. For FCM identifiers, Google states retention until an API deletion request and subsequent removal from live and backup systems within 180 days: https://firebase.google.com/support/privacy.
Processors and transfers
Our backend is hosted by Hetzner Online GmbH under a processing agreement. The server splits chapter text into blocks and assembles the resulting audio; the speech itself for both Medium and Expert cloud qualities is created by Google Cloud Text-to-Speech through its European endpoint. Google receives text and voice and language settings; we do not add your account or device identifier to these requests. The text itself may contain personal data. Google states that this service does not log customer text or generated audio: https://docs.cloud.google.com/text-to-speech/docs/data-logging. This does not describe all other Google operational data.
Translation sends selected chapters and necessary context to the OpenAI API, which may process data in the United States. We do not add your contact details or account code, but the text itself may contain personal data. We use store:false. This does not mean zero retention: under OpenAI’s default rules, abuse-monitoring records may be retained for up to 30 days, longer for a legal obligation or specified safety exception. Under default API terms, data is not used for training unless the customer expressly enables sharing: https://developers.openai.com/api/docs/guides/your-data.
Google Cloud and OpenAI API processing is governed by their processing addenda: https://cloud.google.com/terms/data-processing-addendum and https://openai.com/policies/data-processing-addendum/. For transfers outside the EEA these provide for applicable adequacy decisions or standard contractual clauses and associated safeguards. Cloud-feature permission does not replace those safeguards. Contact privacy@silkidea.com for information about particular recipients, applicable safeguards and a copy. Apple operates the App Store, iCloud and push infrastructure in its respective roles under its own terms. We do not receive payment-card details from Apple. An App Store credit purchase carries a pseudonymous token derived from the account identifier so that credits reach the right account; Apple returns it in transactions and notifications.
Firebase Cloud Messaging processes message-delivery data for us under the Firebase terms: https://firebase.google.com/terms/data-processing-terms. The service may use global infrastructure, including locations outside the EEA; the European speech-synthesis endpoint does not restrict that processing. The terms provide for applicable adequacy decisions or standard contractual clauses. Google may have separate roles and policies for its own Firebase service data and for Google Play or your Google-account backup.
Your choices and decisions
Before the first cloud conversion or translation, the app asks for express permission to send content to the named recipients. You can change this at any time in app information (i), under Credit balance, using “Send book text to partner services”; local reading does not depend on it. Cloud features are for users aged 18 or over. Do not send data you are not authorised to process this way; professional processing for another controller requires appropriate contractual arrangements.
Apple only: when it requests information for a particular refund, we share delivery status, the calculated consumption percentage for that purchase, an automated refund recommendation derived from the unused balance, and flags for consent to sharing and availability of a free sample. We send this information only with separate optional consent. Change the choice in (i) › Credit balance using “Share credit usage with Apple for refunds”; refusal does not prevent credit use. We record the current choice, its change time and handling of the request. The calculation recommends a full, proportionate or no refund according to the estimated unused share; it does not determine your statutory rights. Apple decides the refund. You can ask our support for human review of the information, recommendation, charging or protective blocking.
Removing data and the account
Request server-data erasure or account closure at privacy@silkidea.com, quoting the account code from (i) › Credit balance › Credit history. We verify authority proportionately and explain how pending jobs and credits are handled. Deletion is not conditional on using the balance or waiving claims. Evidence needed for a legal obligation or specific claim is separated and its retention reason explained.
Uninstalling alone does not delete the server account, transaction history or all Keychain, iCloud, Block Store or Google-backup records. Manage local books, synchronised copies and backups on your devices and in the relevant Apple or Google account; we assist with erasure of app records. For Android a request also covers purchase links, credit-code use and the notification identifier. Erasure from the active database is not immediate erasure from every backup or provider system; requests also address these copies, Firebase and any restoration. While the identifier remains on a device or in a backup, the app may register it again as a new empty account after server erasure; iOS 4.00 may do so at the next launch. We therefore address local and backed-up identifiers when handling a request, rather than only deleting a server record. The precise process depends on the app version and may require your cooperation; uninstalling alone does not guarantee removal of the identifier.
Requests can be fulfilled manually after verification; we do not rely only on automatic rotation. Erasure covers linked records in active systems and unnecessary data in operational records. Ordinary logs are retained only as needed to diagnose and protect the service, according to the duration of a particular fault or security risk. We review necessity and erase or irreversibly anonymise records when it ends; a specific incident or legal claim may justify separate retention of the necessary records.
Backups and completion of erasure
We use daily Hetzner server backups in seven rotating slots for recovery. With regular daily operation, the cycle therefore covers approximately seven days. This is a server backup, not a separate retention period for accounts, operational logs or other providers’ data; their retention follows the purposes and rules described above.
A backup is a snapshot of the whole server. It may also contain chapter text queued or currently being processed, translation context, results awaiting download and persisted abuse-prevention counters. The periods above apply to the live system; after removal from it, data may remain in an earlier backup until that slot is overwritten, approximately a further seven days with regular daily operation. Manual copies and other providers’ backups follow the rules below.
Erasure also covers manual technical and migration copies. We retain these only as needed to verify recovery or complete a migration, then remove them unless a specific legal reason requires separate retention. Hetzner’s seven slots do not automatically remove these copies.
If an individual record cannot safely be separated from an immutable backup, we restrict further use and access, establish the earliest deletion date for that copy and reapply the relevant erasures before normal use after restoration. Technical difficulty alone is not a reason to refuse a request or retain data indefinitely. We explain the scope, timing and any statutory exception when handling the request.
Support and legal claims
The following rules also cover messages to handyreader@silkidea.com, info@silkidea.com and privacy@silkidea.com.
When you contact us, we process your address, message and information you attach to reply, perform the contract or handle a complaint. For general enquiries our legitimate interest is communicating with users. Send only necessary information. Our mail is hosted directly by IceWarp Cloud on its infrastructure and handled by people authorised by SilkIdea. IceWarp processes mail content to provide the service under its processing agreement: https://myicewarp.com/others/dpa.
We retain ordinary support correspondence while handling it and for no more than 12 months after the enquiry is closed. Necessary evidence of a specific legal claim may be kept separately until the applicable limitation period expires or the dispute is finally resolved. A document subject to statutory accounting or tax retention is kept for that period; this is not a reason to keep all correspondence.
IceWarp may use subprocessors. Its DPA requires appropriate safeguards for transfers outside the EEA, such as an adequacy decision or standard contractual clauses. Contact privacy@silkidea.com for recipient information and a copy of applicable safeguards. Our seven-day Hetzner server-backup cycle is not the retention period for the inbox or IceWarp backups.
Your rights
You may request confirmation of processing, access and a copy, correction, deletion, restriction and portability to the extent provided by applicable law. You may object to processing based on legitimate interests. You can withdraw consent for future processing without affecting the lawfulness of earlier processing.
Write to privacy@silkidea.com. We verify only information reasonably needed to handle the request; do not send passwords or secret keys. Requests are normally free. Under the GDPR we generally respond within one month and explain any permitted extension, its reason or any refusal. We do not penalise you for exercising your rights. A particular feature may become unavailable if we can no longer process data necessary to provide it.
You may complain to the competent supervisory authority, particularly where you habitually live or work or where an alleged infringement occurred. In the Czech Republic this is the Office for Personal Data Protection, https://uoou.gov.cz/. You do not have to resolve a matter with us before seeking regulatory or judicial protection.
Users in other countries
The contact process above is available to users in every country. Mandatory local rights prevail. Where your US state privacy law applies, you may also use an authorised agent and ask privacy@silkidea.com to review a denied request; we respond within the applicable deadline and explain further remedies. We do not sell data or share it for targeted advertising across services. This document describes the categories, purposes, recipients and retention.
Users in the United Kingdom may contact the ICO https://ico.org.uk/, in Switzerland the FDPIC https://www.edoeb.admin.ch/ and in Brazil the ANPD https://www.gov.br/anpd/. Local rights, including information about recipients, the consequences of refusing consent and review of decisions, remain available. The page language does not determine your residence or the scope of your rights.
Policy updates
The date and version appear above. We explain material changes and provide appropriate notice, for example in the app or on the website before new processing begins. Editing this page does not authorise a new purpose requiring consent. Previous versions are available on request.
Language versions
We prepare these documents in Czech and provide translations. If language versions of the same document and the same version conflict, the Czech text prevails to the extent permitted by applicable law. This does not affect mandatory local language requirements, mandatory consumer rights, interpretation of ambiguities in the consumer’s favour or information reasonably relied on when concluding the contract. This clause does not give priority between different dated versions and does not change Apple’s separate Standard EULA.
Version 1.2. From the release of handyREADER 4.00.
Back to top ↑