Remaster AI Privacy Policy

1. Videos and enhancement

We process the video you select, including its audio and visual content, and technical properties such as duration, dimensions and file size to provide the enhancement you request and calculate its credit cost. The app lets you select and trim a video; it does not upload your entire photo library.

Third-party AI service providers process selected video content. Every new video is enhanced to up to 4K by WaveSpeed, which runs the FlashVSR upscaling model. Saved older jobs retain the providers they originally used, including fal.ai, which upscaled some videos until October 2026 and also provided colorization and frame interpolation; fal.ai no longer receives new videos. Supabase provides authentication, job coordination and private temporary media storage. After you consent as described in this paragraph, and before your video is uploaded, still frames from the range you selected (about one every 2 seconds) may also be sent to OpenAI for an automated content check, as described below. Before your first upload, the app identifies the providers used for enhancement, explains the video and technical details being shared, and asks for your explicit consent to share the videos you choose to enhance with those third-party AI service providers for processing. The app keeps your consent on your device and does not ask again for later videos; it asks again if the providers or the shared details it describes change, after you reinstall the app, or after you withdraw your consent. You can withdraw it at any time with the “Share videos with AI providers” switch in App Settings > Privacy; withdrawing it does not affect videos already uploaded. If you cancel or dismiss the dialog, the upload does not start.

The video files at these providers expire after up to 7 days (WaveSpeed documents this period; for older jobs at fal.ai, we set it). Other provider records, such as request logs and backups, may be kept longer under each provider’s own terms, described below. We also keep the video you uploaded in our private Supabase storage for 7 days after the app finishes preparing your enhanced video, then delete it; if that never happens, we delete it when the 30-day window described under Retention in Remaster AI ends. During those 7 days we may review your video and its enhanced result, in the providers’ dashboards or our own tools, to check and improve enhancement quality. The app tells you this before you agree to share a video.

Remaster AI does not process videos that contain material flagged by a content checker. Only after you consent to share a video, and before it is uploaded, the app may send small, downscaled still frames, about one every 2 seconds, taken only from the range you selected, through our servers, to OpenAI’s moderation service, which checks them for categories such as sexual and graphically violent content. According to OpenAI’s API data policy, data sent to its moderation endpoint is not used to train its models and is not retained for abuse monitoring. We keep these frames, with their position in the video and their check results, in our private Supabase storage for up to 7 days, then delete them. During that time we may review them, to confirm the check’s decision when frames are flagged and to check enhancement quality when the video is enhanced. Apart from that review, the scores are used only to stop a flagged video and to choose which section of the video is sent for enhancement first; that order is saved with the job. If OpenAI’s service is unavailable and too few frames have been flagged, the video continues without this check. If this check stops a video, the video is not uploaded and no credits are used, and the message names the reason when the check reports one (sexually explicit or graphically violent content); if you have allowed analytics, the app records only that a video was stopped, that reason category, and how many frames were checked and flagged; the frames and their scores are never sent to our analytics. Our AI service providers may also scan the videos they process with automated content checks and reject videos they flag. A rejected video is not enhanced, and the credits it used are refunded automatically; copies held by the provider follow the provider terms described below.

2. Identifiers, purchases and service records

No name, email address or user-created password is required to use the app. An automatic authentication session and a randomly generated app/device ID associate your jobs and credits with your installation. These identifiers and a recovery credential help restrict access, recover the app identity and investigate problems. They are pseudonymous identifiers, not a guarantee that all collected information is anonymous. On iPhone, the app also keeps this ID and the recovery credential in the iOS Keychain, which iOS usually keeps after you delete the app. On Android, it keeps them in Google’s Block Store, part of Google Play services, which keeps them after you delete the app when Google backup is turned on and, when end-to-end encryption is available on your phone, also backs them up to your Google account so that they can be restored on a new phone; the app’s other data is excluded from Android backups and device transfers. Either way, reinstalling the app on the same device restores the same ID and your credits and prevents one-time offers from being claimed again. To have the ID and its records deleted, contact us as described below.

RevenueCat and the store you buy through, Apple’s App Store on iPhone or Google Play on Android, process in-app purchase information. We use purchase history, product and transaction identifiers, subscription status and credit balances to deliver purchases, verify access, restore eligible purchases and reconcile charges or refunds. Apple or Google handles payment details; the app does not request your payment-card number.

