← Time To Swipe

Privacy policy

Last updated 24 September 2026

Ce document est publié en anglais. Le reste de ce site est traduit pour votre confort de lecture ; pour la politique de confidentialité et les conditions d'utilisation, le texte anglais fait foi.

Who we are

Time To Swipe is a photo clean-up app for iPhone and Android, published by Havra LLC, a limited liability company formed in the State of Florida, United States. Havra LLC is the controller of the small amount of data described below. To reach a human about anything on this page, write to support@timetoswipe.app.

This policy covers the Time To Swipe mobile apps and the website at timetoswipe.app. It was first published on 1 September 2026, and this version takes effect on 9 September 2026. It is written to be read, not to be survived.

Every network request the app makes

Setting advertising aside for a moment — it has its own section below, and it is the larger part of what leaves the device — the app itself makes three kinds of request, and this is the whole list.

One. GET https://timetoswipe.app/v1/config.json — a static settings file holding the free-tier limits. No query string, no request body, no cookies, no identifier of any kind attached: it is the same request from every copy of the app. It runs at most once every six hours, and if it fails the app keeps using the values built into it. The numbers it carries include the 100-swipe welcome every new install receives; the app issues that grant itself, from this file or from its built-in default, without asking anyone.

Two. Requests to RevenueCat, the purchase-management service described under "Purchases". Its SDK asks RevenueCat’s servers whether this install holds a paid tier, and when you buy or restore it sends the store’s receipt or purchase token. Every one of those requests carries a random anonymous identifier generated on this install, and nothing that names you. RevenueCat’s SDK makes them rather than our own code, but it makes them on our behalf and for our purposes, so they are ours to list.

Three. Requests to Google’s Firebase services — Analytics and Crashlytics — which begin only after you have accepted the terms on first launch and are described under "Analytics and crash reports". They carry a random per-install identifier that Firebase generates, the named usage events and crash reports listed there, and nothing about your photos or about you.

As with every HTTP request from any app, all of these reveal your IP address to the machine answering them, and the hosts record it in ordinary server logs. Nothing in our code reads it, no decision is made on it, and it is never joined to anything else. Google uses the address of a Firebase request to derive a country and region for its reports and does not show us the address itself.

And a fourth kind, which is not ours. If a photo you are looking at lives in iCloud rather than on the device, the app asks PhotoKit for it and permits PhotoKit to fetch it — that is the thumbnail on the card, the full-resolution image in the zoom view, a video you play, and the file size and EXIF fields in the info sheet. The download runs between your device and your own iCloud account, is performed by Apple’s code and not ours, and brings your photo onto your phone. Nothing travels outward, nothing reaches us, and no equivalent path exists on Android, where MediaStore serves what is already on the device.

Advertising adds traffic made by third-party SDKs rather than by our code. We do not see it, and we cannot enumerate their requests the way we can enumerate ours. What the ad networks collect is set out under "Advertising".

The welcome grant, and why no server is involved

Every new install starts with 100 free swipes. The app issues them itself, reading the number from the settings file or from its built-in default, and tells nobody. No request is made to claim them, no identifier is read, hashed or sent, and nothing about your device is recorded anywhere to stop it happening twice. We considered an anti-abuse check and decided that a gift this small does not justify collecting anything to protect it: reinstalling simply gets the gift again.

Earlier versions of this policy described a once-per-install request to a server of ours that decided the size of the grant and kept a hashed, per-device record on Android to do so. That server has been shut down and its database deleted. No current version of the app makes the request; an older version that still tries receives no answer and issues the full grant on its own.

What we hold on our side

Nothing that names you. We operate no database and no server of our own: the website and the settings file are static files served by Vercel, the same to everyone, and the app never sends us a photo, a name, an email address or anything you typed. There is no account table, no per-device record and no per-install record of ours.

