Protect the document. Protect the account. Keep the boundaries clear.

1. ReadThisAloud Security Model

ReadThisAloud separates local document processing from online commercial and account services. The Windows Reader is treated as a customer-controlled endpoint; source documents, OCR-recognized text, Natural Voice synthesis, read-along processing, and permitted audio encoding occur locally during standard use.

ReadThisAloud.com and related services handle the functions that must be shared across devices or accounts, including authentication, license and device validation, subscription status, narration-allowance authorization and metering, billing, secure downloads, updates, support, and administrative operations.

• keep source document text out of ordinary server-side narration requests;
• send character counts and authorization metadata instead of narration text for plan metering;
• protect database, payment, email, administrative, and other backend credentials from customer devices;
• authenticate and authorize account and device requests at the ReadThisAloud service boundary;
• separate payment-card handling from ordinary ReadThisAloud application data through Stripe where supported; and
• minimize collection and retention of information that is not necessary to operate the licensed service.

2. Security Architecture: Local Reader → ReadThisAloud Services → Operational Providers

The source document text used for standard narration is not part of this online service path. The Reader performs speech synthesis and supported OCR on the customer's computer. Online authorization and metering requests are designed to carry account, device, plan, application, timestamp, and character-count information rather than the source text.

The required voice models are bundled with the ReadThisAloud installer and stored locally on the Windows computer. There is no separate first-use voice-model download. Software download and update traffic contains application files and service metadata, not the customer's document or narration text.

4. Protected Service Credentials

Account, payment, email, database, and other service functions rely on protected server-side credentials. Those credentials are kept outside public webpages and are not presented as customer settings inside the Reader.

Access to systems that can read or change production credentials is treated as privileged access and should be limited to the people and components that require it.

5. Account, Device, and Metering Protection

The ReadThisAloud API acts as the controlled gateway for account, authentication, license, device, subscription, narration-allowance, and metering functions. A request may be evaluated for account state, authorized device, subscription status, plan limits, usage availability, application version, request validity, and abuse indicators.

For ordinary narration authorization, the service is designed to receive the character count and operational metadata needed to approve and record usage rather than the source document text. The approved text is synthesized locally by the Reader.

Rate limits, authentication checks, idempotent transaction handling, validation, and audit records help protect customer accounts and ReadThisAloud systems from abuse.

6. Transport Security and Network Communication

ReadThisAloud uses HTTPS/TLS for supported communication between the Windows Reader, ReadThisAloud.com, and other ReadThisAloud-controlled endpoints. Encrypted transport protects account, license, device, authorization, metering, billing-related, download, and support traffic while it is in transit.

Standard narration text and OCR-recognized text are processed locally and are not transmitted to an online speech provider for synthesis. If a customer voluntarily submits content to Support or stores an exported file in a third-party synchronized folder, that separate action may transmit content outside the local Reader workflow.

7. Customer Accounts, Passwords, and Authentication

ReadThisAloud account systems are intended to protect access to subscriptions, downloads, devices, billing-related information, and other customer functions. Customers are responsible for using a unique password, protecting the associated email account, and preventing unauthorized access to devices on which they remain signed in.

ReadThisAloud may use session controls, authentication records, password-reset mechanisms, login monitoring, rate limits, or other safeguards appropriate to the account system.

ReadThisAloud Support should not need your current password. Do not send passwords by email or support ticket. If account access must be restored, use an approved password-reset or identity-verification process.

8. License, Seat, and Device Security

License and device controls protect both legitimate customers and ReadThisAloud. They help prevent a purchased license from being copied, pooled, resold, or activated beyond the rights of the applicable plan.

ReadThisAloud may maintain activation identifiers, device-related identifiers, plan information, activation dates, deactivation history, and other licensing records reasonably necessary to administer purchased rights and investigate suspected abuse.

Device fingerprints or identifiers are security and licensing tools; they are not intended to give ReadThisAloud ownership or general remote control of the customer's computer.

9. Narration Usage, Rate Limits, and Abuse Prevention

ReadThisAloud plans include narration allowances and may include purchased Character Boost balances. Usage validation is therefore both a commercial and security control. ReadThisAloud may measure narration characters, authorization events, account usage totals, or equivalent plan units associated with an account or license.