Job records include processing status, timestamps, selected duration, model, credit use and technical errors. They support progress tracking, retries, billing and troubleshooting. Service providers also receive connection and device information, such as IP addresses and software details, when your device contacts them.

3. Optional analytics, crash reports and screen recordings

If the app’s Settings show the switch “Share analytics & screen recordings”, your version asks for your choice, as described in this section. When you first open such a version, the app tries to delete any usage events, crash reports and screen recordings that earlier versions had not yet sent; data that earlier versions already sent is not affected.

Earlier versions, which do not show this switch, send usage events and crash reports, linked to the app’s random ID, without asking, and screen recordings while recording is switched on for our PostHog project. Our servers treat enhancement jobs started from those versions as if you had not allowed analytics. For those versions we rely on our legitimate interest in understanding and fixing problems in the app; you can object at any time by emailing hello@keremcebi.co, and we will delete the analytics data linked to your app ID (the app’s Settings show the ID) — or update the app once the new version is available.

Analytics, crash and error reports, and screen recordings (session replay) are optional for everyone, wherever you live. At the end of the introduction screens, the app asks “Help improve Remaster AI” and offers two equal buttons, Allow and Don’t Allow; if you had already finished the introduction before this version, it asks on the home screen instead. Until you tap Allow, or turn on the “Share analytics & screen recordings” switch in App Settings > Privacy, the app does not start PostHog and makes no connection to PostHog: it sends no events, crash or error reports or screen recordings, and does not download PostHog’s settings. If you tap Don’t Allow or close the question, the app sends nothing to PostHog; only a rating of a result that you choose to give is sent to our servers, which store it and pass it on to PostHog only under a code that only we could trace back to the video, without any identifier that PostHog could link to you, as described below. Events and errors that occur before you allow are discarded, not sent later. The app keeps your answer only on your device; until it has an answer, including after an update, it treats analytics as not allowed. You can change your choice with that switch at any time. The switch shows whether sharing is off, on, or on with a screen recording in progress. Your choice does not affect any feature, enhancement or purchase. The optional thumbs-up and thumbs-down rating of a result is shown to everyone. Whatever you choose, every rating is stored on our servers and sent to PostHog only under such a code, without any identifier that PostHog could link to you; your choice only decides whether the app also sends PostHog the rating linked to the app’s random ID (if you allow analytics).

Once you allow, the app starts PostHog straight away, links what it sends to the app’s random ID, and from then on sends usage events so we can understand how the app is used and find and fix problems: app lifecycle and screens viewed (when you first allow, PostHog may also record that this version of the app was installed or updated); the steps of an enhancement and their timings, with technical properties of the selected video such as duration, resolution, frame rate and file size; your thumbs-up or thumbs-down rating of a result and the reason you select; and paywall and purchase events covering the product identifier, its price and currency, and whether a purchase completed, was cancelled, is awaiting approval or failed. Each event includes device and app details such as device model, operating system (iOS or Android) and its version, app version, language and time zone. Payment details are never included. Crash and error reports contain technical details such as the error type, its message, the stack trace and the app version.

If you allow, the app also makes screen recordings, but only in published versions of the app, only while screen recording is switched on for our PostHog project, and only if analytics were already allowed when you opened the app. If you allow analytics while you are using the app, recording can start only the next time you open the app, and App Settings says so. Screen recordings show how the app’s screens are used: the screen layout, colors, animations, tap positions and screen names. Before a recording is uploaded, the app masks text, images, icons and videos on your device, and it does not capture native system screens, such as the photo picker, App Store or Google Play purchase sheets and the share sheet. Recordings contain no console logs or network requests. PostHog keeps screen recordings for 30 days.

Events, crash reports and recordings are linked to the app’s randomly generated ID, not to your name, email address or an account, so they are pseudonymous, not anonymous. Recordings made by versions that ask for your choice may be analysed automatically by AI: two PostHog Replay Vision scanners send these masked recordings to Google’s Gemini models, which may run outside the European Union, to find usability problems, such as broken screens and moments of frustration. When PostHog receives data from the app, it derives an approximate location (country, city, postal code and approximate coordinates) from your IP address and then discards the IP address. PostHog stores this data in the European Union.