The only thing that exists on our side is the ordinary access log Vercel keeps for the website and the settings file — IP address, timestamp, requested path, user agent — for the operation and security of the service, in the way every web server does. We do not read, aggregate or analyse it, we do not join it to anything, and Vercel retains it on its own short schedule.

What does exist on our side is the Firebase project Google runs for us, which holds the usage events and crash reports described under "Analytics and crash reports" — keyed by a random identifier that Firebase generates on each install and that we cannot connect to a person. We see it as dashboards and crash reports, and that is the one place data about your use of the app sits with us.

Retention, and how deletion works

There is nothing of ours to retain, so there is nothing of ours to delete. Uninstalling the app removes everything it kept on your device — your review history, your pending deletions, your settings, your swipe balance and the record of a purchase — immediately and completely. Nothing survives on our side, because nothing was ever sent to it.

What outlives an uninstall belongs to others, and is described in their sections: the store keeps its record of any purchase, RevenueCat keeps the anonymous entitlement record for as long as it manages purchases for us, and the ad networks keep what their own policies say they keep.

Your photos

Time To Swipe reads your photo library through the operating system’s own photo APIs — PhotoKit on iOS and MediaStore on Android — and only after you have granted permission through the system permission dialog. On iOS you may grant access to selected photos only, and the app works normally with that restricted set.

Photo data is read into memory to draw a card on screen and released when the card leaves the deck. No photo, no thumbnail, no EXIF field, no capture date and no location tag is ever transmitted off the device, to us or to anyone else. This is not a promise about intent: the app contains no code that uploads image data, the two requests above are the only ones it makes itself, and the ad and purchase SDKs share no data path with the photo layer.

On Android the app holds the ACCESS_MEDIA_LOCATION permission so the info sheet can show you where a single photo you are looking at was taken. That lookup happens on the device, for one photo at a time, at the moment you ask for it. It is never run over your library in bulk, and the result is never transmitted.

What the app keeps on your device

So it does not show you the same photo twice, the app stores a list of the photo identifiers you have already reviewed, a queue of photos you have marked for deletion, your filter settings, your swipe balance and when it next refills, your lifetime counters, and the cached settings file. All of it lives in the app’s own private storage, readable by no other app.

There is also a diagnostic log: at most 500 recent events — things like "a swipe was committed" or "a config fetch failed" — written to a capped file on the device so it cannot grow. It exists so a problem can be looked at on a phone in front of you. It is never transmitted, and the app contains no mechanism to transmit it.

The app’s data files are marked as excluded from iCloud backup on iOS, and Android’s backup is switched off for the app, so this state is not copied off the device that way either. Deleting the app deletes all of it.

Deleting photos

Swiping never deletes anything. Swiping left adds a photo to a pending list, and that list only becomes a deletion when you confirm it and your operating system presents its own delete confirmation dialog. That system dialog is the only mechanism the app uses to delete, on both platforms.

Confirmed photos are moved to Recently Deleted on iOS and to the Trash on Android, where they remain recoverable for 30 days. The app cannot empty Recently Deleted or the Trash, and does not try to — which means your storage is not fully reclaimed until you empty it yourself in the Photos or Gallery app.

Once a batch is confirmed the app offers a button that opens an app already on your phone — the Photos app at Recently Deleted on iOS, the Google Photos bin on Android — so you can empty it yourself. It is a handoff, not a transmission: nothing about you or your photos travels with it, no browser is opened, and the button is hidden entirely when that destination is not present on the device. The only other place the app can send you is your own system settings screen, for changing the photo permission.

Analytics and crash reports: Firebase, after you accept the terms

Until version 1.0.1 on iOS and 1.0.7 on Android this section said we had no analytics at all, and it was true. From 1.0.2 and 1.0.8 the app uses two Google services, Firebase Analytics (Google Analytics for Firebase) and Firebase Crashlytics, so that we can see how the app is used in aggregate and fix crashes we would otherwise never hear about. Google processes this data on our behalf; it is ours, not Google’s to use for itself.

