Privacy Policy — AIX Player

Last updated: 2 November 2026

Changed on 2 November 2026: this policy covers AIX Player on Windows, Mac, iPhone, iPad and Android. It explains diagnostics choices, approximate location, storage regions, 90-day retention and deletion requests.

AIX Player is published by Ace Thought Technologies Private Limited, which operates the AixApps brand. In this policy, “we” and “us” mean Ace Thought Technologies Private Limited.

The platform descriptions cover AIX Player on Windows, macOS, iPhone, iPad and Android. Features and controls that differ are identified below.

The short version: AIX Player has no publisher account, shows no advertising, and does not upload a list of the titles you watch. Your library stays on your device. Videos move between your device and the TV, computer or media server you choose when you use those features, without a video relay operated by us (sections 4 and 8). The app can send diagnostic reports to us. On a new installation, the Mac, iPhone and iPad ask before creating diagnostic reports; older installations can keep an earlier regional default. AIX Player on Windows and Android asks first in the consent regions listed below; elsewhere diagnostics start on. You can switch diagnostics off. Reports include technical information and feature outcomes; on Windows a playback-failure report can also include eight bytes from the start of the file. This page explains the details.

1. There is no publisher account

AIX Player has no publisher sign-up or sign-in. We do not ask you to create a profile with your name, email address, phone number or date of birth, and we hold no publisher account for you.

Other companies’ accounts may be involved, and none is ours:

Microsoft account — if you buy the optional upgrade on Windows. The purchase happens in the Microsoft Store, under Microsoft’s terms.
Apple Account — if you buy or restore the optional upgrade on the Mac, iPhone or iPad. The purchase happens in the App Store, under Apple’s terms.
Google account — if you buy or restore the optional upgrade on Android. The purchase happens in Google Play, under Google’s terms.
Roku account — if you cast to a Roku. Roku requires our receiver channel to be added from your Roku account, so that step takes place on Roku’s website, under Roku’s terms.
Your media-server account — AIX Player only — if you connect to Jellyfin, Emby or Plex, as described in section 8.

2. Your videos and your library stay on your device

AIX Player reads videos you choose. It stores a library index on your own device: file names and locations, durations, resolutions, thumbnail images, playlists, favourites, and the position you stopped at in each file.

AIX Player on Windows and Mac: the app reads video files from folders you choose. It also adds the system Videos and Pictures folders on Windows, and the Movies folder on the Mac, to the initial library. You can manage these folders in Folders → Manage Library.
iPhone and iPad: the app can read videos from your Photos library, with the access you grant, and files you open or import. For a video stored in iCloud, iOS downloads it from Apple’s service so you can play it; that is Apple’s service, not ours.
Android: with your permission the app reads the videos on your device. On Android 14 and later you can grant access to selected videos only, and change that selection later. You can also choose folders or open single files. On Android 13 and later the app requests video-media access. Older versions use the broader storage permission, although the device scan looks for videos. The Android app opts out of Android’s system backup.

That index is never uploaded to us. It lives in the app’s local storage. Playing or casting a video does not upload your library to us either. The limited diagnostic information described below is separate from the index. See section 10 for removing local data.

3. Diagnostics are optional, and you are always in control

For AIX Player, whether the app asks before sending diagnostics depends on your platform. On Windows and Android it also depends on the country or region set on your device. The table and AIX Player paragraphs below describe that app.

AIX Player platform	Who is asked	Until you answer	Where to change it
Mac	Users without a recorded decision, once	No new reports before agreement; previously queued reports may still be sent	Settings → About → Send diagnostics
iPhone and iPad	Users without a recorded decision, once	No new reports before agreement; previously queued reports may still be sent	Settings → Privacy → Diagnostic data
Windows	Users without a recorded decision in the consent regions below, or whose region is unknown	No new reports before agreement; previously queued reports may still be sent	Settings → About → Send diagnostics
Windows	Other users without a recorded decision	Diagnostics start on; there is no question	Settings → About → Send diagnostics
Android	Users without a recorded decision in the consent regions below, or whose region is unknown	No new reports before agreement; previously queued reports may still be sent	Settings → Privacy → Diagnostic data
Android	Other users without a recorded decision	Diagnostics start on; there is no question	Settings → Privacy → Diagnostic data

