What a media app on your phone can see, and what it should never send
An app that plays your files, holds your IPTV credentials and browses the web on your behalf is trusted with a lot. Most of the privacy questions worth asking are not about whether an app is malicious — they are about what it collects because collecting is easy, and what it stores carelessly because storing is easy.
- No account is a real answer
- If there is nothing to sign in to, there is no server-side profile to leak, subpoena or sell.
- Analytics is not tracking
- Counting screen opens and counting you across other companies’ apps are different activities with different rules.
- A lock is not encryption
- A PIN in front of a folder stops a person holding your phone. It does not make the files unreadable.
Three things a media app is unavoidably trusted with
The first is your library — file names, folder structure, what you played and when. This is unusually revealing. A list of file names says more about a person than most contact lists do, and it is trivially easy for an app to include in an analytics event without anyone intending harm.
The second is credentials: IPTV panel usernames and passwords, cloud tokens, WebDAV logins. These are only as safe as the place they are stored. On iOS that place is the Keychain, which is encrypted, tied to the device and not readable by anything else. A credential in an app’s own database is a credential in that app’s backup, and in anything that can read that backup.
The third is what you browse, if the app has a browser. Cookies from a logged-in session are as good as a password for as long as they last. They need to exist in memory for the duration of a request and be gone afterwards — never written to disk, never logged, never sent anywhere for “diagnostics”.
The vocabulary that appears in every privacy policy
Worth understanding, because these words are used precisely in the App Store rules and loosely everywhere else.
- Analytics
- Counting things about how an app is used — screens opened, features tried, crashes. It becomes a privacy problem when the values carry content: a file name, a URL, a channel, a search term.
- Tracking
- A specific term in Apple’s rules: linking data about you with data from other companies’ apps or sites, for advertising or data brokerage. It is not the same as analytics, and it is what the permission prompt is about.
- IDFA
- The advertising identifier. An app may only read it after you allow tracking in that prompt. Declining does not remove ads; it removes the identifier that would tie them to you across other apps.
- Consent management (UMP)
- The dialogue advertising SDKs show in Europe to gather a legal basis for personalised advertising. It is separate from Apple’s prompt, and you can decline both.
- Keychain
- The system’s encrypted store for secrets. It is the correct home for every password an app holds, and its use is one of the few things you can actually verify from the outside, in an app’s own documentation.
Reading an App Store privacy label without being misled
These headings mean quite different things, and the middle two are where most surprises live.
| Label | What it means | What to ask |
|---|---|---|
| Data Not Collected | Nothing at all leaves the device. | Rare and strong. If an app has advertising, this cannot be true. |
| Data Not Linked to You | Something is collected, but not tied to an identity. | What, exactly? Aggregate counts are fine; a list of what you played is not, whatever the label says. |
| Data Linked to You | Collected and associated with an account or identifier. | What identifier — and can it be turned off after the fact, or only before? |
| Used to Track You | Shared for cross-app advertising or brokerage. | Whether declining the prompt actually stops it, and what the app does when you decline. |
Free apps, honestly
A free app is paid for by something. Usually that is advertising, a subscription, or both — and each has an honest version and a dishonest one. The dishonest version of advertising is the full-screen interstitial that appears between you and what you were doing, or an ad SDK given free rein over whatever identifiers it can reach. The honest version is advertising that stays out of the way and does not follow you between apps when you decline to be followed.
It is worth knowing that ad networks are rarely one company. A mediation setup asks several networks to bid, which means several SDKs in the app, each with its own policy. An app that names them is telling you something real; an app that says “we may use third-party advertising partners” is telling you nothing.
The same applies to analytics. There is a genuine difference between an app that counts how many people opened the downloads screen and an app that records what you downloaded. The first is a product question. The second is your library, on somebody’s server, forever.
What an app lock does — and what it does not
A passcode or Face ID prompt in front of an app is a screen lock. It stops someone who has your unlocked phone in their hand from opening the app and browsing your files. That is a real and useful threat model — it is, in fact, the threat most people actually face — and no small thing.
What it is not is encryption. The files still sit on disk in the ordinary way. A forensic tool with the device passcode, a full unencrypted backup, or another app that has been granted access to the same folder does not encounter that lock at all. Any app claiming a PIN makes your files unrecoverable is overselling, and it is worth noticing which claim an app makes.
Device-level encryption is the layer that does that work, and iOS gives it to you free: the whole disk is encrypted, and the device passcode is what unlocks it. An app lock sits on top as a second door, which is worth having precisely because it defends against the everyday case.
How to evaluate any media app you are considering
- Is there an account, and why?
A player that requires a login should be able to explain what the server does for you. Often the answer is “collects”.
- Does the policy name its partners?
Specific names — analytics provider, ad networks — are checkable. Vague categories are not.
- Can analytics be declined, and stay declined?
Both at first launch and later, permanently, without hunting.
- Where do credentials go?
The Keychain is the only correct answer, and a decent app says so plainly.
- What happens on decline?
An app that degrades or nags when you decline tracking has told you what it thinks that permission is worth.
- Can you get your files out?
Content in a normal, visible folder can leave. Content in a private database cannot, and that is a privacy question too.
Where the platforms differ
Where the tracking prompt and the consent dialogue appear, and where an app lock earns its place — the phone is the device most likely to be handed to someone else.
The same rules as iPhone. More often a shared device in a household, which makes a second lock on private folders more useful, not less.
A build with no advertising SDK linked at all, so the entire question of identifiers and consent does not arise.
Questions people ask
If I decline tracking, do the ads go away?
No — the ads stay, and become less targeted. Declining removes the advertising identifier that would link what you see to your activity in other companies’ apps. That is the whole scope of the prompt, and any app implying otherwise is misdescribing it.
Can an app read my other apps’ files?
No. The sandbox prevents it. An app sees its own folder, plus anything you explicitly hand it through the document picker or the share sheet. This is enforced by the operating system rather than by the app’s good behaviour.
Is a VPN needed to use an IPTV player privately?
A VPN hides traffic from your network operator and moves the visible endpoint. It does not change what the app itself collects, and it does not change your provider’s obligations. It is a separate concern from app privacy, frequently sold as though it were the same one.
What is the safest way to keep something private on a phone?
A strong device passcode with the disk encryption it enables, an app lock on top for the everyday case, and an honest understanding that anything synced to a cloud account is subject to that account’s security rather than your phone’s.
Where FoxDL stands on each of these
Stated plainly, because the whole point of the section above is that vague answers are not answers.
- There are no user accounts at all. Nothing to sign up for, nothing to sign in to, and therefore no profile of you anywhere.
- Your library never leaves the device by our doing — no file names, no paths, no URLs, no panel usernames appear in anything we send.
- Analytics is Firebase/Google Analytics, and it can be declined during onboarding or later in Settings, permanently.
- Advertising is banner, native and rewarded only — there is no interstitial in the app and none may be added. The ad networks are named in the Privacy Policy rather than hidden behind “partners”.
- The Mac build links no advertising SDK at all, which is why its free tier is metered daily instead.
- Every credential lives in the Keychain, never in the database and never in a log. Browser cookies exist in memory for the length of a request.
- App lock with a 4–6 digit PIN, Face ID or Touch ID and a recovery code — described as a screen lock, because that is what it is.
- The vault is the encrypted one, and the distinction is kept everywhere on this site: files moved into it are encrypted with ChaCha20-Poly1305 under a key that never leaves the device, and we hold no copy of it.
The full Privacy Policy names every SDK, every category of data and the legal bases. The English version is the authoritative one; other languages are provided for convenience.
Questions people ask about this
- What data does FoxDL collect?
- Are there ads, and do they interrupt anything?
- Can I lock the app with a passcode or Face ID?
- Is FoxDL free?
- What does FoxDL Pro include, and what does it cost?
Keep reading
Hidden, locked, encrypted — three words that are sold as one
What separates hiding from locking from encrypting, and why the recovery code is the whole thing.
Five ways to get a large file onto an iPhone, and when each is the right one
Wi-Fi, device to device, cloud, WebDAV or a drive — which route suits which job.
What has to happen before a web page will give you its file
The four ways a page delivers video, and why only one of them is a file you can keep.
Where your files actually live on an iPhone, and who can see them
The sandbox, where downloads actually go, and why renaming a file breaks so many apps.
Your library, finally in one place.
Free to download. No account, no sign-up, and the whole feature set is in the free version.