When you create an enhancement job or resume its upload, the app tells our servers whether you have allowed analytics. If you have, the app also sends our servers its PostHog identity (the app’s random ID) and its PostHog session ID for analytics, and our servers send PostHog processing-time records linked to them: job, segment and provider request identifiers; the provider and model used; the video’s duration, dimensions, frame rate, frame count and file sizes; how long each step took; retry counts; and the outcome. Error reports about creating such a job, about an automatic retry that processes such a job’s video in one go, and about the app reporting that it could not finish preparing your video (including the reason the app gives, the lengths it measured and its attempts) are also linked to the app’s random ID, the job and the session. Error reports about the app loading your list of jobs while analytics are allowed are linked to the app’s random ID only, not to a job or session.

If you turn analytics off, the app at once stops any screen recording in progress, switches PostHog off and stops sending events. It also tells our servers, usually straight away; otherwise, the next time it loads your jobs. From then on, your jobs stop sending processing-time records, and their later error reports are no longer linked to the app’s random ID, the job or the session. Resuming an upload, rating its result, or the app reporting that it could not finish preparing a video, while analytics are off has the same effect for that job. If you turn analytics back on, only new jobs send processing-time records; a job created, or later withdrawn, while analytics were off never sends them again. Error reports about a request the app makes for such a job while analytics are on (for example resuming its upload or reporting that its video could not be prepared) are linked like other reports made while analytics are on.

If you have not allowed analytics, the app does not tell our servers to link your jobs to analytics (it sends no consent signal, no PostHog identity and no PostHog session ID), and our servers send PostHog no processing-time records for those jobs. They still send operational error reports when something fails on our servers, so that we can keep the service running. Those reports, and every other server error report not described above (for example from our background job checks and the automated content check, even when you have allowed analytics), are filed under the name of the server function and contain no field holding a device ID, job ID, session ID, provider request ID or other identifier. In the error text, IDs in the standard UUID format, long hexadecimal codes such as provider request IDs, and the paths of web addresses (the site name is kept) are replaced with placeholders, and web-address parameters, access tokens and email addresses are removed. The reports contain the error type; the error message, cleaned in this way; where in our server code it occurred; the error level; the HTTP status and method; the error message the app received; which of our server projects and environments it came from; and operational values, such as length-check values; for the automated content check, counts such as frames sent, answered and flagged, the reason category, whether the video was stopped and the moderation service’s response status — never the frames or their scores; for an automatic retry, details such as what triggered it, the model, the video’s duration and the billing status; and, for a video the app could not finish preparing, details of our server’s decision, such as whether the job was refunded, whether our server confirmed the failure itself, whether the refund limit applied, and the billing status. Each report has a random report number, which only our own server logs connect to a job.

Whatever you choose about analytics, when you rate a result the app sends our servers your rating (thumbs up or thumbs down) and, after a thumbs-down, the reason you pick from a fixed list (never text you type), together with the job ID, the app’s random ID and the time on your device when you rated. Our servers use the job ID and the app’s random ID only to check that the video is yours and finished, to compute the video’s code and look up the general facts about it listed below and, if you have not allowed analytics, to withdraw a consent stored on that job, as described above; neither is stored with the rating. If a rating request fails, the error report about it contains neither the app’s random ID nor the job ID or a session ID. Each video has one rating: changing it replaces the earlier one, and earlier ratings are not kept in our database (the PostHog events already sent for it remain, as described below). We store every rating in our Supabase database under a code computed from the video with a secret key; it is stored without the app’s random ID, the job ID, a session ID or your IP address. With the rating we store general facts about the enhancement (the enhancement type, which is 4K, or for a video from an earlier version of the app the quality mode it used, which provider enhanced the video, its output size class, for example 1080p or 4K, its length range, for example 30 to 60 seconds, and whether it was processed in parts), whether you had allowed analytics when you last rated, a revision number based on the time of the latest change, the time on your device when you last rated (used only to put a video’s ratings in order), when the record was created and when its rating last changed, and whether, how many times and when we have tried to send it to PostHog. When a video’s rating changes, our servers send PostHog one event with its current state: the same code, its revision number, the rating, the reason (if any), the rating it replaced (when sent straight away), whether you had allowed analytics, the general facts above and technical labels such as which of our environments sent it and whether it is a retry (with its attempt number), with a new random ID each time. Changes made within 10 seconds of the previous one are sent together a few minutes later as one event with the latest rating; if PostHog is unavailable, our servers try again, with up to 10 attempts in all over at least about 28 hours (longer if our background checks are delayed), and an event sent later is dated at the time of the latest change. The event never contains the app’s random ID, the job ID, a session ID, your IP address, the exact length or the price. From the code, PostHog cannot work out the video, the app’s random ID or your other videos. Our team’s internal review tool recomputes, with our key, the code of each video it shows from its job ID, so that when we check enhancement quality we see the video’s current rating and reason next to the video, its enhancement details and the app’s random ID; a rating last changed before this change to the policy was published on October 12, 2026 is not shown there. Otherwise we recompute a video’s code only to delete ratings at your request or to change the key. Neither the key nor the job ID is ever sent to PostHog, so PostHog still cannot link a rating to the video or to you. If you allow analytics, the app also sends PostHog its own rating events, linked to the app’s random ID, as described above. Like every request to our servers, the request that carries a rating is recorded, with its time and the app’s sign-in session, in the request logs of our hosting provider, Supabase, and the database requests it causes are recorded there with the job ID and the app’s random ID; we do not combine those logs with the ratings.

