Security at ReadThisAloud

1. ReadThisAloud Security Model

ReadThisAloud's security model is intended to reduce the number of systems and people that need access to sensitive credentials and customer information. The desktop Reader is treated as a customer-controlled endpoint, while privileged cloud credentials and administrative capabilities remain on protected service infrastructure.

The principal design goals are to:

• avoid embedding Azure subscription keys, Stripe secret keys, private API keys, or administrative credentials in the Windows Reader;
• authenticate and authorize requests at the ReadThisAloud service boundary;
• apply license, device, account, subscription, and usage controls before consuming paid cloud resources;
• minimize persistent storage of Customer Content used solely for real-time narration;
• separate payment-card handling from ReadThisAloud's ordinary application data wherever the selected Stripe integration permits;
• restrict administrative access according to business need;
• retain enough operational and security information to detect abuse, troubleshoot problems, respond to disputes, and protect ReadThisAloud; and
• avoid making security claims that are broader than the controls actually implemented.

2. Security Architecture: Reader → ReadThisAloud → Speech Service

The customer application should not function as the owner of ReadThisAloud's Azure Speech resource. Instead, the Reader requests authorized ReadThisAloud functionality through the ReadThisAloud service boundary. This architecture lets ReadThisAloud enforce commercial and security controls without exposing privileged service credentials to every installed copy of the application.

4. Managed Identity and Server-Side Secret Management

The ReadThisAloud backend is designed to use Microsoft Azure managed identity where supported and appropriate. Microsoft describes managed identities as a way for Azure-hosted applications to obtain Microsoft Entra access tokens without developers having to place service credentials directly in application code.

Where a required service does not support the intended managed-identity authentication flow, any necessary secret should remain server-side in an appropriately protected secret-management configuration rather than being shipped to customer computers.

Managed identity is not a substitute for access control. Permissions assigned to an identity should be limited to what the associated service needs, and administrative access to resources capable of using that identity must also be restricted.

5. ReadThisAloud API as a Security Boundary

The ReadThisAloud API is intended to act as the controlled gateway between the customer application and protected cloud services. A request may be evaluated for account state, authentication, license validity, authorized device, subscription status, plan limits, usage availability, request validity, and abuse indicators before ReadThisAloud requests paid speech processing.

Keeping authorization logic on the service side makes it harder for modification of a local application setting alone to bypass subscription or usage controls.

ReadThisAloud may reject, throttle, delay, challenge, log, or temporarily block requests that are malformed, unauthorized, excessive, automated in an unsupported way, suspicious, abusive, or inconsistent with the EULA.

6. Transport Security and Network Communication

Production ReadThisAloud website and API communications are intended to use HTTPS/TLS so that supported traffic is encrypted while moving between customer systems and ReadThisAloud-controlled endpoints. ReadThisAloud also relies on encrypted transport offered by approved service providers for supported service-to-service communication.

Customers should not bypass browser certificate warnings, disable TLS validation, install untrusted interception certificates, or use modified clients that intentionally defeat transport protections.

Encryption in transit reduces exposure to network interception, but it cannot protect data after an attacker has gained control of an unlocked customer computer, stolen account credentials, compromised an authorized administrator, or otherwise reached an endpoint with legitimate access.

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

Natural speech processing creates real cloud-service expense. Usage validation is therefore both a commercial and security control. ReadThisAloud may measure characters, requests, service units, or equivalent usage associated with an account or plan.

Service-side limits can help prevent stolen credentials, automated abuse, denial-of-service behavior, or a compromised account from generating uncontrolled cloud charges.

ReadThisAloud may implement request-size limits, concurrency limits, rate limits, usage ceilings, retry controls, anomalous-usage review, temporary holds, or other protective measures. Limits may evolve as the service and threat environment change.

10. Customer Documents and Narration Content

Customer Content should be processed according to the data-minimization principles described in the Privacy Policy. Text needed for requested narration may pass through ReadThisAloud-controlled infrastructure and Microsoft Azure Speech or another approved provider.

The architecture is designed around narration processing rather than using ReadThisAloud as a permanent document-hosting repository. Transient technical processing can still involve memory, request queues, temporary buffers, network transit, provider processing, and limited diagnostic handling needed to complete or secure the service.

Microsoft currently states that customer data is not used to improve its Speech models and documents its storage and retention behavior for its Speech services. Provider behavior can vary by feature, so ReadThisAloud's Privacy Policy should remain aligned with the specific Azure features actually enabled in production.

11. Logs, Operational Metadata, and Diagnostics

Security requires enough evidence to understand what happened. ReadThisAloud may retain operational metadata such as timestamps, request status, account or license identifier, device activation events, usage totals, software version, error information, authentication events, IP or network information, and security signals.

ReadThisAloud should avoid intentionally placing full private document text into ordinary application or web-server logs unless that content is specifically required for an authorized diagnostic process.

Security, fraud, payment-dispute, license-abuse, and incident records may be retained longer than ordinary performance logs when reasonably necessary to investigate an event, defend ReadThisAloud, comply with law, or establish what occurred.

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 should be limited to personnel and systems with a legitimate operational need. ReadThisAloud's architecture is intended to separate ordinary customer use from privileged administration.

Privileged access should be granted narrowly, reviewed when roles change, and removed when no longer needed. Where supported, administrative systems should use stronger authentication and role separation appropriate to their risk.

Access to systems that can execute code under a managed identity is particularly sensitive because that code may inherit the identity's authorized Azure permissions. ReadThisAloud administrators should therefore treat code-deployment access as privileged access.

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 cloud-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 WAV 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 Cloud and Service Providers

ReadThisAloud depends on third-party services for portions of its operation. Microsoft Azure may provide cloud and speech-processing functionality; Stripe provides supported payment infrastructure; other providers may support hosting, email, monitoring, or 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 ReadThisAloud.

ReadThisAloud may replace a provider or technical component when necessary to address security, reliability, legal, availability, or business concerns.

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's Azure keys or another party's private cloud 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.