When it starts. Neither service is started until you accept the Terms of Use and this policy on the first-launch screen. Before that the app makes no Firebase request of any kind. Once accepted, both start with every later launch.

What the app sends. Named usage events, each with three properties — days since install, the version of the settings file, and which stage of the free tier you are in: a session starting and ending, with the number of swipes and the storage queued for reclamation in that session; the out-of-swipes screen appearing; a rewarded video being offered, watched or declined; the purchase screen appearing or being dismissed; a purchase completing, with the product name and nothing about payment; a banner or full-screen ad being shown; and the settings file failing to download. That is the whole list. No event carries a photo, a photo identifier, a filename, a name, an email address, a phone number, or anything you typed.

What the Firebase SDKs collect on their own. A random identifier Firebase generates for this install (the “app-instance id”); the device model, operating system version, app version and language; the country and region Google derives from the request’s IP address; when the app was first opened and when each session started and ended. Crashlytics additionally records, when the app crashes, the stack trace, the device’s state at that moment (free memory, orientation, whether it was in the foreground), a per-session identifier, and the app’s own recent events as breadcrumbs. Both send this only to Google’s Firebase servers, in our project.

What it is not. We deny Google’s advertising-storage, ad-user-data and ad-personalisation consent flags for every user, on every launch, so Firebase is configured for measurement only: it is not linked to any advertising account of ours and is not used to build a profile or to target you. The advertising identifier is the ad networks’ business, described under "Advertising", and is not what Firebase is keyed on.

How long. Google keeps crash reports for 90 days and analytics event data for the period set in its standard retention controls, after which only aggregated reports remain. We do not export it anywhere else.

Stopping it. There is no switch for it in the app, and we would rather say so than hide it in a settings screen: it runs for every user who has accepted the terms, paying or not. Uninstalling the app ends collection, and reinstalling generates a new identifier with no link to the old one. Google’s own privacy commitments for these services are at https://firebase.google.com/support/privacy.

The honest qualification, unchanged: the ad SDKs — Start.io, Google AdMob and Unity Ads — each collect their own crash data and diagnostics and their own record of how you interacted with an ad, and RevenueCat keeps its own record of purchase and restore attempts. That is theirs, not ours — we never receive the ad data, and RevenueCat’s is described under "Purchases". The app also keeps a capped 500-entry copy of its own events on your device, for its own use; it goes nowhere else.

What we deliberately do not do

We build no device fingerprint. Nothing in our code combines model, screen size, locale, timezone, carrier, battery or installed fonts into an identifier; that is a technique Apple prohibits and we would not want it anyway. No decision anywhere in our service is made on your IP address. We buy no data about you, and we join nothing to anything from another source. There is no user account to attach any of it to even if we wanted one.

What we can no longer say: that no advertising identifier is read. The ad SDKs read the advertising identifier — the IDFA on iOS, where you have allowed tracking, and the Google Advertising ID on Android. It is the ad industry’s own resettable identifier, it belongs to the operating system rather than to us, and we never receive it. "Turning ads off" below explains how to reset it, refuse it, or remove the SDKs.

Advertising

The free tier is paid for by ads. Three ad networks supply them, and the app tries them in a fixed order — Start.io first, then Google AdMob (the Google Mobile Ads SDK), then Unity Ads — moving on only when the one before has no ad to show. Each is an independent controller of what its SDK collects, not a processor acting on our instructions: we choose to put them in the app; we do not direct what they do with what they gather. Their own policies are the authority on that, and you should read them if this section matters to you. Start.io: https://www.start.io/policy/privacy-policy/. Google: https://policies.google.com/privacy, and https://policies.google.com/technologies/partner-sites for what Google collects inside apps that use its services. Unity: https://unity.com/legal/privacy-policy, and for Unity Ads specifically https://unity.com/legal/game-player-and-app-user-privacy-policy.

