Privacy policy

Your moments. Your information.

How Magic Postcard uses profile information, video postcards and limited service events.

Effective 15 October 2026 — Operated by Jacob Bartlett

The short version.

Magic Postcard is for people aged 13 and over and lets connected friends share silent video postcards on their Lock Screens. We do not perform age verification or collect a date of birth. It uses an automatically created Firebase app identity linked to your chosen profile and service activity. This is a pseudonymous identity, not anonymous data.

We do not read or upload your address book or record microphone audio. Magic Postcard has no advertising feature or cross-app advertising tracking. Videos and profile photos use our Firebase service. New postcards have a private cloud Gallery original, downloaded on demand, with a small cache on your phone. Magic Postcard does not automatically save videos to your Photos library or iCloud Photos.

Information the service uses.

  • Your profile: your claimed unique username, any older display name still held for compatibility, optional profile selfie, Firebase account identifier and profile-photo version. New setup requires an available username, not a Contacts lookup or a real first name. You can skip the profile-photo step.
  • Your connections: friend requests, accepted connections, invitations, selected recipients, removed connections and blocks.
  • Your postcards: videos you choose to send, their sender and recipients, format, timestamps and per-recipient delivery and playback receipts. Both square and widescreen postcards may include an optional message. New recordings are limited to 10 seconds; existing longer originals are not shortened or deleted by this limit. Clips are silent: there is no recorded audio track.
  • Device and service identifiers: your app’s device identifier, notification and Live Activity tokens, app version and device model information needed for delivery. Firebase and Apple attestation services may process authentication, installation and app-attestation information to operate and protect the service.
  • Reports and support: report reasons, account identifiers and any details you provide. A report that references a received postcard may include its identifier and message. It does not attach an additional video copy automatically. Email support also includes the contact details and information you choose to send.
  • Technical information: request and delivery logs, errors, network addresses processed by service infrastructure, and limited usage/performance events described below.

Why we use it.

We use this information to identify your app account, show profiles, manage friendship requests and blocks, deliver postcards to the people you select, record delivery outcomes, handle reports and support, and diagnose or improve the app. You can delete your account in the app; questions and additional data requests can be sent to the contact below.

Camera effects, including Vision and Core ML processing, run on your phone. The resulting video you choose to send is uploaded; the app does not send a separate person-segmentation or depth model input to a cloud AI service.

Delivery and playback receipts.

The sender can see when an accepted friend’s app confirms that the original video was saved in local Gallery (Delivered) and when video playback starts in that friend’s visible app (Seen). These essential service records contain account identifiers and timestamps. Download preparation, a Lock Screen display, using Older/Newer or pinning a postcard do not count as Seen. Receipts can be delayed or unavailable; they do not prove someone watched the whole video or paid attention.

Receipt and postcard metadata can remain with cloud Gallery and after an older clip’s one-day download window so Gallery can show these states. Removed connections and blocked or quarantined postcards restrict new receipt access. Account deletion removes this account’s recipient receipt entries from other people’s server records.

When you like a received postcard using its heart, it is saved to your Favourites and the sender can see your like in their delivery details. Removing that like clears the sender-visible heart after their next successful refresh. Liking is not a playback or Seen receipt.

Basic usage and performance events.

Magic Postcard sends a limited set of basic usage and performance events through its Firebase backend: app opens, friend actions, profile-picture changes, send attempts and outcomes, filter selections, receiving steps, card navigation, broad friend-count buckets, camera frame counts, effect-processing and encoding timings, and diagnostic stages/error codes. These events run automatically; the app does not provide an analytics switch.

These records include your Firebase account identifier, app build and timestamps. They are linked to your app identity, even when used to understand aggregate behavior. Usage-event payloads do not include your name, profile picture, video, postcard message, friend identities, invite code or notification tokens. Other service logs can contain request and delivery diagnostics.

Queued events are bounded and sent in small batches. Deleting your account stops further events from that account and removes its existing usage-event records as part of account deletion. Firebase SDKs and the backend also process authentication, security and delivery diagnostics. Firebase SDK adoption telemetry is separate from these account-linked events.

Firebase Crashlytics automatically collects crash stack traces, app and operating-system versions, device characteristics and diagnostic installation/session identifiers to help us find and fix crashes. We do not attach your Firebase account identifier, username, messages, photos or videos to Crashlytics reports. Crash diagnostics are separate from our account-linked usage events and follow Firebase’s retention and deletion processes.

Who receives information.

The friends you select receive your username or older display name and postcard; your profile photo is available to connected friends and may appear with a postcard. When you choose Share link, your username and optional photo may also appear in the chosen messaging app’s invite preview. A recipient can keep a copy or share it outside Magic Postcard.

Google Firebase provides authentication, backend functions, database and file storage, messaging, crash diagnostics, and the support/privacy website and older invitation hosting. New invite pages at games.jacobstechtavern.com are hosted on Vercel. Apple provides system notifications, Live Activities and device security services. Providers may process service information according to their own terms and retention settings.