On a new AIX Player Mac, iPhone or iPad installation, the app asks once whether to send diagnostics, whatever the region. The same applies to an installation with no recorded diagnostics decision. New reports require both an enabled diagnostics setting and a recorded decision. An older installation can keep an earlier regional default that allows reports without asking again. You can change that setting at any time.

For AIX Player on Windows and Android, in the app’s consent-first regions — the European Union and wider European Economic Area, the United Kingdom, Switzerland, South Korea, China, Brazil and Russia — the first run asks, once, whether to send diagnostics. No new diagnostic reports are submitted unless you agree. If the app cannot determine your region, it asks; it never assumes.

For AIX Player on Windows and Android, everywhere else, diagnostics start enabled after the app records that regional default, so crashes and casting failures can be found and fixed. There is no question. You can switch them off at any time.

For AIX Player on all four platforms, the consent question shows the diagnostics switch already on. Confirming with the switch on enables diagnostics; dismissing a question that appeared records a decline. On iPhone, iPad and Android the confirmation button says Continue. If the question never appears, no decision is recorded. A recorded choice is kept for later launches. On phones, Settings → About → Send diagnostics also opens the Privacy page.

The setting is checked before each new report, so switching it off stops new reports without restarting the app. It does not withdraw reports already handed to Microsoft’s exporter: reports queued in memory or saved locally for retry can still be sent, including on a later launch. This is the same on every platform. It also does not erase reports already received.

Windows reads its Country or region setting, with a locale-based fallback if the Windows region APIs fail. Android reads the region of the device’s language setting. Region does not decide the question on a new Mac, iPhone or iPad installation, but an older regional-default setting can still take effect. The app does not use your network location to make this consent decision.

While diagnostics are on, the app sends technical reports to Microsoft Azure Application Insights, a service operated by Microsoft. Its storage region is in section 5. Microsoft’s separate SDK health counters, called Statsbeat, are disabled on every platform.

3.1 What is sent

There are two kinds of report. Both are described here because both are sent.

Crash and error reports — when something goes wrong: the error type, its numeric error code (shown in hexadecimal), its redacted message, the name of the operation that failed, and a technical stack trace naming the app’s code and, where available, source file names and line numbers. If an error wraps an underlying error, the report also includes that underlying error’s type, redacted message and code stack, with limits on their length. For handled errors reported by the app’s media-server connection service or media-server screen, original messages are replaced with a fixed failure label and error types, alongside the code stack. Other error paths, including playback and crashes, use the general redaction rules. These are code locations, not the locations of your videos.

If the player takes too long to shut down, the report also says whether its quit command was accepted, was still pending, was cancelled or was not sent, or gives the type of its failure; whether the source was local or a network stream; and whether hardware decoding was last observed active, inactive or unknown. It records the shutdown wait limit and, once, whether the forced shutdown completed, left the player running until the app exited, failed, or had not settled within a further 30 seconds, and how long that took (up to that limit). A counter that restarts with the app pairs these two reports within the same launch. The later report may not be sent if the app has already exited. These reports also include the number of worker threads, pending work items and processor cores. These shutdown details include no video path or title.

Previous launch — Windows only. The app keeps a local launch record even when diagnostics are off. When diagnostics are on, a previous-launch report can include the previous app version; startup, page and activity labels; up to six recent event or error labels; whether the app crashed, hung or ended without a matching record; whether the computer restarted or the app version changed; time to the last record, its age, and the launch duration and end time where known. It can also include shutdown stages and a shutdown counter; video codec, HDR and resolution classes; a short label for a stalled interface operation; the page, control and event involved in an interface diagnostic; crash code, program module, module version, location category and code offset; or managed-code error types, limited stack frames and interface-parser details. The report also says whether Windows records were successfully queried and whether a matched Windows record supplied the end time. These are technical facts, not the video’s path or title, and launch duration is not viewing duration.