Where the ads appear: a banner on the swipe screen, an interstitial after a deletion batch is confirmed or when the deck runs out, and a rewarded video you can choose to watch for 100 more swipes whenever your balance reaches zero — as often as you like. The rewarded one is always optional and there is always another way to continue.

What the networks collect. Taken from each SDK’s own privacy manifest and the permissions it adds to the app, rather than from marketing. Any of the three may read the advertising identifier (the IDFA on iOS, where you have allowed tracking; the Google Advertising ID on Android), your IP address and a coarse location derived from it, device and operating-system details, how you interacted with its ads, and its own crash and diagnostic data. Ordinary request metadata — device model, operating system version, screen dimensions, language, country, connection type, and the app’s package name and version — reaches each of them as well, as it would any ad network. Google’s SDK additionally declares performance data, and links what it collects to the advertising identifier. Start.io’s manifest goes furthest: besides the above it declares precise location and a category it labels only as other data types, it declares the advertising identifier and both location types as used for tracking, and on Android its SDK also registers for the Privacy Sandbox Topics permission, through which the operating system can offer apps coarse interest categories. Asking every network for non-personalised ads limits how they may use any of this; it does not shrink what they may collect.

Precise location deserves saying out loud rather than leaving in a list. Start.io declares that it collects it for advertising. It can only read a location your operating system has already granted, and Time To Swipe never asks for location permission for itself — so if you have never granted location to this app, there is none for it to read, and what any network can derive is the coarse location that follows from an IP address. On iOS, Apple merges each SDK’s disclosure into ours, which is why the App Store privacy label for a camera-roll cleaner names precise location and says it is used to track you. We would rather you learned that here than from the store listing.

What no network ever receives: any photo, any thumbnail, any EXIF field, any capture date, any location tag read from a photo, any swipe decision, any count of what you deleted or kept, and any of the statistics the app shows you. The ad SDKs and the photo layer share no data path. The app has no upload code for image data of any kind, which was true before ads and is still true.

Personalisation is off, for everyone, on every network. Before any of the three serves an ad it is told that you have not consented to personalised advertising, unconditionally and everywhere in the world: every request to Google carries its non-personalised-ads flag, Start.io’s consent flag is set to no, and Unity Ads is set to contextual ads only. You get contextual, non-personalised ads. If that ever changes, consent will be collected properly first, and this policy will say so before the version that does it is released.

There is one consent prompt, and it is worth being precise about what it does. Google will not serve any ad — personalised or not — to anyone in the European Economic Area, the United Kingdom or Switzerland unless a Google-certified consent flow has been shown, so in those places the app shows Google’s own User Messaging Platform prompt, the standard IAB TCF message, the first time ads could appear and after you have accepted our terms. In US states with privacy laws that reach advertising it shows Google’s "do not sell or share" message instead — offered even though, with personalisation off, we do not sell or share in the CPRA sense. Your answer decides one thing: whether Google AdMob is asked for an ad at all. It does not turn personalisation on, and it does not affect Start.io or Unity Ads, which are not Google demand and are asked for non-personalised ads either way; decline, and AdMob is simply never asked while the other two still serve. The prompt is Google’s code: it asks Google’s servers whether a message applies to your region, which shows Google your IP address, and it stores your answer on the device as a standard consent string that accompanies AdMob requests. A Privacy options entry in the app’s Settings, shown to anyone who has been given the choice, reopens the form so you can change your answer.

On iOS, the app also lists the SKAdNetwork identifiers of all three networks. SKAdNetwork is Apple’s attribution mechanism: when an install follows an ad, Apple itself sends the network a postback saying that a campaign led to an install. The postback carries no user identity and nothing from the app, it works the same whether or not you allow tracking, and it identifies nobody.

Turning ads off, and turning the identifier off

Buy a tier that removes ads. This is not a setting that hides them: a user with an entitlement is handed a different object internally, so none of the three ad SDKs is ever constructed and none of them starts. They collect nothing, because they are not running.