The application’s Firebase functions are configured in London. This does not mean every provider operation or all data processing stays in the UK. See Firebase’s privacy information and Apple’s privacy information.

Postcards are not end-to-end encrypted. New cloud Gallery originals require authenticated app-account access; recipient access also requires the accepted connection and checks for blocks, reports and account restrictions. Temporary delivery copies, older postcards and profile photos can still use token-bearing download links. Someone given such a link may access the file while the link and file remain available. Removing a connection prevents new authorized recipient lookups and sends; it does not invalidate every older link or copy already shared.

How long information stays.

  • Cloud Gallery originals: new postcard originals remain until the sender chooses Delete postcard permanently, deletes their account, or the operator removes the media for a safety reason. For a received cloud postcard, Remove from Gallery hides the entry for that app account; it does not delete the sender’s original. For a cloud postcard you sent, the Gallery trash action is Delete postcard permanently. Sender deletion stops new cloud downloads, but cannot recall copies already downloaded by recipients or existing Lock Screen cards. Minimal postcard identifiers and technical deletion records can remain to prevent stale requests from restoring a deleted postcard; the deleted video and message are not kept in those records.
  • Temporary and older delivery clips: these have a one-day download window and are eligible for deletion under an age-one-day rule on the temporary clips storage area. That rule does not expire cloud Gallery originals. Provider lifecycle deletion is asynchronous, not an exact 24-hour erasure guarantee.
  • Provider recovery period: Cloud Storage currently retains deleted objects for seven days under its soft-delete policy. Normal app download access is removed before this recovery period ends; deletion is not instant physical erasure of every provider copy.
  • Usage events: records are marked to expire 90 days after receipt, using a database time-to-live policy. Deletion can happen after the expiry time, not exactly at it.
  • Account, profile and connection data: these are retained to operate your account and connections until you delete the account or a removal request is processed. In-app deletion removes the account profile and device registrations, friendships/requests/blocks, invitations, own server uploads and usage-event records. It removes your recipient identifiers from other people’s server postcard records without deleting their uploads. Removing or blocking one friend is not deletion of the entire account.
  • Reports: report records may contain account identifiers, your report details and a reported postcard’s message. Safety evidence can remain after account deletion to investigate abuse and enforce the rules. Records are marked for 90-day expiry; cleanup can occur after that time, not exactly at it. Ask us about review or removal of a particular report. There is no automatic video classifier: user reports, limited text safeguards and manual operator review are used.
  • Deletion progress: a minimal account-identifier/progress record fences stale requests and lets you retry a failed deletion. Incomplete deletion records remain until deletion finishes. Completed records are eligible for cleanup after one day; if final housekeeping fails, the operator may need to reconcile the record. This is not an immediate-erasure promise.
  • Local Gallery and cache: the phone keeps postcard metadata, retry state, cached receipts and previews. Verified, recoverable cloud originals use a cache with a 75 MiB target and can be downloaded again when access is still allowed. This is not a total-app storage limit: older sole copies, failed or uncertain sends, copies not yet verified recoverable, offline cleanup and videos in active use can remain above the target. Older local-only postcards are not silently uploaded or erased to meet it. The local Gallery folder is excluded from device backup; Magic Postcard does not automatically save to Photos.
  • Service logs and support email: these follow provider or operational retention and are not removed immediately by deleting a local postcard. Contact us about a particular data-removal request.

Removing a postcard from your Gallery, removing a friend or uninstalling Magic Postcard does not delete your server-side account or a recipient’s independent copy. To delete a cloud original, use the sender’s permanent-delete action or delete the sender’s account. Older profile-photo and delivery links already issued may remain accessible while the underlying objects remain available.

Your controls and requests.

You choose your profile photo, message and recipients. You can accept or decline requests, remove or block a connection, report a problem and replace your invite link. In Gallery, the trash action removes a received cloud postcard from your own Gallery or permanently deletes a cloud postcard you sent. Deleting an older local-only postcard removes this phone’s saved original; it may be the only copy. If a removal cannot finish online, its pending state stays visible in Gallery rather than being presented as completed. Camera and Live Activity permissions are managed in iPhone Settings.

Open Friends → Privacy & about → Privacy & Account → Delete account for permanent deletion. It requires confirmation. If a network/server step fails, local Gallery is kept and you can continue deletion in the same screen. Only after the server confirms completion does the app remove this account’s local Gallery/cached media and sign it out. Copies saved independently by recipients cannot be recalled. For additional removal requests or questions about accessing or correcting information, email Jacob Bartlett at . We may need to confirm which account you control. An emailed request is an additional support route, not a replacement for the in-app deletion control. Independently saved recipient copies cannot be recalled.

Please don’t email passwords, private videos or live invite codes in your initial request. We will explain what information is needed to identify the account or investigate your concern.

Questions and changes.

Magic Postcard is operated by Jacob Bartlett. Contact for privacy questions or use the support page for help with the app.

We will update this page and its effective date when the app’s data practices change. The app’s App Store privacy disclosure should describe the shipped version’s collection, including partner services.