Crash dumps — Windows only. When diagnostics are on at the startup check, the packaged Windows app asks Windows Error Reporting to keep crash-dump copies in the app’s own folder on your PC. At startup the app makes a best-effort cleanup pass targeting two files, 200 MiB in total and seven days of age. These are cleanup targets, not guaranteed limits: files can remain longer if the app is not relaunched or cannot delete them. On the next launch the app reads a dump on your PC and sends only a short summary: the crash code and flags, the processor architecture, the name, version, timestamp and code offset of the program module where the crash happened, a list of module names and code offsets from the stack, when the dump was written, its age, and the crashed and reporting app versions. The summary can also include the read/parse result, file-type and root-folder/subfolder categories, stack-scan type and start, and whether and how a Windows end record was matched, including its end time. The dump file itself is not sent. After marking a dump as processed, the app attempts to queue the summary and delete the dump; it does not wait for confirmation that the report reached us. If the app could not set up these copies, it reports the reason. If diagnostics are off when the startup task checks the setting, it skips dump registration and reading and attempts the same cleanup. Changing the switch later does not cancel dump work or registration already started during that launch; new diagnostic reports still pass the current setting check. This app-managed dump feature exists only on Windows; operating-system and store reports are separate.

Usage events — named events about feature use and outcomes, including successful operations as well as failures. We use reports to fix crashes and errors, learn which features are used, and understand upgrades to Pro. We do not use them for advertising, advertising profiles or to reconstruct what someone watched. Events depend on the features in your app. They include:

Event	What it carries
Graphics inventory — Windows only	Numeric hardware vendor/device identifiers and driver versions; process and operating-system architecture; report-schema version; and the enumeration result, stage, reason, error code and counts. The free-form adapter description, memory size and integrated/discrete classification are not included in this report
Playback failed	Failure reason, engine reason code, codec, file extension and whether the source was a network stream; where the file can be checked, whether it was readable and a rough size band. On Windows: up to the first eight bytes of the file as hexadecimal text (`magic`). On the Mac, iPhone, iPad and Android: only a format name from a fixed list, such as `mp4`, `matroska` or `unknown` (`format`), with no bytes of the file
Thumbnail generation failed	File extension; requested decoder, attempted decoders, failure stage, attempt count and fallback/result flags; exception type and a short, redacted error line; codec, pixel format, transfer function, DV HDR profile, HDR/wide-colour flags and a rough band for the file’s duration. The thumbnail image is not sent
Audio-chain snapshots and output problems — all four platforms	A snapshot of fixed audio-filter names and limited output values can be reported after a load even without an error. Problem reports include a fixed reason, whether a saved output device was missing, the kind of device preference and codec class
Unknown casting device model	Casting-device class, manufacturer, model number and reported firmware or operating-system version, plus the attempted playback route and its outcome. Product fields are cleaned and limited to 48 characters. Reported at most once per model per installation when diagnostics are enabled; no friendly device name, IP address, MAC address, serial number or unique device identifier is included
Casting outcomes	Casting technology and connection, pairing, start, stop or command outcome; refusal and invalid-queue reasons; timeout operation and length; conversion progress and seek target percentage. Playback outcomes can also include a random identifier for the attempt, planned and actual playback route, encoder and receiver model, retry and stage information, performance timings, receiver errors and timeout checks; container, video/audio codec, resolution and frame-rate bands, bit depth, HDR type and audio-channel class. No video title or watched-title history is attached
Purchases and restores — Windows, Mac, iPhone and iPad	Product identifier, public catalog price where available, purchase/restore outcome and failure category; Store connection/catalog problems and whether the entitlement could be saved or recovered. The Mac, iPhone and iPad also report entitlement revocation and its outcome. Windows also reports Store-page and review-prompt activity. These events contain no payment-card details, receipt or Store-account identifier
Pending purchase-entitlement recovery — Android	Product identifier, recovery method and result, including successful recovery and cases where a saved recovery record cannot be read. Ordinary Google Play checkout results and catalog prices are not sent by the billing callback; this recovery report can be sent when diagnostics are enabled. No Play purchase token is attached
Upgrade screen — all four platforms	That the upgrade screen was opened, and from where in the app
HDR allowance and rating request — all four platforms	When the allowance applies, that the free HDR allowance started, ran out or blocked a preview, without extra event-specific fields; the common report fields below still apply. Rating-request reports say that the app asked the store to show its rating prompt, why, and the outcome; the rating itself is the store’s
Library maintenance	Scan completion, counts, budgets and fallback reasons; stale or duplicate row counts; failed analysis with extension and attempt count; database collection/version, error type and lock status where reported. No library listing is sent
Download failure — AIX Player on Windows only	Download scheme, address category and failure reason. The Mac, iPhone, iPad and Android apps have no download feature
Network or saved-sign-in failure	Timed-out network operation; media-server provider and connection error/status; which secret-storage operation could not save a credential and why, without the credential
App startup and other feature outcomes	Startup stage, failed operations, and refused folder/address schemes; fixed outcome labels rather than the folder or full address