On iOS, the app asks for permission to track before any tracking identifier is used, through Apple’s own App Tracking Transparency prompt. Decline it and the IDFA is not available to any of the ad networks. Declining changes nothing else — the same ads appear, the same features work, and no part of the app is gated behind allowing it. You can change the answer later in Settings, Privacy and Security, Tracking.

On Android, you can delete or reset the advertising identifier in Settings, Privacy, Ads. Deleting it means apps receive no advertising ID from the system at all.

On both platforms you can also reset the identifier periodically, which breaks the link between what an ad network knew about the old one and the new one.

If you were shown Google’s consent prompt, the Privacy options entry in the app’s Settings reopens it, so a choice made once is not a choice made forever.

Purchases

Time To Swipe has no payment system of its own and never asks you for payment details. Any paid tier is sold and billed by the App Store or the Google Play Store — through Apple’s StoreKit on iOS and Google Play Billing on Android. We never see, receive or store your name, your card number, your billing address or your email address.

Entitlements are managed through RevenueCat, a purchase-management service whose SDK is in the app. Once you have accepted our terms it starts, generates a random anonymous identifier for this install, and asks RevenueCat’s servers whether that identifier holds an entitlement. When you buy or restore, it receives the store’s receipt or purchase token — which names the product, the price, the date and the store’s own transaction identifiers — and keeps it against that anonymous identifier so a purchase can be restored on a new device. It never receives your name, your email address or a card number, because we never have them either. RevenueCat acts on our behalf for this and nothing else; its privacy policy is at https://www.revenuecat.com/privacy.

The app keeps the yes-or-no answer on the device, and that is the whole of our own purchase record.

Children

Time To Swipe is intended for general audiences aged 13 and over. It is not directed at children, it contains nothing aimed at children, and we do not knowingly collect personal information from anyone under 13 — or under 16 where local law in the EEA or the UK sets that age.

In practice the app collects no personal information from anyone of any age. Nothing that names anyone reaches a server of ours: the settings file is fetched with no identifier attached, the usage events and crash reports sent to Firebase carry only a random per-install identifier, and the other identifiers in the app are the advertising identifier the ad networks read on their own account and the anonymous purchase identifier RevenueCat holds, each described in its own section. Neither is used to recognise a child, to profile anyone, or to contact anybody.

If you believe a child has somehow provided us with personal information, write to support@timetoswipe.app and we will look into it — though there is no field in our records where such a thing could sit.

Advertising does not change that position, because personalisation is switched off for every user on every network regardless of age: nobody is profiled and no interest-based targeting happens. Time To Swipe is not enrolled in Google Play’s Families programme and must not be while it carries these ad networks as configured — their demand is not certified for it.

How the little we hold is protected

Every request the app makes is encrypted in transit over HTTPS. There is no database of ours to protect and no secret of ours in the app: the settings file is a public, static file. The Firebase project that receives usage events and crash reports is protected by Google’s own security and by the two-step verification on the account that administers it, and nothing that ships inside the app can write to it beyond those events. What the stores and RevenueCat hold is protected under their own terms.

If a breach affecting personal data ever occurs, we will notify the competent supervisory authority within 72 hours where the law requires it, and affected people directly where the law requires that. The honest scope of the risk: we hold no name, no email address, no photo and no record of any device, so there is nothing on our side that a copy would reveal about anyone.

Legal basis, for the EEA and the UK

Most of what the app does involves no personal data at all, because nothing identifying is collected and nothing of ours stores anything. Five things are worth naming anyway. Havra LLC is the controller for each.

IP addresses appearing in our hosts’ server logs are processed on the basis of our legitimate interests under Article 6(1)(f) of the GDPR and the UK GDPR, for the security and operation of the service. We do not read them.