All of these server records are sent from our servers, not from your device, so PostHog does not receive your IP address with them, and PostHog does not build a user profile from them. They never contain your video, its frames or audio, or payment details. We use the processing-time records and linked error reports only with your consent, and the error reports without identifiers based on our legitimate interests in operating the service and fixing failures, and we store the ratings and send them to PostHog only under the video’s code, without any identifier that PostHog could link to you, whatever you choose about analytics, based on our legitimate interest in checking and improving enhancement quality.

4. Notifications and support

Firebase Cloud Messaging (on iPhone, together with Apple Push Notification service) uses installation identifiers and push tokens to deliver job-status notifications. You may decline notifications or change permission in iOS Settings or Android Settings; on Android 13 and later, the app asks for permission to send notifications. Disabling notifications does not prevent video enhancement and does not itself request deletion of identifiers already held by a provider. To send notifications in your language, we store the app’s language, and whether your phone runs iOS or Android, with your push token. On Android, while the app uploads or finishes preparing a video, Android shows a notification for as long as that work runs.

When you contact support, we receive your email address, message and any information you choose to send. We use it to answer your request. If you use the feedback form in App Settings, we receive your message, the contact email you enter (optional), your Device ID, device model (on Android, its manufacturer and model), operating system (iOS or Android) and its version, app version and language, and a list of your recent jobs; this is stored in our database and emailed to us through Resend. The Netlify-hosted support website may generate connection and security logs to deliver pages and protect the service. We do not sell personal information.

5. Legal bases

Where data-protection law requires a legal basis for processing, we rely on the following:

• Performing the service you request: enhancing the videos you select, delivering purchases and credits, and keeping the job records this requires.
• Your consent, in versions of the app that ask for your choice: optional analytics (including the rating events the app sends linked to its random ID), crash and error reports and screen recordings; the processing-time records and linked error reports our servers send to PostHog for jobs created while you allowed analytics; and error reports about loading your job list while you allowed analytics. You can withdraw your consent at any time with the “Share analytics & screen recordings” switch in App Settings > Privacy; withdrawing it does not affect processing carried out before then.
• Our legitimate interests: keeping the service secure and preventing fraud and abuse (including restoring the app’s ID after a reinstall); the automated content check; operating and troubleshooting the service (including the error reports without identifiers that our servers send to PostHog, and internal job reports); understanding and fixing problems in the app through the usage events, crash reports and screen recordings sent by earlier versions of the app that do not ask for your choice; answering feedback and support messages; and checking and improving enhancement quality by reviewing uploaded videos, results and checked frames during the 7-day review period, and through result ratings, which we store and send to PostHog only under the video’s code, without any identifier that PostHog could link to you, whatever you choose about analytics. You can object to this processing; see “Your choices, rights and deletion requests”.
• Legal obligations: keeping purchase and tax records.

6. Retention in Remaster AI

Temporary enhanced files in our Supabase storage are deleted when successful on-device finalization is confirmed. The video you uploaded is kept for 7 days after that confirmation so we can review enhancement quality, and is then deleted automatically. Still frames sent for the automated content check are kept for up to 7 days after the check, whether or not the video is enhanced, and are then deleted automatically. If you do not finish preparing the result, a 30-day access window starts when all enhanced segments become ready. Automatic cleanup runs after that deadline. Failed jobs also trigger temporary-media cleanup. Scheduled cleanup or retries can take additional time; the 30-day window starts at readiness, not at upload.