The file’s duration band is its length, not how long you watched it. Conversion and seek percentages describe an operation that failed; they are not a continuous playback log. Error text can carry information that the redaction rules do not recognise, as section 3.2 explains.

Reports also carry: the event name or code component, app version, Debug/Release build, process and operating-system architecture (including whether the process is emulated), shutdown state, and a random session identifier generated fresh each time the app starts. The iPhone, iPad and Android apps also add an explicit platform-family field (ios or android), not a device model or system build. The Windows and Mac apps do not add that explicit field. The exporter adds the report time, technical type/severity, SDK and application metadata, and another per-process instance identifier. These random identifiers group reports within a launch; they are not saved as a permanent user or device ID.

3.2 What is removed, and the limits of that

Error messages, event names and every event-property value pass through automatic redaction before sending, on every platform. Recognised email addresses and credential patterns are replaced; a property named as a password, token or other secret has its value withheld altogether. Handled errors from the media-server connection service and media-server screen get a fixed message and error types instead of the original message; other error paths use the general rules. If redaction cannot finish in time, the message is withheld rather than sent half-redacted.

A recognised file path is removed. In its place the report keeps only the file’s extension and a short code calculated from the file name, or a folder placeholder. The folder structure and readable name are removed. The code is calculated the same way every time and is not salted: the same name gives the same code across reports, and someone who guesses a name can calculate its code and compare. This is the same on every platform.
Recognised web addresses on iPhone, iPad and Android become their scheme and a placeholder, such as https://…; the server name, path, query and fragment are removed. This applies to recognised addresses, not every possible address written in free text.
Web addresses on Windows and the Mac are reduced, not removed: a web address keeps its scheme and server name, for example https://example.com/…. Its user information, path, query and fragment are removed. A private or personal server name can itself identify a person or device.
Recognised IPv6 addresses and private/local IPv4 addresses are masked, as are IPv4 addresses with a port or a clear network cue. A bare public-looking IPv4 address can remain. Fields named as software or driver versions skip address masking so that version numbers are not mistaken for addresses.

One limitation worth stating plainly: redaction works by recognising patterns, and it cannot recognise every name, bare file name, unusual path or piece of personal text in an error message or event value. This limitation also applies on iPhone, iPad and Android. Names are removed where the app recognises them, but unrecognised text and codes derived from names can remain. The Windows and Mac Settings switch is labelled “Send diagnostics”. File-name codes, the server names kept on Windows and the Mac, and any unrecognised text mean that we cannot promise every report is anonymous. The Windows file-header field is also actual file content, not a code.

3.3 What is never sent

Through the app’s diagnostic channel, we do not send:

Video pictures, sound, thumbnail images, or a copy of your video file. On Windows there is one limited file-content exception: a playback failure can send the first up to eight bytes, as hexadecimal text. These normally help recognise a file’s format, not a picture or sound; if a non-video file is opened, those bytes can instead be ordinary text. On the Mac, iPhone, iPad and Android, those bytes are turned into a format name from a fixed list on your device, and no bytes of the file are sent.
Your library index, playlists or favourites, or a history of which titles you watched and for how long. The failure-related size/duration bands and progress percentages in section 3.1 are separate.
Your Store-account identifier, purchase receipt or purchase token, card number or billing address.
An advertising identifier, or a permanent user/device identifier assigned by our diagnostics code. The per-launch identifiers change; the file-name codes and retained text described above can repeat.
A Windows crash dump file (only the summary in section 3.1).