Advertising is the second thing, and the one that would otherwise need consent. Personalised advertising in the EEA and the UK requires consent, and we do not do personalised advertising: every network is told you have not consented before it serves anything, and each serves contextual ads instead. What you will see in the EEA, the UK and Switzerland is Google’s consent prompt, because Google requires a certified consent flow before it serves any ad there at all. Where you consent, that consent is the basis on which Google AdMob is asked for an ad; where you decline, it is not asked. Neither answer turns personalisation on. If we ever want to personalise, a compliant consent flow gating every network has to come first.

Purchases are the third: they are processed because you asked for them, and the contract you enter when you buy a tier is the basis for what the stores and RevenueCat receive.

The usage events and crash reports sent to Firebase are the fourth. They are processed on the basis of our legitimate interests under Article 6(1)(f): understanding how the app is used in aggregate and keeping it from crashing, which we cannot do without them. The data is pseudonymous — keyed by a random per-install identifier — measurement-only by configuration, never used for advertising or profiling, and starts only after you have accepted the terms. You may object; the only practical form that objection can take is described under "Analytics and crash reports", and we say so there rather than pretend otherwise. The fifth is this website’s two advertising tags, described under “This website”: in the EEA and the UK they run only on the basis of your consent under Article 6(1)(a), given in the bar on your first visit and withdrawable from the footer at any time.

Your rights, and one honest limit

You have the rights the GDPR, the UK GDPR and comparable laws give you: access, rectification, erasure, restriction, objection and portability. Write to support@timetoswipe.app.

Here is the limit, stated plainly. We hold no name, no email address and no account. The one record of ours that concerns your use of the app is in Firebase, keyed by a random identifier that the app never shows and that we cannot connect to a person, a device or an email address. So a request for access to, a copy of, or erasure of our records can only ever be answered with "there is nothing we can find that is yours" — which is a limit of the design, not a refusal.

What that means in practice: everything the app knows about you is on your device, and uninstalling destroys it and ends what Firebase receives. The other records that exist belong to others — the store’s record of a purchase, RevenueCat’s anonymous entitlement record, and whatever the ad networks hold — and are described in their sections. Write to us about any of them and we will pass the request on, though none of them is linked to a name on our side either.

You also have the right to complain to your data protection authority.

Who else is involved, and where the data sits

These parties, and no others.

Vercel serves this website and the settings file from its content delivery network. Meta Platforms receives the website events described under “This website” when its pixel runs — Meta Platforms Ireland Limited as our joint controller for their collection where the GDPR or the UK GDPR applies, and Meta Platforms, Inc. in the United States, which is certified under the EU-US Data Privacy Framework for the transfer. Google receives the website events described under “This website” when its tag runs, as an independent controller — Google Ireland Limited where the GDPR or the UK GDPR applies, and Google LLC in the United States, which is certified under the EU-US Data Privacy Framework for the transfer.

Apple bills iOS purchases, through the App Store.

Google bills Android purchases through Google Play, and supplies the consent prompt and the AdMob ads described under "Advertising".

Google LLC also runs Firebase Analytics and Firebase Crashlytics for us, from the United States, as our processor: it holds the usage events, crash reports and the random per-install identifier described under "Analytics and crash reports", and nothing else about you. Its terms for these services are at https://firebase.google.com/terms/data-processing-terms and its privacy commitments at https://firebase.google.com/support/privacy.

RevenueCat manages purchase entitlements on our behalf, from the United States. It holds the anonymous identifier and the store receipts described under "Purchases" and nothing else about you; its privacy policy is at https://www.revenuecat.com/privacy.

Start.io, Google AdMob and Unity Ads supply the ads on the free tier. Each is an independent controller of what its SDK collects, not our processor, and each operates internationally — their own privacy policies, linked under "Advertising", are the authority on where they store and who they share with, because we genuinely do not control that. None of them receives anything about your photos.