The finished video and local comparison clip are stored in the app without a scheduled age-based expiry. The finished video is not uploaded back to our cloud storage. Saving to Photos (on Android, to your phone’s gallery) creates a separate copy. On iPhone, local files and Photos copies may be included in device backups or iCloud according to your Apple settings. On Android, the app’s own files are excluded from Android backups and device transfers, but gallery copies may be backed up by Google Photos or another app according to your settings. Our media cleanup does not delete those copies.

Server-side identity and job records do not have an automatic age-based expiry in the app. Identity, purchase, credit, job, support and feedback records are retained for service continuity, unused credits or subscriptions, recovery, troubleshooting, billing and applicable legal requirements. They are not erased by the 30-day media cleanup. Result ratings stored in our database have no fixed retention period; they are kept until they are deleted, for example at your request. The local performance log is limited to the latest 500 entries. PostHog keeps analytics events, crash and error reports and the technical records our servers send for up to 7 years, the data-retention period of our PostHog plan, and screen recordings for 30 days; provider logs follow each provider’s own schedule.

For records without a fixed period stated here, retention depends on the continuing service or legal need, the relevant provider settings and any applicable deletion request. Contact us for information about your records or to request deletion.

7. Provider retention and backups

Deleting data from an active service does not always immediately remove older backup or archival copies. The periods below describe published provider rules, not a single retention period for all Remaster AI data. Our temporary-media cleanup does not control independent provider records or backups.

8. Service providers and international transfers

We share data with the service providers named in this policy only so that they can provide their services to us. Each provider handles the data under its own contract or terms; where those terms allow wider use or longer retention, its entry above says so.

These providers are located in the European Union, the United States and other countries. PostHog stores analytics data in the European Union. Supabase stores our database and temporary media in the region configured for our project. WaveSpeed, fal.ai (older jobs), OpenAI, RevenueCat, Google (Firebase and, on Android, Block Store), the Google Gemini models used by PostHog, Resend and Netlify may process data in the United States or other countries; each provider’s own terms describe where it processes data.

Where the law of your country requires a transfer mechanism for sending personal data abroad, for example the GDPR in the European Union and European Economic Area, the UK GDPR, Brazil’s LGPD, Saudi Arabia’s PDPL, Japan’s APPI or Korea’s PIPA, transfers rely on the safeguards our providers offer, such as standard contractual clauses, or on another basis that law allows.

9. Your choices, rights and deletion requests

You can choose which video to submit, decline the third-party AI data-sharing consent before upload, turn optional analytics, crash reports and screen recordings on or off at any time with the “Share analytics & screen recordings” switch in App Settings > Privacy (earlier versions, which do not show this switch, send analytics without asking: to object, email hello@keremcebi.co and we will delete the analytics data linked to your app ID, or update the app once the new version is available), and manage Photos and notification permissions in iOS Settings, or notification permission in Android Settings (on Android, you choose videos in the system photo picker and the app saves results to your gallery without asking for access to your photos or storage). Copies you save or share are controlled by you and the destination service.

To request access, correction or deletion, email hello@keremcebi.co. Include the Device ID displayed in App Settings so we can locate the associated records. No registered email address is required. We may ask for information needed to verify that the records belong to you; please do not send passwords or payment-card details.

We assess requests and arrange deletion of eligible records with the relevant providers. Some records may need to remain for legal obligations, dispute resolution or other permitted purposes, and provider backup deletion may take additional time. We will explain applicable limits when responding. Removing local files or uninstalling the app does not itself erase server or provider records, or the ID kept in the iOS Keychain or Google’s Block Store. Manage active subscriptions separately: in your Apple account settings on iPhone, or in Google Play on Android.

Depending on where you live, you may have the right to access, correct or delete your data, to object to processing based on our legitimate interests, to data portability and restriction of processing, to withdraw your consent at any time without affecting earlier processing, and to complain to the data protection authority in your country. To exercise your rights, contact hello@keremcebi.co.

10. Security and policy changes

We use authenticated requests, access controls for private media, and protected recovery credentials to limit access.

This policy may change as the app or its providers change. We will publish revisions here and update the date above. Contact hello@keremcebi.co with questions about this policy.