Approximate location. The app does not request GPS or precise location on any platform. Microsoft’s service sees the public IP address your device connects from and derives an approximate location from it. It stores country or region on every report, and state/province and city on most. We keep these location fields. They can appear when we look at reports by region. We do not use them to identify or contact anyone, for advertising or for profiles.

The connecting IP is masked on every stored report: IPv4 is stored as 0.0.0.0, and IPv6 is cut to a prefix. No full connecting address is retained in that field. This does not remove addresses that may remain in report text under the redaction limits in section 3.2.

Your configured country is used on your device for the consent decision on Windows and Android; it is not a location field added to our reports. Connections to a store, a TV, a computer on your Wi-Fi or your own media server are separate from diagnostics and are described below.

4. Casting on your network and device set-up

When you cast a local video file to a TV, playback is between your device and the TV you chose. The app can start a temporary web server on your device so the TV can fetch the video directly. For AirPlay, the Mac, iPhone and iPad use Apple’s system services; Windows and Android use the app’s own sender. We do not upload the video to a server we operate or route it through one.

That temporary server is intended for local-network playback. It uses plain HTTP, which is not encrypted, and does not require a sign-in. A client that can reach it can request files allowed by the server, including files in the cast video’s folder and its subfolders, and the app’s casting cache. Access is not restricted to the selected TV or by a check that each client has a private network address.

Device set-up can involve the manufacturer. Depending on the receiver supported by your platform:

Roku requires our receiver channel, added from your Roku account on Roku’s website.
Chromecast devices load their receiver through Google’s infrastructure.
AirPlay on the Mac, iPhone and iPad uses Apple’s system services and route picker.
Other TVs may ask for a one-time pairing step.

The available routes depend on the app, receiver, network permissions and receiver software:

App and platform	Compatible receivers and routes
AIX Player — Windows	Chromecast; Roku with our receiver channel; compatible DLNA, Samsung Tizen, LG webOS and Fire TV devices; Apple TV through the app’s sender
AIX Player — Mac	Chromecast; Roku with our receiver channel; compatible DLNA, Samsung Tizen, LG webOS and Fire TV devices; AirPlay through Apple’s system services
AIX Player — Android	Chromecast; Roku with our receiver channel; compatible DLNA, Samsung Tizen, LG webOS and Fire TV devices; Apple TV through the app’s sender
AIX Player — iPhone and iPad	AirPlay through Apple’s system services. Other compatible Chromecast, Roku, DLNA, Samsung Tizen, LG webOS and Fire TV receivers can be offered when local-network discovery is available

On iPhone and iPad, discovery of other receivers depends on the app having Apple’s required local-network entitlement and your local-network permission. Those receivers may not appear if either is unavailable. Apple’s system AirPlay picker is a separate route. Compatibility can vary by receiver model and software.

App-managed TV pairing codes or tokens are stored locally and are not sent to us. Your TV and system services are operated separately; consult the policies of the services and devices you use. If the source is an internet stream or a remote media server rather than a local file, that source is also contacted to obtain the video.

4.1 Wi-Fi transfer — iPhone, iPad and Android

Wi-Fi transfer moves your own files between a computer and your phone or tablet over your Wi-Fi. You start it in the app. The app then runs a small web server on your device’s private Wi-Fi address, protected by an access code. The file transfer uses no outside transfer service and does not send the transferred files to us. Diagnostic error reports can still be sent when diagnostics are enabled. The connection uses plain HTTP, which is not encrypted; the access code controls who can connect, but it does not encrypt the files.

On both phone platforms, new transfer requests are refused once the session is 30 minutes old, and each request has its own 30-minute timeout. A transfer already in progress can continue past the session’s thirtieth minute. Leaving the transfer page stops the server. On iPhone and iPad, moving the app into the background also stops it; Android has no corresponding automatic background stop in this feature. The Windows and Mac apps do not expose Wi-Fi transfer.