If you are in the EEA or the UK, that means data reaches the United States. Transfers to Vercel, RevenueCat and Google’s Firebase, which act on our behalf, rely on the Standard Contractual Clauses in their data processing terms; the website’s tag events reach Meta and Google under the EU-US Data Privacy Framework and its UK extension. The ad networks are not our processors, so their transfers are governed by their own arrangements rather than ours.

California

We do not sell personal information and never have — no money changes hands for your data in either direction.

Sharing is the question worth being careful about. Under the CPRA, "share" is a term of art meaning disclosure for cross-context behavioural advertising, and that is exactly what personalised advertising is. We have switched personalisation off for every user on every network: each is told you have not consented before it starts, and each serves contextual ads. On that basis the app does not share personal information for cross-context behavioural advertising. This website is the exception: when Meta’s pixel and Google’s tag run, they disclose your visit to Meta and Google for advertising measurement, which counts as sharing under the CPRA, and so the website offers the opt-out the law requires — described under “This website”, and at the end of this section. Residents of California and the other states with comparable laws are nevertheless shown Google’s "do not sell or share" message, because Google offers it and we would rather you had the switch than took our word for it; it controls whether Google AdMob is asked for an ad at all. If personalisation is ever switched on, that stops being true, this section gets rewritten, and a working opt-out ships with it — not after.

Because the position depends on a setting rather than on the absence of an ad network, the practical opt-outs are worth stating plainly, and they are in "Turning ads off" above: decline App Tracking Transparency on iOS, delete the advertising ID on Android, use the Privacy options entry in Settings where it is offered, or buy a tier that stops the SDKs from running at all. On this website, Meta’s advertising pixel and Google’s ads tag are the things there are to opt out of, and two things do it: the “Do Not Sell or Share My Personal Information” control in the footer, and a Global Privacy Control signal from your browser, which we honour as an opt-out before anything loads.

Categories collected in the past twelve months: identifiers (the advertising identifier that the ad networks read on their own account, the anonymous purchase identifier RevenueCat holds, and the random per-install identifier Firebase generates), internet or other electronic network activity (your interactions with ads, held by the ad networks; and your use of the app — sessions, swipe counts, the screens named under "Analytics and crash reports", and crash reports — held by Google’s Firebase on our behalf), geolocation (coarse, derived from your IP address by the ad networks; precise where your operating system has granted it, read by Start.io), commercial information (purchase records held by the stores and RevenueCat), and the IP addresses in our hosts’ server logs. We retain none of the ad networks’ categories ourselves; the Firebase categories are ours, held by Google as our processor.

Under the CCPA as amended you have the right to know what we collect and to receive a copy, to delete it, to correct it, to opt out of sale or sharing, to limit the use of sensitive personal information, and not to be discriminated against for exercising any of them. We will never charge you a different price or give you a worse app for asking. Write to support@timetoswipe.app. The limit set out under "Your rights" still applies to our own records: with no account and no record of any device, there is no record of ours that points at a person.

This website

timetoswipe.app is a set of static files. It embeds no fonts, no frames and no images from any other domain. There are two exceptions, and they are the subject of this section: an advertising pixel supplied by Meta Platforms — the company behind Facebook and Instagram — and an advertising tag supplied by Google, which we use to tell which of our ads actually brought somebody here. Whether they run depends on where you are, because the law does.

In the EEA, the UK and Switzerland, and in Brazil and Quebec, whose laws lean the same way, the two tags load only after you accept them in the bar that appears on your first visit. Ignore the bar and nothing loads; decline and that is remembered permanently for this browser. An acceptance is remembered for twelve months or until this policy changes, whichever comes first, and you can withdraw it at any time from the “Cookie settings” control in the footer, which also deletes the cookies described below that the tags set on this site. Everywhere else the tags run by default, and the footer control — labelled “Do Not Sell or Share My Personal Information” in the United States and “Privacy choices” elsewhere — switches them off with one tap. A browser that sends the Global Privacy Control signal is treated as having opted out everywhere, before anything loads, and is told so instead of being offered a switch.

