Privacy Policy

Last updated: 28 September 2026

The data controller for the "Tunvio" app within the meaning of the GDPR is the operator of the Tunvio Project named in the legal notice (https://tunv.io/impressum).

Contact for data protection matters: support@tunv.io

Tunvio is solely a viewer / player application. Content is not provided by the Tunvio Project; every IPTV connection goes directly to a server you have entered yourself as a profile (Xtream Codes, M3U playlist, a direct stream URL or a Stalker portal).

Tunvio is solely a viewer / player application. The Tunvio Project does not provide any content, does not host any streams, and does not operate any media services. For information on your responsibility when choosing a source, see the Terms of Use (https://tunv.io/terms-of-use).

Tunvio stores the following information exclusively on your device:

• Server URL, username, and password of the IPTV provider you configured
• Profile names (optionally assigned by you)
• Watch history (recently viewed content)
• Favourites list
• Downloaded content and recordings (if created by you — for these you can choose a folder of your own, see Section 12)
• Optional parental PIN per profile
• Image cache (thumbnails for channels and movies)
• TMDB metadata cache (see Section 8)
• Skip observations per profile: the points in a series where you skipped the intro or the end credits, so the app can offer "Skip intro" or "Next Episode" there
• Queue of skip-mark contributions not yet sent, if you have turned on sharing skip marks (see Section 8)
• Anonymous purchase identifier, where a purchase runs through the browser (see Section 5)
• Household identifier, if you have paired devices (see Section 5.1)
• Device identifier of this installation, as soon as you use device pairing (see Section 5.1)

None of this data leaves your device towards the Tunvio Project; only if you pair devices yourself are the household and device identifiers sent to our pairing service and stored there (Section 5.1), and only if you have turned on sharing skip marks does the queue go to our skip-mark service, without any link to a profile or provider (Section 8). It can be fully removed by uninstalling the app; history and favourites can be cleared directly in Settings. The one exception are recordings and downloads that you have directed to a folder of your own — Section 12 explains what happens to those.

When you use Tunvio, the app establishes a direct connection to the IPTV server you provided yourself (Xtream Codes API, M3U URL, a direct stream URL or a Stalker portal). How that server processes your data is the responsibility of your IPTV provider, not the Tunvio Project. Please review your provider's privacy policy.

When playback stalls or fails, Tunvio automatically checks what is causing it. To do so, the app sends a few short test requests to your provider's server (name resolution, connection setup, encrypted connection, a short fetch of the stream and – for Xtream and Stalker – a call to the account interface with your saved credentials). These are the same kinds of connections the app makes during playback anyway. It also reads on your device whether a VPN or filter app is active, whether the network reports internet access and whether a private DNS is set. The result is shown on your device only and is not sent automatically.

"Check more closely" (only when you tap it). If you tap "Check more closely" in the diagnosis sheet, Tunvio asks a public DNS service (Cloudflare, or Google Public DNS as a fallback) over an encrypted connection whether your provider's server name is known there. Only this server name is sent – no credentials, no path and no device identifier; as with any connection, the service sees your IP address. The check runs only when you explicitly tap it and not when a private DNS is active on your device. The result stays on your device unless you send it to us with a bug report (section 7.1). The legal basis is your request by tapping (Art. 6(1)(b) or (f) GDPR – you want to know why playback fails). The privacy notices of Cloudflare (cloudflare.com/privacypolicy) or Google (policies.google.com/privacy) apply; a transfer to the USA is possible.

Tunvio offers optional premium features that can be unlocked via in-app purchase or subscription. Which channel handles the payment depends on where your copy of the App came from. Where nothing is sold at all — for instance on Samsung Tizen smart TVs — no payment processing takes place and no data is transmitted for this purpose.

• Payment processing through a store: if your copy was distributed through the Apple App Store, Google Play or the Amazon Appstore, the purchase is handled there. Your payment details (e.g. credit card) are processed directly by Apple, Google or Amazon; the Tunvio Project receives and stores no payment data.
• Payment processing in your browser: for builds not distributed through a store (desktop versions, for example), the purchase runs through a checkout page hosted by RevenueCat, Inc. in your web browser, where the payment itself is handled by the payment service provider used there. Here, too, the Tunvio Project receives and stores no payment data. The App only opens the page; whatever you enter there, you enter with RevenueCat and its payment service provider.
• Subscription management: To manage subscriptions and verify entitlement status we use RevenueCat, Inc. (USA). RevenueCat receives an anonymous, randomly generated app user ID together with purchase/receipt information from the purchase channel you used to determine whether an active subscription exists. No real names, email addresses, or payment details are transmitted to RevenueCat by the App. Privacy notice: https://www.revenuecat.com/privacy
• E-mail address after a browser purchase: since the App has no user account, a purchase made in the browser is restored on another device via the e-mail address you used at checkout. You enter it in the App, where it is converted on your device into a derived identifier (a hash); only that identifier is used to look up the entitlement. The address itself is not stored permanently — only the derived identifier remains on your device — and if you open the checkout page again afterwards, it is carried along as a pre-fill.

Legal basis: performance of a contract (Art. 6(1)(b) GDPR) for providing the purchased features.

If you have bought Premium on one device, you can use it on your other devices without buying it again. To do so you have the paid device show you an eight-digit code and type that code into the second device. Both devices then belong to one household (at most seven devices) and share a single, randomly generated purchase identity. This is brokered by a service of our own at https://pair.tunv.io, operated by the Tunvio project itself in Germany; no processor is involved, and no transfer to a third country takes place.

Only on an explicit action of yours. Pairing is never triggered automatically. As long as you neither have a code shown nor enter one, the app makes no contact whatsoever with this service — there is no check at startup, no background reconciliation and no periodic sign of life. In builds of the app made without this service's address the feature is absent entirely and never appears in the interface.

This service is the only place where a device identifier is stored permanently. Every other service of our own described in this policy is deliberately built so that a device cannot be recognised again across days — which is why, for example, the diagnostics in Section 7 carry a daily identifier only. A device list you can remove an individual device from cannot be built that way: it requires an identifier that stays. We name this exception explicitly rather than pass over it.

Only the following is stored permanently, per household:

• a random device identifier for each paired device. It is generated by the app itself from random numbers; it is not an identifier of your operating system, not an advertising ID, not a serial number and not a MAC address.
• a display text for the device list: the device model your operating system reports (for example "Pixel 8") or, where it reports none, a generic word for the type of device (for example "Samsung TV" or "Windows PC"). There is deliberately no self-chosen name.
• the time of pairing
• a random household identifier that ties these entries together
• per household, the time it came into being and a yes/no note on whether a code was ever redeemed. Both exist for one purpose only: to recognise a pairing attempt that never became a pairing, and delete it after 30 days.

Only briefly does the eight-digit code itself exist: it is valid for 10 minutes and deleted afterwards; once redeemed, it is spent immediately.

Expressly not stored:

• no IP address. The service keeps no access logs (access_log is switched off) and writes your address to no entry.
• no email address, no name, no account — the procedure has no sign-in at all.
• nothing about your purchases. When a code is requested the app does send along its current purchase identity — the service needs it to recognise a household that already exists — but the service discards it as long as it is still the anonymous identifier of a single installation. It checks no entitlement and keeps identifiers and nothing else. Whether a purchase exists for you at all is something it never learns.
• nothing about your profiles, your provider, channels or titles.
• the service's logs never contain a code, a device identifier or a household identifier.

Abuse limits. So that an eight-digit code cannot simply be guessed, three limits apply: at most 3 codes per household per day (this daily counter is kept against the household identifier), 5 failed attempts, then a 60-second lockout, and a general cap on request frequency. For the latter two your IP address is converted at the point of arrival into an opaque, rotating pseudonym — a keyed hash whose key is generated randomly when the service starts, exists only in main memory, is never written to disk, never logged and never exported, and is replaced on a fixed schedule. The address itself is neither stored nor logged nor passed on, and once the key has been rotated the mapping can no longer be reconstructed. This protection of the service rests on our legitimate interest (Art. 6(1)(f) GDPR, see Recital 49).

What changes for RevenueCat. After pairing, the app user ID mentioned in Section 5 is no longer a different one per installation but the same one for every device in your household — namely the random household identifier. It remains a random number with no connection to your name or address; no real names, email addresses or payment data are transmitted as a result.

Retention: no expiry. A paired device stays stored until you remove it from the list. There is deliberately no deadline after which an entry disappears by itself — a television that is not switched on for half a year should keep its place. The one exception is a pairing attempt that never became a pairing: if a code was fetched and never redeemed, that entry is deleted after 30 days.

How you delete. In the app, under Settings → About, you see the devices of your household and can remove any of them; that makes its entry at this service disappear. If you remove your own device, it leaves the household and returns to a purchase identity of its own. When the last entry is removed, the household itself is deleted.

Access and erasure. For these entries too we store no name, no account and no email address; we cannot identify you as a person within them (Art. 11 GDPR). Unlike with the diagnostics server in Section 7, however, you do not need us for that: the device list in the app shows you exactly what is stored for your household, and removing an entry deletes it immediately. Access and erasure are therefore something you exercise directly yourself here. For questions: support@tunv.io.

The legal basis is your consent (Art. 6(1)(a) GDPR), given by having a code shown or by entering one. You withdraw it with effect for the future by removing the device from the list.

On Android and iOS Tunvio uses services provided by Google Ireland Ltd. / Google LLC ("Firebase"). On other platforms these services are inactive.

We collect the following two services only with your consent. They are switched off by default; on first launch we ask you once whether you want to enable them. Without your consent no data is collected through them:

• Firebase Analytics: Collects pseudonymous usage statistics (e.g. screens viewed, coarse device and app-version information, approximate region) so we can improve the app. Analysis relies on pseudonymous identifiers; no IPTV credentials, profile names, passwords, or playback URLs are transmitted to Firebase.
• Firebase Crashlytics: Collects crash and error reports (technical stack trace, device and app-version information) so we can fix crashes. Here too, no credentials, profile names, or playback URLs are transmitted.

The legal basis for analytics and crash reports is your consent (Art. 6(1)(a) GDPR, and § 25(1) TDDDG for accessing information on your device). You can withdraw your consent at any time with effect for the future — under Settings → Data & Storage via "Usage data & crash reports". The change takes effect immediately. If you decline on first launch we will ask you at most one more time; never again after that.

Data may be transferred to the USA; Google relies on the EU Standard Contractual Clauses for this.

Google privacy notice: https://policies.google.com/privacy

In addition to the Firebase services described in Section 6, we report selected technical errors and crashes to a diagnostics server of our own. That server (https://diag.tunv.io) is operated by the Tunvio Project itself in Germany; no processor is involved and no transfer to a third country takes place. Unlike Firebase, this reporting works on all platforms — including smart TV and desktop, where Firebase does not run.

Collection takes place only with your consent and is switched off by default. It is governed by the same switch as analytics and crash reports (Settings → Data & Storage, "Usage data & crash reports"). Without your consent nothing is collected through it.

This section describes the automatic reports. A bug report you write and send yourself is covered separately in Section 7.1 — it is its own processing operation and does not depend on this switch.

The purpose is error diagnosis only — detecting errors, grouping equivalent reports, fixing them and verifying that a fix actually holds in a new version. There is no usage analysis, no profiling and no advertising measurement.

Only the following data is transmitted:

• kind of event (playback, login or sync error, crash, or a hang or freeze of the user interface measured by the app itself)
• error class (e.g. timeout, TLS failure, decoder error, connection limit reached)
• HTTP status code, where the server returned one — the number only, e.g. 403
• the playback engine and decode step in use
• content type (live, movie or series)
• kind of profile (Xtream Codes, M3U, direct URL, Stalker or merged) — not the provider and not its address
• app version, platform, major operating-system version, device model and language setting
• coarse device and runtime characteristics, always as a tier and never as a measurement: the device's memory class (low/medium/high), the app's build type (release/debug/profile), after a hard termination of the previous session the termination kind named by the operating system as a keyword (such as "not responding" or "native crash") together with a coarse age bucket for that information, and for merged profiles whether one, some or all members were affected
• a daily identifier: 16 random bytes, regenerated on every calendar day. It lets us recognise several reports from the same day as belonging together and is deliberately chosen so that a device cannot be recognised across days. There is no installation or device ID.
• for crashes and for a hang terminated by the system additionally: the exception type, the error message with free-text parts redacted, the technical stack frames of the program code, and the internal name of the app screen on which it happened (such as "player" or "settings" — never a content item, channel or title)

The following is expressly not transmitted: playback or server URLs (not even shortened or masked — the bare hostname alone would indicate which IPTV service you use), channel, movie or series titles, search terms, profile names, usernames, passwords or any other credentials, MAC addresses and device serial numbers.

No storage of the IP address. The server keeps no access logs (access_log is switched off). Your device's IP address is needed for transport only; it is neither stored nor written to the reports, and is held transiently in memory solely to limit abuse (rate limiting).

The legal basis is your consent (Art. 6(1)(a) GDPR, and § 25(1) TDDDG for accessing information on your device). You can withdraw it at any time with effect for the future in the settings under Data & Storage; the change takes effect immediately, and nothing further is transmitted from that point on.

Retention: individual reports are deleted automatically after 90 days. Only aggregated figures per error pattern remain (such as counts, first and last occurrence, affected app versions), which no longer relate to an individual report or an individual device.

Access and erasure: note on Art. 11 GDPR. For these reports we store no identifier that would let us attribute them to a particular person or a particular device — there is neither an account nor an installation ID, and the daily identifier is regenerated every day. Under Art. 11(2) GDPR we are therefore not in a position to identify you within this data set, and to that extent we cannot fulfil the rights of access, rectification, erasure, restriction of processing and data portability (Art. 15 to 20 GDPR). That is the statutory consequence of the data minimisation this feature was deliberately built around. Under Art. 11(2), second sentence, GDPR you may provide additional information enabling attribution; without such attribution the rights named above do not apply to this data set. Your right to withdraw consent at any time in the settings and your right to lodge a complaint with a supervisory authority remain unaffected.

Besides the automatic reports above, you can write and send a bug report yourself under Settings → About → "Report a problem" – or in the player via the diagnosis sheet "What's wrong?" → "Report a problem". This is a separate processing operation with its own purpose, its own trigger and its own scope — it is not part of the ongoing diagnostics.

Only on an explicit action. A report leaves your device only when you write it and confirm the send dialog. It is not buffered, not re-sent in the background and not repeated.

Independent of the ongoing diagnostics. The report arrives even when the "Usage data & crash reports" switch is off; conversely, sending a report does not switch the ongoing diagnostics on. The send dialog offers you to turn them on as a voluntary, separately ticked option; it is not pre-selected, sending works without it, and you can withdraw that consent at any time in the settings (Art. 7(3) GDPR).

What is transmitted:

• the free text you wrote (your description of the problem),
• the technical diagnostics log of your session (the same lines you can view and share under Settings → Playback → Advanced), including the most recent program errors with technical stack frames,
• the type of problem reported (playback, connection, app, other),
• app version, platform, major OS version, device model, language setting, playback engine in use, profile type, and whether a premium entitlement exists,
• for a report from the player, additionally the diagnosis result (suspected cause, confidence, outcome of the test requests from section 4.1 and whether a VPN or private DNS was active – each as a short value, without server names, IP addresses or credentials).

Before sending you can inspect exactly the log that will be transmitted, via "What will be sent?" in the send dialog. Both the free text and the log are automatically stripped of URLs, host names, e-mail addresses, IP addresses and credential-shaped strings — on the device and again on the server. Please still do not put passwords or credentials into the description: automatic redaction cannot recognise a password written inside an ordinary sentence.

No link to your device or account. The report carries no daily identifier and no other identifier; it cannot be connected to the automatic reports from the same device, nor to an account. The reference number issued is randomly generated and derived from no device or user value. Here, too, no IP address is stored.

The legal basis is your consent, given through the explicit act of sending (Art. 6(1)(a) GDPR). Withdrawal for the future is moot because nothing is processed on an ongoing basis; for a report already sent, contact support@tunv.io quoting the reference number — with that number we can locate and delete it.

Storage period: as with every individual report, 90 days, then automatic deletion.

Tunvio enriches movies and series with extra information (descriptions, ratings, logos, posters, age ratings) from The Movie Database (TMDB). The enrichment is part of how the catalogue is displayed and has no separate on/off switch. What you can do at any time is delete the metadata cached on your device, under Settings → Data & Storage.

Requests do not go directly to TMDB but through a caching proxy operated by the Tunvio Project (https://tmdb.tunv.io). Only what the respective request needs is transmitted: when searching for a title, the cleaned title and — where detectable — the release year; when fetching details, the TMDB id of the movie or series; when fetching a season and when fetching skip marks (below), the TMDB id of the series and the season number. Which episode you are watching and how long it runs is not transmitted. No profile, credential, password, or playback data is transmitted. The proxy adds the required TMDB API key server-side and queries TMDB with it — you do not need a TMDB API key of your own. Results are cached both on the proxy and locally on your device to reduce requests.

Your IP address is not stored. The proxy keeps no access logs. Your address is needed to transport the request, and for protecting the service against abuse (rate limiting, blocking automated probing) it is converted at the point of arrival into an opaque, rotating pseudonym — a keyed hash whose key is generated randomly when the service starts, exists only in main memory, is never written to disk, never logged and never exported, and is replaced on a fixed schedule. The address itself is neither stored nor logged nor passed on, and once the key has been rotated the mapping can no longer be reconstructed. This protection of the service rests on our legitimate interest (Art. 6(1)(f) GDPR, see Recital 49).

The legal basis for the enrichment itself is our legitimate interest in convenient, fast metadata display (Art. 6(1)(f) GDPR); you have the right to object under Art. 21 GDPR (support@tunv.io). TMDB's own processing is governed by its terms (https://www.themoviedb.org/privacy-policy). The Tunvio Project has no affiliation with TMDB.

Fetching skip marks. When you play an episode of a series, Tunvio asks through the same proxy (https://tmdb.tunv.io/skip) whether other viewers have already contributed marks for the intro and end credits of that season (see "Shared Skip Marks" below). This lets the app offer "Skip intro" or "Next Episode" from the very first episode — as a button, never as an automatic jump. Only the TMDB id of the series and the season number are transmitted; the response contains the marks for the whole season, and the app picks the matching episode only on your device. The episode, its running time and the title are not transmitted. Your IP address is treated exactly as described above. The request does not depend on whether you share skip marks yourself. The legal basis is our legitimate interest in convenient playback (Art. 6(1)(f) GDPR). You can object at any time (Art. 21 GDPR) by turning off the "Show shared skip marks" switch under Settings → Data & Storage; this request then no longer takes place.

If you search for online subtitles for a movie or episode (or enable automatic loading in Settings — off by default), the request is routed through a caching proxy operated by the Tunvio Project (https://subs.tunv.io). Only what is needed to find matching subtitles is transmitted: the title's TMDB/IMDB id — or, where unavailable, its cleaned title, release year and season/episode numbers — plus the requested subtitle languages. No profile, credential, password, or playback data is transmitted. Your IP address is treated exactly as described above: no access logs, no storage of the address, and a rotating pseudonym for abuse protection only. The proxy queries OpenSubtitles (https://www.opensubtitles.com) with server-side credentials — you do not need an OpenSubtitles account. Subtitle files are cached both on the proxy and locally on your device to reduce requests.

The legal basis is our legitimate interest in the convenient display of subtitles (Art. 6(1)(f) GDPR). OpenSubtitles' own processing is governed by its privacy policy (https://www.opensubtitles.com). The Tunvio Project has no affiliation with OpenSubtitles.

Anyone can fetch the shared marks (see above). For them to exist, you can contribute voluntarily: when you skip an intro or move on to the next episode during the end credits, Tunvio sends that skip point, without any personal reference, to a service of our own at https://tmdb.tunv.io/skip. It runs next to the metadata proxy on the same server, which the Tunvio Project operates itself in Germany; no processor is involved and no transfer to a third country takes place.

Only with your consent. Sharing is switched off by default and does not depend on the "Usage data & crash reports" switch (Sections 6 and 7). After you have skipped an intro for the first time, the app asks you with a small prompt whether you would like to share — on a phone, tablet or computer briefly in the player, on a TV only after you leave the player, on the series view. If you do not answer, sharing stays off; after three unanswered prompts the app stops asking. Your consent applies to this device only and is not carried over to other devices by Device Sync (Section 10).

Only the following data is transmitted per contribution:

• the kind of mark (intro or end credits)
• the TMDB id of the series, the season number and the episode number
• the running time of the episode
• the skip point: for the intro, the position where you skipped and the one where you landed; for the end credits, the position where you moved on to the next episode

All times are rounded to whole seconds beforehand.

The following is expressly not transmitted: the title of the series or episode, your provider and its address, your profiles, the time at which you watched, and any device, installation or daily identifier. Skips you triggered via a mark that was already shared are neither sent back nor used for your own marks learned on the device.

Batched and delayed. The app first collects contributions on your device and sends them in a batch at most once a day — so not at the moment you are watching. For each episode and kind of mark, only the most recent observation is kept.

Your IP address is not stored. Like the metadata proxy, the service keeps no access logs. Your address is converted at the point of arrival into the same rotating pseudonym described above and used only to protect against abuse: for rate limiting, and so that one device can have only one contribution counted per episode within a day. For this check, a keyed hash of pseudonym and episode is held until the next key rotation and then discarded. The address itself is neither stored nor logged nor passed on, and neither it nor the pseudonym is written to the stored contribution. This protection rests on our legitimate interest (Art. 6(1)(f) GDPR, see Recital 49).

What is stored and published. For each contribution, the service stores only the values listed above and the day of receipt (without a time of day). A mark is published — that is, delivered to others when they fetch marks — only once several independent contributions received on different days agree, and even then only as a middle value (median) together with the number of contributions, never as an individual contribution.

Retention: individual contributions are deleted automatically after 180 days — physically from the database file as well, not merely marked as deleted. Only a mark per episode and running time that had already been published at that point remains, and only as its middle value, number of contributions and number of days of receipt, without any relation to an individual contribution; contributions to marks that were never published leave nothing behind. If enough new contributions from different days later contradict such a mark, it is deleted.

The legal basis is your consent (Art. 6(1)(a) GDPR, and § 25(1) TDDDG for accessing information on your device). You can withdraw it at any time with effect for the future under Settings → Data & Storage ("Share skip marks"). The withdrawal takes effect immediately: from then on nothing is sent, and contributions not yet sent are deleted on your device. Fetching shared marks is not affected.

Access and erasure: note on Art. 11 GDPR. A contribution that has been sent carries no identifier that would let us attribute it to a person or a device. Under Art. 11(2) GDPR we are therefore not in a position to identify you within this data set, and we can neither provide access to contributions already sent individually nor delete them selectively; to that extent the rights under Art. 15 to 20 GDPR do not apply. In any case they are deleted after 180 days at the latest (see above). Your right to withdraw consent at any time and your right to lodge a complaint with a supervisory authority remain unaffected.

On Android and iOS Tunvio retrieves a static configuration file from our server (https://tunv.io/app/config.json) when the app starts and when you run a manual check in the settings. On other platforms this retrieval does not take place.

The file contains information about the app itself only: the version currently available per distribution channel, the minimum supported version and the matching download or store addresses. No data about profiles, providers or content is transmitted.

Your IP address is not stored. The retrieval technically involves your device's IP address; it is not logged (no access log), not linked to any identifier and not stored.

The legal basis is our legitimate interest in a secure and up-to-date app (Art. 6(1)(f) GDPR).

Optionally, Tunvio can keep your profiles, favourites, watch history and settings in sync across your devices. This feature is switched off by default and only becomes active once you explicitly connect it under Settings → Device Sync. Where the data goes is decided by the storage destination you pick:

• On iOS the sync data is stored in your personal iCloud account (Apple), inside the app's own iCloud container.
• On Android it is stored in your personal Google Drive account, inside the app's hidden application-data folder (not visible among your regular Drive files).
• If you choose Microsoft OneDrive, you sign in with your own Microsoft account. Signing in works through a device code: the app shows you a short code that you enter on a Microsoft sign-in page — so you enter your Microsoft password with Microsoft, not in the app. The sync file is then kept in a folder of the app's own inside your OneDrive. Microsoft's sign-in page asks for access to the files in your OneDrive. That is the permission Microsoft requires for the app to be able to create its own folder in the first place; the app itself only ever uses that one folder. You can withdraw the permission at any time at account.live.com/consent/Manage.
• If you choose WebDAV, you decide entirely for yourself where the data is stored — for instance your own Nextcloud or a NAS at home. You enter the server address, the username and the password in the app. These details stay on your device — in your operating system's encrypted secret storage, where your platform provides one (see Section 12) — and are used for nothing other than connecting to precisely that server. Neither the Tunvio Project nor any third party receives them.

The data travels directly from your device to the storage you chose yourself — that is, to Apple, Google, Microsoft, or to the server you specified. The Tunvio Project does not operate a sync server and never receives this data. The synced data includes your configured IPTV profiles (in particular server URL and username) as well as the parental PIN, so that a restored device is usable again straight away.

The passwords of your IPTV accounts are deliberately not uploaded — to none of these destinations. They are removed from the data before it is transferred, because storage outside your device is not a place for secrets kept at rest; that applies to your own WebDAV server just as it does to iCloud, Google Drive and OneDrive. On a device that receives a profile this way, you enter its password once. Please note one technical limitation: with M3U, direct-URL and Stalker profiles the access data is part of the address itself (the playlist URL or the MAC address) and therefore inevitably travels with the profile — removing it would leave a profile with nothing that could be re-entered.

With iCloud, Google Drive and OneDrive all of this is stored exclusively in the private app area of your own account, which other apps cannot read; with WebDAV it is stored in the folder on the server you run or rent yourself. In the app you choose which categories are synced, and you can disconnect the sync at any time. After disconnecting, the sync file already uploaded remains in your storage; you can delete it yourself at any time (iCloud: Settings → your name → iCloud → Manage Account Storage; Google Drive: Settings → Manage apps → delete hidden app data; OneDrive: delete the app folder in your OneDrive; WebDAV: delete the file on your server).

The legal basis is your consent (Art. 6(1)(a) GDPR), which you give by actively connecting the feature and can withdraw at any time by disconnecting. Apple's, Google's and Microsoft's processing is governed by their own privacy policies (https://www.apple.com/legal/privacy, https://policies.google.com/privacy, https://privacy.microsoft.com/privacystatement). With WebDAV, processing is governed by the terms of whoever operates the server you specified — if you run it yourself, no further recipient is added beyond your own storage.

In addition — or as an alternative — Tunvio can keep your devices in sync directly on your local network, including on platforms without cloud sync (e.g. smart TVs). This feature is also switched off by default: you enable it under Settings → Device Sync and pair your devices once using a six-digit PIN. The paired devices then exchange the sync data (the categories described above) directly from device to device — end-to-end encrypted (AES-256) with a key stored only on your paired devices. Over this route the account passwords are transferred along with the profiles, precisely because this route does not involve any third-party storage: the data stays inside your own network, encrypted, between two devices that have authenticated each other.

The data never leaves your local network: no server and no internet connection is involved, and neither the Tunvio Project nor any other third party receives this data. The legal basis is again your consent (Art. 6(1)(a) GDPR), given by actively enabling the feature and pairing your devices; you withdraw it by unpairing devices or switching the feature off.

Settings, favourites and watch history are stored using the Flutter package shared_preferences in the app's internal storage. The access data for your profiles, the parental PIN and — if you use device sync — your WebDAV password or your OneDrive sign-in token are held in your operating system's encrypted secret storage (Android Keystore, iOS Keychain, libsecret on Linux); on Samsung Tizen, which provides no comparable storage, they fall back to the app's internal storage. The same secret storage also holds the household and device identifiers, as soon as you use device pairing (Section 5.1). Image caches and the TMDB metadata cache are stored in the app-specific cache directory. All of this is removed completely when you uninstall the app.

Recordings and downloads may be somewhere else. By default they are kept in the app's own storage area too, and disappear along with it. In Settings, however, you can choose your own destination folder for them — for instance on an SD card or in a shared media folder. Files saved there belong to that folder, not to the app: they remain in place when you uninstall Tunvio, and depending on the folder you picked and your platform's permission rules other apps may be able to read them. If you want them gone, delete them yourself. Either way the Tunvio Project has no access to them — these files never leave your device on our account.

Under the GDPR you have the rights of access, rectification, erasure, restriction of processing, data portability, and objection. For matters within the Tunvio Project's responsibility (in particular Firebase analytics and crash reports) contact support@tunv.io. You can also withdraw your consent to analytics and crash reports at any time, with effect for the future, directly in the settings (Data & Storage). You can delete locally stored data yourself at any time (Settings or uninstall). You also have the right to lodge a complaint with a data protection supervisory authority.

For the automatic reports sent to our own diagnostics server, the note on Art. 11 GDPR in Section 7 applies in addition: we store no attributable identifier there, so we cannot identify you within that data set. For a bug report you sent yourself this does not apply in the same way: it carries a reference number shown to you after sending, and with it we can locate and delete the report on request (Section 7.1).

For the pairing service in Section 5.1, Art. 11 GDPR applies just as much: there too we store no name, no account and no email address, and cannot identify you within that data set. Unlike with the diagnostics server, however, you do not need us for it — it is the only data set of ours carrying a lasting identifier, and you see all of it in the device list in the app (Settings → About). Access and erasure are therefore something you exercise there directly yourself instead of requesting them from us.

This privacy policy may be updated when future changes to the app warrant it. The current version is always available at https://tunv.io/privacy-policy and in the app under Settings → About → Privacy Policy.