5. Who receives diagnostics, where they are stored, and for how long

Diagnostic reports are sent to Microsoft Azure Application Insights. Microsoft provides the service as our processor under its data-protection terms.

We may use software tools, including AI-assisted analysis tools, to analyse reports, and their providers process them only on our behalf.

Reports for AIX Player are stored in West US 2 (United States). Copies we download for analysis are kept on the publisher’s computers in India.

Reports are kept for up to 90 days in Microsoft’s service. We also delete downloaded analysis copies, including report exports and summaries, after no more than 90 days, using an automatic deletion step.

The app’s diagnostics switch does not change where reports are stored or for how long. Turning diagnostics off stops new reports, but does not delete reports already received or cancel the exporter’s saved retry queue.

The stores’ own crash and usage reporting is separate from the app’s diagnostics switch. We use reports from Microsoft Partner Center, Apple App Store Connect and Google Play Console. These include installs and acquisitions, purchases and add-ons as reported by the store, crash and health reports, and ratings and reviews. Apple’s App Analytics includes only users who agreed to share with developers. We use these reports to fix crashes and errors, learn which features are used, and understand upgrades to Pro.

We keep downloaded store-report copies, such as exports and screenshots, for at most 90 days. The stores’ own privacy policies govern what they collect. Our retention limit for downloaded copies does not set how long a store keeps its own records.

6. Purchases

Optional upgrades and add-ons are sold and processed by the store you buy them from, under that store’s terms and privacy policy. The app uses the store’s checkout and does not ask you to enter card numbers or billing addresses in the app’s own checkout form. We receive store reports about purchases and add-ons as described in section 5.

Windows — Microsoft Store. The app asks the Store for products, prices and purchase status, and saves the entitlement information it needs on your device so it can recognise your upgrade.
Mac, iPhone and iPad — Apple App Store. The app uses Apple’s StoreKit for products, purchase, restore and transaction updates, and saves the entitlement information it needs on your device.
Android — Google Play. Google Play handles the payment. Play returns the product, a purchase token, the purchase time and its state; the app confirms the purchase to Play with that token. The app saves your entitlement and its date on your device. It does not save the purchase token in its files.

When diagnostics are enabled, the purchase and restore outcomes listed in section 3.1 are sent to us from Windows, the Mac, iPhone and iPad; the receipt and Store-account identifier are not. On Android, the billing callback does not send ordinary checkout results or catalog prices to diagnostics, but pending-entitlement recovery can report the product identifier, recovery method and outcome when diagnostics are enabled.

7. No advertising or advertising trackers

AIX Player contains no advertising in its free or paid versions on any of these platforms. It contains no advertising identifiers, social-media trackers, marketing pixels or advertising-attribution products. The diagnostic service in section 3 receives technical reports and feature outcomes; see section 3.1 for their purposes.

We never sell your information. We do not share it for advertising or build advertising profiles of you. We do not use reports to reconstruct what someone watched. Sending diagnostics to Microsoft for processing, and connecting to the services you choose, are the data flows described in this policy.

8. Network shares and media servers — and what is hidden in store releases

This section describes AIX Player.

Network shares and media servers let you play video stored elsewhere. You choose the computers, servers and accounts involved. Saved connection records and protected sign-in tokens stay in local app storage. Diagnostic reports follow the redaction rules in section 3.2, including possible retained server names on Windows and the Mac, and unrecognised text on any platform. The app discovers and probes media servers on your network before you add a connection, then contacts the servers and service endpoints used for the connections you choose, including plex.tv during Plex linking. Technical failure reports can be sent when diagnostics are enabled, as described above.

Network shares (SMB) — Windows and Mac only. The app can browse shared folders on a computer or NAS and play from them. On Windows, choosing to remember a sign-in saves the credential in Windows Credential Manager; Forget sign-in removes it after you confirm. The app may also save the server address and username locally. On the Mac, the SMB password is held in memory for the connection and open files, not saved to disk or Keychain. Remembering a server saves its address and username, not its password, so a later app session may ask you to sign in again. Authentication goes to the server you select. Network shares are not exposed in the iPhone, iPad or Android store-release interface.