Service-side limits can help prevent stolen credentials, automated abuse, account sharing, or a compromised account from consuming another customer's allowance or overwhelming ReadThisAloud services.

The metering request is designed around character counts and account/device authorization data; it does not require the source narration text.

10. Customer Documents and Narration Content

Customer Content is handled according to the data-minimization principles described in the Privacy Policy. Standard document extraction, supported OCR, Natural Voice synthesis, synchronized highlighting, and MP3 encoding occur locally on the Windows computer.

ReadThisAloud.com does not need the source document text to authorize or meter standard narration. Online service records can include account or license identifiers, device information, timestamps, application version, character counts, usage totals, request status, and related operational metadata.

If a customer intentionally sends a document, screenshot, sample text, or diagnostic file to Support, that submitted material is handled as support content and may be retained with the support case as described in the Privacy Policy.

11. Logs, Operational Metadata, and Diagnostics

ReadThisAloud may log account, authentication, license, device, authorization, metering, billing-related, application-version, error, and security events needed to operate and protect the service.

Ordinary server logs should not contain the full source document text used for local narration or OCR. Diagnostic information should be limited to what is reasonably necessary, and customers should avoid sending confidential documents or secrets to Support unless specifically necessary and authorized.

12. Payment Security and Stripe

ReadThisAloud uses Stripe for supported online payment processing. ReadThisAloud's preferred payment architecture is to use Stripe-supported payment interfaces that transmit sensitive card details directly to Stripe rather than routing raw card data through ReadThisAloud application servers.

Stripe states that it is certified as a PCI Level 1 Service Provider. Stripe also explains that PCI compliance remains a shared responsibility: using Stripe can reduce ReadThisAloud's card-data exposure, but it does not eliminate ReadThisAloud's responsibility to configure the integration securely and complete applicable PCI obligations.

ReadThisAloud may receive non-sensitive or limited transaction information such as transaction identifiers, card brand, last four digits, expiration information, billing details, payment status, refunds, and fraud signals where provided by Stripe.

ReadThisAloud Support should never ask you to email your complete credit-card number or card security code.

13. Administrative Access and Least Privilege

Administrative access to production systems, databases, payment settings, email configuration, customer records, deployment environments, and security controls should be limited according to job need.

Code-deployment and configuration access are privileged because a person or process with those permissions may be able to affect production behavior or access protected service credentials. ReadThisAloud should use role separation, strong authentication, audit records, and limited permissions where practical.

14. Software Distribution, Installation, and Updates

Customers should install ReadThisAloud only from ReadThisAloud.com or another source expressly authorized by ReadThisAloud. Third-party download sites may distribute outdated, altered, bundled, or malicious copies that ReadThisAloud does not control.

Security and compatibility updates may be released as the application evolves. ReadThisAloud may require a minimum supported version when an older build cannot safely or reliably communicate with production services.

Customers should keep Windows and other relevant system components updated and should not disable reasonable endpoint-security protections merely to run ReadThisAloud. If a security product flags the official installer, contact Support before creating an exception.

15. Infrastructure and Server Security

ReadThisAloud's production infrastructure should be configured to minimize exposed services, separate development from production where practical, restrict administrative access, protect secrets, apply security updates, and use hosting- and service-provider controls appropriate to the service.

Configuration, patching, dependency management, backups, permissions, network exposure, and credential lifecycle are continuing operational responsibilities rather than one-time tasks.

ReadThisAloud may change hosting components, security controls, regions, providers, or technical architecture when reasonably necessary to improve security, reliability, cost, scalability, or legal compliance.

16. Monitoring, Detection, and Protective Response

ReadThisAloud may monitor service and security events to identify authentication abuse, unusual licensing activity, excessive narration usage, malformed API requests, application errors, suspicious payment behavior, service degradation, or other indicators of misuse.

Protective actions may include throttling, session invalidation, password reset, token revocation, device deactivation, request blocking, temporary account restriction, forced update, service isolation, fraud review, or other measures appropriate to the observed risk.

Security monitoring is intended to protect the service and does not guarantee that every malicious event will be detected before harm occurs.

17. Security Incident Response

If ReadThisAloud identifies a suspected security incident, the response may include validating the event, containing affected access, preserving relevant evidence, rotating or revoking credentials, correcting vulnerable configurations or code, restoring service, assessing affected information, monitoring for continued misuse, and documenting corrective actions.