To know which of those applies, the site sets one cookie of its own, tts_region, holding only the word optin, optout or default, and keeps your decision in your browser’s local storage as tts_consent. Neither contains an identifier, neither is sent anywhere, and both exist only so the site can obey your decision without asking again.

When Meta’s pixel runs, it is a small script fetched from connect.facebook.net. It sets two cookies on this domain — _fbp, which lets Meta recognise the same browser on a later visit, and, if you arrived from a Meta ad, _fbc, which holds that click’s identifier — and it sends two things to www.facebook.com: that you viewed a page, with its address, and that you tapped the App Store or Google Play button, with the platform you chose. Each request carries what every web request carries: your IP address, your browser’s user agent and the page you are on. Meta’s optional automatic collection — which would otherwise report the text and destination of anything you click, and the page’s metadata — is switched off in the code, so those two events are the whole of it. Meta may match the visit to a Facebook or Instagram account you are signed in to, under its own privacy policy at https://www.facebook.com/privacy/policy, which we do not control.

When Google’s tag runs, it is a script fetched from www.googletagmanager.com for our Google Ads account. It sets cookies on this domain — _gcl_au, which lets Google Ads connect a later visit to the same browser, and, if you arrived from a Google ad, _gcl_aw, which holds that click’s identifier (gclid) — with a copy of the same under _gcl_ls in your browser’s local storage, and it sends to Google, at www.google.com, www.googleadservices.com, googleads.g.doubleclick.net and ad.doubleclick.net, that you viewed a page, with its address, and, where we measure it as a conversion, that you tapped the App Store or Google Play button. Each request carries your IP address, your browser’s user agent and the page you are on. Google may also read or set cookies on its own domains, which this site can neither see nor delete; your browser’s site-data settings can. The tag is told that consent has been given only when it has — in the EEA, the UK and Switzerland that means you accepted — and before that it is not on the page at all. Google may connect the visit to a Google account you are signed in to, under its own privacy policy at https://policies.google.com/privacy, which we do not control.

Where the GDPR or the UK GDPR applies, Havra LLC and Meta Platforms Ireland Limited are joint controllers for the collection of that data and its transmission to Meta, under Meta’s Business Tools terms; Meta alone controls what it does with the data afterwards. Google receives its tag’s data as an independent controller, under Google’s Ads controller-controller data protection terms — Google Ireland Limited where the GDPR or the UK GDPR applies. Our legal basis for our part is your consent, which you can withdraw as described above. The data reaches Meta in the United States under the EU-US Data Privacy Framework and its UK extension, which Meta Platforms, Inc. and Google LLC are both certified under.

What is never sent, under any circumstances: anything from your camera roll. No photo, no thumbnail, no filename, no EXIF field, no location, no count of your photos, and nothing about what you kept or deleted. The website cannot read any of it — your camera roll is on your phone, and this is a page in a browser. That boundary is not a policy we are promising to honour; it is a thing the web page is incapable of crossing.

Our host records standard access logs — IP address, timestamp, requested path, user agent — for the operation and security of the service, in the ordinary way that every web server does. We do not read, aggregate or analyse them, and we do not join them to anything.

If you arrive with campaign parameters in the address bar — the utm_ values a link may carry, or an ad-click identifier such as gclid, fbclid, ttclid, twclid or msclkid — the home page reads them in your browser and appends them to the App Store or Play Store link you tap, so the store can attribute the install. They are never stored by us and never sent to us. fbclid is the one Meta’s pixel also reads, for the _fbc cookie described above, and gclid the one Google’s tag reads, for _gcl_aw — each only when its tag is running.

Changes

If this policy changes in a way that affects what leaves your device, the change will be described in the app’s release notes, not slipped in silently. The date at the top of this page always reflects the current version and is its effective date.

Questions, corrections, or an argument with anything above: Havra LLC, support@timetoswipe.app.