Media servers (Jellyfin, Emby, Plex). For Jellyfin and Emby, the app sends the username and password you enter to your server. Plex uses account linking through plex.tv and then a token for the selected server. The sign-in token is saved on your device:

Windows: in the app’s local connection file, encrypted for your Windows user account.
Mac: in the app’s local connection file, encrypted using a random key kept in the macOS login Keychain. The Mac does not put each token directly in Keychain.
iPhone and iPad: encrypted with AES-256-GCM using a key kept in the iOS Keychain on this device only; the key is not synchronised to other devices.
Android: encrypted with AES-256-GCM using a key held in Android Keystore on the device.

If encryption is unavailable, the app does not save that token in plaintext; you may need to sign in again. When removal saves successfully, it removes the connection’s saved token from the app’s connection file and recovery copy. This is not a guarantee of erasure from other backups.

For HTTPS media-server requests, the app also accepts an unverified certificate when its host rule recognises the address as local, such as a private IPv4 address, localhost, a single-label name or a .local name. This rule does not recognise every kind of private address. HTTPS requests to public hosts require valid certificates. A server configured with plain HTTP has no certificate check or encrypted connection, whether its address is public or private.

Plex linking contacts plex.tv. The account token obtained during linking is used to find your servers; only the selected server’s token is kept. The app also creates a persistent, random media-server client identifier and sends it to the selected service, including plex.tv during linking. For Jellyfin and Emby, it adds a short code calculated from the username to distinguish accounts on the same installation. These identifiers are separate from the diagnostic session identifiers.

While you play from a media server, the app reports the title’s identifier and your playback progress to that server so it can resume and mark titles watched. The server handles those reports under its own policies, which we do not control. Posters and titles come from the server and are cached on your device. The app also supports browsing compatible DLNA media servers.

Hidden in the store-release interface: linking cloud-storage accounts (OneDrive, Google Drive, Dropbox). We will update this policy before any store version enables cloud-account linking.

9. Children

AIX Player is for a general audience. It is not directed at children under 13, or under the minimum age where you live. We do not knowingly collect personal data from them. If you believe this has happened, contact aixplayer@acethought.com. There is no publisher account or child-specific registration. The same optional diagnostics and connections to services you choose apply to all users. The diagnostic controls and limitations described above apply to everyone.

10. Your choices

Turn diagnostics off or on at any time — in AIX Player on Windows and the Mac in Settings → About → Send diagnostics; on iPhone, iPad and Android in Settings → Privacy → Diagnostic data. Switching off stops new reports; previously queued or saved reports can still be sent.
Remove saved sign-ins by removing media-server connections and, on Windows, using Forget sign-in for network shares. A Windows network credential can be shared with other Windows apps.
Remove local data as well as the app if you want to erase the library index, thumbnails, playlists, favourites, playback positions and app-managed TV pairing records. Do not assume deleting the Mac app also removes its saved data or its Keychain encryption key. Uninstalling does not erase records already held by Microsoft, Apple, Google, your media servers or other services you used.
Ask us anything using the address below.

To request deletion of reports from AIX Player on any of these platforms, contact aixplayer@acethought.com. Tell us your platform, the app version, and the approximate dates and times of the reports. Include the time zone if you know it. Reports carry no name or email-address field and no publisher account identifier. The redaction limits in section 3.2 still apply.

We delete matching reports and downloaded copies. Without a name or account attached to reports, we may be unable to single out one person’s reports. Reports in Microsoft’s service and our downloaded copies age out after at most 90 days under the limits in section 5.

Depending on where you live you may have rights under laws such as the GDPR or the CCPA. Use aixplayer@acethought.com to ask about or exercise those rights.

11. Changes to this policy

If this policy changes, we will update this page and the date at the top. We will clearly describe material changes, including changes to what we collect.

12. Contact

Questions, privacy requests or deletion requests for AIX Player on any platform:

aixplayer@acethought.com

Ace Thought Technologies Private Limited (AIX Player / AixApps)