Where applicable law requires customer or government notification following a qualifying breach, ReadThisAloud will provide the notice required by that law. Not every service interruption, blocked attack, failed login, software defect, or suspicious event constitutes a legally reportable data breach.

During an active incident, ReadThisAloud may temporarily disable a feature or account if doing so is reasonably necessary to contain risk.

18. Availability, Backups, and Recovery

Security also includes the ability to recover from failures. ReadThisAloud may use backups, configuration recovery, deployment rollback, service redundancy, provider recovery capabilities, or other continuity measures appropriate to its production systems.

Because ReadThisAloud is not intended to be the permanent repository for the customer's original documents, customers remain responsible for maintaining their own source-document backups and copies of exported MP3 files they wish to preserve.

Backup availability does not guarantee zero downtime, zero data loss, or instantaneous recovery following every possible event.

19. Third-Party Service Providers

ReadThisAloud depends on third-party services for portions of its operation. Stripe provides supported payment infrastructure; other providers may support website hosting, transactional email, monitoring, security, software/model distribution, support, or other operational functions.

ReadThisAloud evaluates providers in light of their role and available security information, but ReadThisAloud does not control a provider's internal systems. Third-party outages, vulnerabilities, policy changes, or service changes can therefore affect the online portions of ReadThisAloud.

Standard local Natural Voice synthesis and supported OCR do not require a third-party speech-processing provider.

21. Business and Enterprise IT Considerations

Organizations should review ReadThisAloud before deployment in a managed environment. Relevant topics can include Windows version, installation permissions, endpoint protection, proxy and firewall rules, outbound service communication, seat administration, identity practices, software distribution, document classification, and acceptable-use policy.

Business customers may contact ReadThisAloud for security or procurement questions. ReadThisAloud may provide reasonable product-security information but may withhold sensitive internal architecture, credentials, exploit details, security configurations, or information that would materially weaken ReadThisAloud's security if publicly disclosed.

A customer's internal approval of ReadThisAloud remains the customer's responsibility.

23. Safe Interaction with ReadThisAloud Support

ReadThisAloud Support may request information necessary to diagnose a problem, but you should never send:

• your ReadThisAloud password;
• ReadThisAloud backend credentials, private API keys, or another party's service credentials;
• your Stripe account password;
• a complete payment-card number or card security code;
• private encryption keys, recovery phrases, or unrelated authentication secrets; or
• confidential documents when a redacted sample will reproduce the issue.

Support may legitimately request your account email, application version, Windows version, error message, transaction identifier, diagnostic logs, screenshots, or a carefully selected document sample when needed to reproduce a technical problem.

24. Reporting a Suspected Vulnerability

If you believe you have identified a security vulnerability in ReadThisAloud.com, the Windows Reader, an ReadThisAloud API, authentication, licensing, or another ReadThisAloud-controlled system, please report it privately rather than publishing exploit details before ReadThisAloud has had a reasonable opportunity to investigate.

Send a concise description to support@readthisaloud.com with the subject Security Vulnerability Report. Include the affected component, steps to reproduce, observed result, expected result, and enough technical detail for ReadThisAloud to validate the report.

Do not exploit a suspected vulnerability to access another customer's data, disrupt production, persist access, exfiltrate secrets, perform destructive testing, or violate applicable law. A vulnerability report does not authorize testing beyond access you otherwise lawfully possess.

25. Security Limitations and No Absolute Guarantee

Security controls reduce risk; they do not eliminate it. ReadThisAloud cannot guarantee that the service will never experience a vulnerability, malicious attack, compromised third-party provider, software defect, credential theft, customer-device compromise, outage, or unauthorized access.

ReadThisAloud may modify controls as threats, technology, architecture, providers, laws, and operating requirements change. A control described on this page should not be interpreted as an insurance policy, service-level guarantee, certification, warranty of uninterrupted service, or promise that every attack will be prevented.

Security representations are also subject to the EULA, Terms of Service, and rights that cannot legally be waived.

26. Security Changes and Contact Information

ReadThisAloud may update this Security page as the product and production architecture mature. Material privacy changes are addressed through the Privacy Policy, while license and service rights are governed by the EULA and Terms of Service.