1. Who we are
Warlock Assistant is an independent, hobbyist companion app for the Magic: The Gathering trading card game. The app is developed and operated by the Warlock Assistant team ("we", "us", "our").
The data controller — the person who decides what happens to your data and answers for it — is Roberto Di Miceli, based in Italy, reachable at [email protected]. Write to that address for anything in this policy, including the rights in section 16. We have not appointed a Data Protection Officer, and are not required to.
This policy explains what personal data we collect when you use the Android, iOS, desktop, or web versions of the app, and how we handle it. It describes the app as it currently behaves, including a few things we are actively working to improve — those are called out where they apply.
2. Our privacy commitment
Some things will not change, whatever the app becomes. We do not sell or rent your personal data to anyone. We do not build commercial profiles of you for marketing. And we will never hand an advertising network your account identifier, email address, nickname, decks, collections, notes, search text, or anything else you have created or typed.
As of this version the app displays no advertising and integrates no advertising SDK, carries no affiliate link, and sells nothing. Section 7 sets out what would apply if we introduce advertising, and section 8 what would apply if we offer optional paid features. In both cases we will publish an updated policy — and ask again for consent where consent is required — before the first advert is shown or the first purchase is possible.
To keep the app stable we run a small set of Google Firebase services; exactly which ones run on which platform, and what you can and cannot switch off, is set out in section 4.
3. Data we collect
At sign-up we collect: (a) your email address, used as your login identifier and to deliver account-management messages; (b) a salted and bcrypt-hashed form of your password (we never store, log, or transmit passwords in plain text); (c) a nickname (alphanumeric, 1–30 chars) that acts as your in-app handle; (d) optionally, your MTG Arena nickname (see section 12); (e) which version of the Terms and Conditions and of this policy you accepted, and the moment we recorded it. We keep (e) because an agreement nobody can point to is not an agreement: it is how we can show you exactly which text you were shown, and it is included in the data export described in section 16.
If you sign in with Google or Apple we store the provider's stable identifier for you and your email address (for Apple, this may be a private-relay address); we discard the name they return. With Apple we also keep the refresh token Apple issues to us when you sign in, and which of our apps it was issued to. It opens nothing in your Apple account — all it can do is confirm that you still use Sign in with Apple with us — and we keep it for one purpose: so that deleting your account can have Apple revoke it, as Apple requires (section 15).
While you use the app we also store: the Magic-related content you create (decks you build or import, cards you mark as owned, your collections and favourites, and the private notes you attach to a card, a deck or a preconstructed deck); the profile picture you choose (a card artwork URL and the card's identifier), which is shown to your friends, to other players at an online match table, and to anyone who opens a link you shared; your friendships (see section 9); your share links and grants (see section 10); records of online matches (see section 11); your in-app notification inbox (title, body, category and link of each notification), which is written even when you have turned push and email off for that category, and which you can mark as read but not delete; your notification preferences; and your interface and card-data language choice, which is saved to your account and sent with every request so we can return content in that language.
Ideas & feedback: when you send an idea for the app or describe a problem, we store its title and description, its type, the area you picked, the language it is written in, your account identifier, when you sent it and what became of it (waiting, published, declined or taken down, its status and any note an administrator wrote about it); for a problem, also the platform, app version and operating-system version of the device it came from. We also store the votes you give — which idea and when — the time of your last submission, which is how we let one through per hour, and, if an administrator stops your account from sending ideas and voting, until when. Section 10 says who sees what.
Device registration: when you are signed in and push notifications are available, we store a record linking your account to a random installation identifier the app generates on first run (not a hardware, advertising, or Google identifier), the push token issued by Firebase, and the platform. We store no IP address, device model, or OS version in that record.
Sessions: signing in creates one record per device — what Account settings → "Active sessions" shows you, and what lets you sign a device out remotely. It holds the same random installation identifier, a hashed form of the token that keeps you signed in (never the token itself), the platform, the device model and operating-system version the device reports, the app version, and the times the session started and was last renewed. We store no IP address and no location in it. On the web, where there is no device model to report, we derive only a coarse browser and operating-system label (for example "Chrome" and "Windows") and never store the full browser identification string.
Sign-in restore (Android): where the platform supports it, the app can create a restore key, so that a phone set up from your backup signs you back in without you retyping your password. It is a public-key credential minted by Android's Credential Manager: we store its identifier and its public key against your account and the installation that created it, while the matching private key is placed by your device in your own Google backup and never reaches us. It carries no password and grants nothing on its own — it can only prove that your backup is being restored — and it is deleted when you delete your account.
Camera and card scanning: on Android and iOS the app can use the camera to read a card and find it in the catalogue. The camera preview is processed entirely on your device: frames are never stored, never uploaded, and never sent to us. What leaves your device is only the text the scan reads — the card name, plus the set code and collector number when they are legible — sent to our own catalogue in the same request an ordinary search makes, and kept no longer. The app asks for camera permission the first time you open the scanner and never uses the camera anywhere else.
Beyond what is described in this policy, we do not collect your real name, postal address, phone number, date of birth, precise location, contacts, photos, or any advertising identifier — sections 7 and 8 explain what would change if we introduced advertising or paid features.
4. Telemetry, crash reporting, and performance
We use Google Firebase to keep the app healthy. What runs depends on the platform, and this differs in ways worth knowing.
Android and iOS: Firebase Analytics, Crashlytics and Performance Monitoring are started automatically when the app launches, before you interact with it, and so are Remote Config and Cloud Messaging. There is currently no in-app switch to disable them, and no device setting that does: Android's "Usage & diagnostics" switch, which earlier versions of this policy offered as the way out, governs what your device itself sends to Google, not what apps collect. The consent banner described in section 21 exists on the web version only.
Web: Firebase Analytics is OFF until you accept the Statistics category in the banner, and Performance Monitoring does not run on the web at all. Other Firebase components load before you choose — see section 21.
Desktop: no analytics, crash reporting, performance monitoring or push messaging. The desktop app does make one call to Firebase Remote Config at startup to fetch feature flags; that request carries a random identifier regenerated on every launch and never stored, our app identifier, and unavoidably your IP address.
What the services collect: Analytics records the screens you visit and a defined list of feature-usage events — that a match started and how many seats it had, that a deck was created or imported, that a search ran and roughly how many results it returned, that a card was scanned, that a setting changed, and so on — together with device attributes (app version, OS version, device model, approximate country from the IP address). It reads neither an advertising identifier nor any identifier of your device: the Android app switches off the advertising ID and the Android ID, and the iOS app uses the edition of Analytics that cannot read Apple's advertising identifier and switches off the identifier for vendors. What tells one installation from another is a random identifier Firebase creates for it, which a reinstall replaces. Crashlytics (Android and iOS) captures stack traces and a short breadcrumb log. Performance Monitoring (Android and iOS) measures start-up and rendering times, and records no network request. Remote Config delivers feature flags. Cloud Messaging delivers the push notifications you opted into.
What those events never contain: the text you type. No search query, no deck or collection name, no personal note (not even its length), no nickname, no email address, and no identifier for any card, deck or collection. Counts are reported as ranges ("3-5", "26+") rather than exact numbers, and every other detail is drawn from a fixed list of values written into the app. On the web, Analytics by default attaches to every event the full address of the page you are on and of the page that sent you there. Those addresses can carry a share link's token, the one-time token of a password-reset link and the identifiers of cards, decks, collections and other players, so the web app sends the name of the screen instead ("deck", "card"), and the referring page cut down to the site it belongs to.
Your account and this data: when you are signed in we do attach your account identifier — the internal random UUID, never your email address or nickname — to the events and crash reports we send, so that a crash can be tied to the session that produced it and so a problem can be traced across your devices. It is cleared when you sign out, and cleared when you delete your account. While you are signed out nothing carries an account identifier at all. (Earlier versions of this policy said we never attached it; that changed in version 8, which is why you were asked about this again.) None of it is sold, shared with advertising networks, or used to profile you.
5. How we use your data
We use your data only to: (a) provide the app's functionality — authenticate you, synchronise your decks, collections and preferences across your devices, run online matches, deliver notifications you opted into, and send transactional emails; publish the ideas and problems you send through "Ideas & feedback", once approved, and count the votes they receive; (b) keep the app stable, by reading crash reports, performance traces and aggregate usage events; (c) decide which features to ship and how to tune them; (d) investigate abuse and technical incidents, including the reports of shared content described in section 10, and read every idea and problem before it is published; (e) produce aggregate, anonymous statistics about how the app and the game are used — how often a card appears in decks, how long matches tend to run, which formats are played — which we may publish or offer access to.
Those statistics are computed across all users and contain no personal data. They describe the service, never you, and cannot be traced back to you, to your account, or to any individual deck, collection or match.
What allows us to do each of these — the legal basis. Running the app for you (a) is the performance of our contract with you: the Terms and Conditions are that contract, and the same basis covers the record of your acceptance of them and the account emails we have to send. Keeping the app stable and investigating abuse (b, d) rest on our legitimate interest in a service that works and is not abused; deciding what to build (c) and the aggregate statistics (e) rest on the same interest. The statistics never operate on anything you typed; deciding what to build does read the ideas and problems you choose to send us — that is what they are for — and publishing them is part of the service you asked for when you sent them (a). Where the law requires your consent we ask for it and you can take it back: that is the Statistics category on the web (section 21) and, if we ever introduce advertising, the prompt described in section 7. Keeping invoicing records, if we ever sell anything, is a legal obligation (section 8).
One honest exception. On Android and iOS the diagnostics described in section 4 start with the app rather than after a prompt, because no in-app switch exists yet. We treat that as a gap to close, not as a consent you gave; until it is closed, they run whenever the app does.
Where a basis above is legitimate interest, you have the right to object to it — section 16 says how.
We do not use your personal data for marketing profiling or for automated decision-making with legal effects, and we do not sell or rent it. If we introduce advertising, section 7 sets out exactly what that would and would not involve.
6. Third-party services
We rely on a small set of processors. (a) Email delivery: outgoing email is handed to an SMTP provider, which receives your email address, the subject, and the full message body including verification and password-reset links. Our current provider is Google (Gmail SMTP). (b) A self-hosted MongoDB database, operated by us, stores account and in-app content. (c) Scryfall's public CDN (cards.scryfall.io, svgs.scryfall.io) serves card images and set icons directly to your device; Scryfall therefore sees your IP address and the image URLs you request, but receives no account information from us. (d) Google Firebase (Google Ireland Limited / Google LLC) processes the signals described in section 4; on the web its SDK is served from Google's gstatic.com CDN, which sees your IP address. (e) Sign in with Google and Sign in with Apple: if you use social sign-in, you sign in on the provider's own page or system sheet, and our server contacts Google (googleapis.com) or Apple (appleid.apple.com) to verify the token you present. With Apple it also trades the one-time code Apple issues at sign-in for the refresh token described in section 3, and hands that token back to Apple, to be revoked, when you delete your account. The web page loads their scripts from accounts.google.com and appleid.cdn-apple.com. (f) MTGJSON supplies card data, prices and preconstructed decklists to our server; it receives no data about you. (g) Font fallback on the web only: when a card name uses characters our font cannot draw — Japanese, Chinese, Korean, Russian and other non-Latin scripts — the browser downloads the matching Noto font from Google's fonts.gstatic.com CDN, which sees your IP address. This is done by the UI framework we build on, which offers no way to switch it off or to route it through us, so it is not covered by the consent banner in section 21 and happens whether or not you are signed in. It is triggered by the characters on screen, not by anything about you, and no account information is sent. (h) Cloudflare (Cloudflare, Inc.) is the content delivery network and TLS front end for our website: every request to warlockassistant.com passes through its network before it reaches our own servers, so Cloudflare sees your IP address, the address of the page you asked for, the page that referred you and your browser's identification string, and it may set a strictly necessary cookie of its own (typically "__cf_bm") to tell a browser apart from automated traffic. It acts as our processor, receives no account information from us, and the data is used to deliver and protect the site, not to profile you. (i) Apple Push Notification service: on iPhone and iPad, Firebase Cloud Messaging hands each push notification to Apple, which delivers it to your device, so Apple receives the notification's title and text and your device's push token.
As of this version we embed no advertising network, no payment provider and no third-party tracker. Sections 7 and 8 describe what would change, and any such party will be named here before it processes anything.
7. Advertising
The app shows no advertising and contains no advertising SDK. This section describes what would apply if that changes, so that you know in advance what you would be asked to agree to.
If we introduce advertising, the adverts would be supplied by a third-party advertising network. To serve them, that network would receive technical data from your device — typically its IP address, device and browser characteristics, and an advertising identifier where your platform provides one — and would set or read identifiers on your device. It would act as its own controller for what it then does with that data, under its own privacy policy, which we would name in section 6 before the first advert is shown.
What we would never do, in this or any future version of this policy: give an advertising network your account identifier, email address, nickname, MTG Arena name, decks, collections, favourites, notes, search text, match records, or anything else you have created or typed; sell or rent your personal data; or let an advert stand between you and card data, your own content, or a match in progress.
Legal basis and your choice. In the EEA and the UK, personalised advertising and the device identifiers it relies on require your consent. We would ask for it through a consent prompt before the first advert is shown, you would be free to refuse, and you could change or withdraw your choice at any time from the app. Refusing takes nothing away from what the app does for you — it only means that any adverts you see are not personalised.
Affiliate links. We may also link to third-party retailers and earn a commission if you buy something. Such a link carries no personal data: it is the same URL for everyone who sees it. When you follow it you leave the app, and the retailer's own privacy policy and cookies apply from that point.
8. Payments and purchases
The app sells nothing. This section describes what would apply if we introduce the optional paid features that section 5 of the Terms and Conditions allows for.
If we do, the payment would be taken by the app store you installed the app from, or by a payment provider acting for us on the web and desktop. That store or provider collects your payment details directly and is its own controller for them: we would never receive or store your card number, bank details or billing address.
What we would store is the record of what you are entitled to — which feature or subscription, when it was bought, from which platform, its renewal or expiry date, and the transaction identifier the store or provider returns — linked to your account so that something bought on one device works on all of them. We would store cancellations and refunds the same way. The legal basis is the contract between us.
Retention is the one place where a purchase behaves differently from the rest of your data. Tax and accounting law in Italy and the EU requires us to keep transaction and invoicing records — normally for ten years from the end of the year of the transaction — so we cannot simply delete them when you close your account. If you delete your account we detach those records from your profile and keep only the minimum the law requires. Everything else follows section 15.
9. Friends and social features
If you use the friends feature we store the connection between the two accounts, its status, and the dates it was created and answered. Any Warlock Assistant user who knows your exact nickname can find you and send a friend request — nicknames are discoverable by design, and the only way to hide from this search is to block someone (below). Once a request is sent or accepted, each of you can see the other's nickname and profile picture. Friend-request and acceptance notifications contain both nicknames and are therefore transmitted to Google as push text — and on iPhone and iPad to Apple, which delivers it (section 6(i)) — and to our email provider as email text. You can decline, cancel, or remove a friendship at any time, which deletes the record, and you can turn the push and email notifications off per category in Settings.
Blocking. You can block another user from their profile, from a friend request they sent you, or from the menu of something they shared. We then store that you blocked them, and when. The block deletes any friendship or pending request between you and withdraws the friend grants either of you gave the other (section 10); from then on they cannot send you a friend request, share with you or invite you to a match, and your profile answers them as if it did not exist; you, for your part, stop seeing the ideas and problems they send — in the list, on their pages and among the similar ideas offered while you write. They are not told. Account settings → Blocked users lists the users you blocked and lets you unblock them, which does not bring back what the block ended.
10. Sharing your content
When you share a deck or collection by link, we create an unguessable link. Anyone holding that link can open the shared item without signing in, and will also see your nickname and profile picture. The link works even if the item is marked private — the link itself is the permission, and changing the item back to private does not disable it. You can review and revoke every link and friend grant you have created from Account settings → Shared links; revoking a link stops it from opening immediately, and revoking a friend grant withdraws that friend's access. A link does not expire on its own, so until you revoke it (or delete the shared item, or delete your account) you should treat it as public. Someone else who opens one of your decks in the app — a friend, someone you gave a friend grant to, or anyone signed in if you made the deck public — also sees your nickname and profile picture with it, so they know whose it is and can report it or block you (section 9).
If you paste a share link into a chat app or social network, that platform will fetch a preview page from our server and may display and cache the item's name, its format, its card count and one card image — including for items you marked private. We have no control over how long those platforms keep that preview; revoking the link stops us serving new previews but cannot erase copies a platform has already cached.
Reports. Anyone signed in can report a deck or collection that someone else shared, from its menu in the app. A report records the reporter's account identifier, which item it is about, the reason they picked and when. An administrator reviews it and either dismisses it or makes the item private: then only its owner can open it, every link and friend grant to it stops working, and the owner receives a notification saying so and why. The owner is never told who reported it. If you report something, that record is kept about your report, and it is part of your data export (section 16).
Ideas & feedback. An idea or problem you send is read by an administrator before anyone else sees it; until then only you and the administrators can open it. The administrator publishes it as it is or after correcting its spelling or taking personal details out of it (it then says so), may add a translation into another language, or declines it, and you receive a notification saying which — and why, if declined. (The one exception: what you had waiting when your account was stopped from sending ideas is declined without a notification; you learn of the stop when you next try.) Once published, anyone can read it in the app or the web app, signed in or not, together with your nickname (never your profile picture), its vote count and, for a problem, the platform and app version it came from; the operating-system version is seen only by administrators. The app never shows who voted for what, administrators included — only how many. We ask search engines not to index these pages. Notifications about an idea — approved, declined, a new status, taken down, or, for those who voted for it, completed or not planned — contain its title, so it travels to Google, and on iPhone and iPad to Apple, as push text (section 6); you can turn them off in Settings, except the one telling you an idea of yours was taken down. A published idea can be reported like a shared item; an administrator either dismisses the report or takes the idea down, which unpublishes it and tells you why, never who reported it.
11. Online matches
When you join or host an online match, the other players at that table can see the seat name you type, your profile picture, and the names of any decks you attach. We store the table while it is live and keep a record of each finished game, including seat names, avatars, deck names and account identifiers. You cannot currently view or delete these records from the app. Live tables are cleaned up when the table closes or automatically after a period of inactivity.
12. MTG Arena integration (desktop only)
On the desktop version only, the app can read MTG Arena's Player.log file on your computer to detect the decks in your Arena library. This reading is off by default: it happens only when both we have enabled the feature remotely and you have switched it on yourself, under "MTG Arena" in App settings (turning it on first asks you to confirm). While it is on, the app watches the log from the moment it starts, reading it line by line, strictly read-only, relying on MTG Arena's own "Detailed Logs (Plugin Support)" option; it never writes to, injects into, reads the memory of, or otherwise modifies MTG Arena. You can switch the reading off again at any time from the same setting, which stops it immediately and removes from your computer the decks it found; the mobile and web versions never read any local game file.
While reading, the app also detects the MTG Arena account name when the log shows it, which MTG Arena does only when you sign in to it with your password, not when it signs you in by itself. This happens automatically and locally. The detected name is kept only in memory until MTG Arena starts again, and is never sent to us unless you confirm it in the "Is this you?" card or type it yourself in Account settings. If you choose "Not me", nothing is stored and we ask again next launch. Once saved it becomes part of your profile, is visible only to you, and can be changed but not currently cleared except by deleting your account.
The decks the app takes from the log are your own: the preconstructed decks MTG Arena gives every player are left out, unless you have saved one of them in Arena, which makes it yours. To show them on your computer, signed in or not, the app looks up their cards in our card catalogue by MTG Arena's card numbers; that lookup carries no account information and is not kept. While you are signed in, those decks — deck name, format, and the cards in each zone — are also uploaded to your account automatically whenever they change, and stored as private decks, so that your other devices show them: switching the reading on is what you agree to this with. If the log shows an MTG Arena account name other than the one saved in your profile, uploading stops until you confirm it, so that someone else's Arena account on a shared computer never fills yours. Arena decks that disappear from your Arena library are removed from your account on the next upload. A copy of the decks is also kept on your computer. Logging out deletes it, although while the reading stays switched on the app writes it again from the log. The raw log file itself is never copied, stored, or transmitted.
13. Local data on your device
The app keeps the following on your device: (a) the two tokens that keep you signed in and a cached copy of your account profile, including your email address; (b) a local database containing every deck you have created or imported with its full card contents, your collections, your favourites and your personal notes; (c) your saved match table — including the display names, avatar URLs and account identifiers of the other players at that table — and a rolling history of your last 50 finished local matches; (d) an autosave of the deck you are currently building; (e) your preferences; (f) a random installation identifier; (g) an image cache of card pictures you have viewed; and, on desktop, (h) the imported MTG Arena deck list.
On the web version everything except the image cache and the card database is stored as plain text in your browser's local storage, unencrypted; the card database lives in your browser's private file storage. On Android the app takes part in Android's automatic backup, and on iOS in iCloud and computer backups, with one deliberate exception: the file that holds items (a), (c), (d), (e) and (f) above — your session tokens and cached profile, your saved match table and local match history, the deck draft, your preferences and the installation identifier — is left out of every backup, and on Android out of device transfer too, so no credential of yours ever travels inside a backup. What a backup does carry is (b) your local card database, restored to a new device; the image cache (g) sits in the system's cache, which backups skip. You can prevent even that by excluding the app's data from your backups in your device's settings. Signing back in on a restored Android device uses the restore key described in section 3, which mints a new session rather than reviving the old one; on iOS you sign in again.
Logging out ends that device's session on our side and erases from the device its tokens and cached profile, the local database, the saved match table and local match history, the deck draft and the imported MTG Arena deck list — items (a) to (d) and (h) above. What your account holds comes back when you sign in again, and before erasing anything the app sends your account every change it has not received yet: if some cannot be sent, it tells you and lets you stay signed in. A session that ends without you logging out on that device — because it expired, you ended it from another device, or you changed or reset your password — erases the same things once the device next reaches our servers, and a change it had not sent by then is lost. Your preferences (e), the installation identifier (f) and the image cache (g) stay.
Deleting your account erases (a), (c), (d), (f) and (h), and asks which of your decks, collections, favourites and notes to keep on the device: what you keep stays there, linked to no account, until you delete it or merge it into an account you sign in to. The "Delete local data" action in App settings erases everything above except your preferences and the image cache. You can also use your operating system's clear-app-data function, or clear site data in your browser.
14. Server logs and administrative access
Running the service produces logs, and they do contain personal data. There are two layers of them.
Our own application server writes one line for every request it serves: the method, the path — never the query string, which on a match connection carries your access token — the response status, a random request identifier, and, once you are authenticated, your account identifier. It records no IP address. Alongside those, our application logs contain the recipient email address of every message we send, account identifiers when scheduled maintenance jobs run, and the text of a search query when a search fails. All of it goes to the server's own output and to rolling files with bounded retention — about two weeks as configured today — and is accessible only to the operator.
In front of that sit the web server that serves the site and Cloudflare (section 6). Both keep conventional access logs, which do record your IP address along with the address you requested, the page that referred you and your browser's identification string. Ours rotate with the container's own output — days rather than months; Cloudflare's are kept under its own retention rules. We read these only to keep the service running and to investigate abuse: we do not use them for analytics, we do not build profiles from them, and we do not join them to your account.
Logs are the one place we cannot search and erase per person. Lines carrying your account identifier are not removed when you delete your account — they age out with the files that hold them, within the retention above.
Administrative access: the operator holds an administrator account which can search accounts by nickname or email address and see the matching account's identifier, nickname and email address, and can send a diagnostic push notification to a specific account, delivered regardless of that account's notification settings. These exist for support and abuse investigation. An administrator also reads every idea and problem before it is published, together with its author's nickname and, for a problem, the device details in section 3, and can stop an account from sending ideas and voting. No log of administrator lookups is kept today. The operator also has direct access to the database.
15. Data retention
When you delete your account we immediately and permanently delete your account record, decks, collections, favourites, your personal notes, share grants, device registrations, active sessions (so every device is signed out), the restore keys bound to your account, in-app notifications, friendships, the blocks you placed and those placed on you, the reports you filed and those about your decks and collections, pending password-reset records, the outbound messages queued or sent to you (including their email address and rendered text), and any live matches you host. Records of finished matches are shared with the other players and feed anonymous, aggregate statistics, so rather than delete them we anonymise your part of them in place: we remove your account identifier, the seat name you used, your avatar and the deck names you played, leaving no record keyed to you.
Ideas and problems work the same way. Deleting your account deletes your votes (they leave the counts), the ideas you sent that were never published, the time of your last submission and any suspension; the ideas of yours that were published stay, because others voted for them, but without your account identifier or nickname — they read as from a deleted user. Reports of them stay with them, no longer naming you.
If you signed in with Apple, we first ask Apple to revoke the refresh token described in section 3, which ends the app's authorisation on your Apple ID, and then delete it with the rest. Should Apple refuse or be unreachable, your account is deleted all the same, and you can remove the app yourself from the Sign in with Apple list in your Apple ID settings.
Deleting your account also erases, from the device you delete it on, your match history, deck draft, imported Arena decks and installation identifier, and asks which of your decks, collections, favourites and notes to keep there (see section 13): what you keep stays on that device only, linked to no account. Your app settings and the cached card images are non-personal and are kept. Your other devices erase their own copies once they reach our servers and find their session gone; one that stays offline keeps its copy until then, and you can clear it with the in-app "Delete local data" action or your device's clear-app-data function.
We also apply automatic expiry to a few short-lived records regardless of account deletion: a queued or sent message is removed within 30 days of being sent (90 days at the outside if it never sends), a password-reset request within 24 hours, a live match when its table closes or after a period of inactivity, a session that has gone 60 days without being used — and with it the device registration of that device — a report 90 days after an administrator has decided on it, an idea or problem 90 days after it was declined or taken down (one you withdraw while it waits goes at once), the time of your last submission after an hour, and a suspension from ideas when it ends. Unverified accounts are warned by email after 5 days and deleted 7 days after sign-up. Firebase Analytics events are retained for 14 months, the default for our project; Crashlytics and Performance data follow Firebase's own defaults. Deleting your account does not reach them: the events and crash reports sent while you were signed in carry your account identifier (section 4), but we do not erase them when the account goes — they expire with the retention above. Log entries follow section 14 rather than this section: they expire with their files and are not deleted on request.
If we ever introduce paid features, transaction and invoicing records are the one category we cannot delete on request, because tax and accounting law requires us to keep them; section 8 explains how that would work.
16. Your rights
If you are in the EU/EEA, UK, or a jurisdiction with similar laws, you may request access to, correction of, export of, or deletion of your personal data, and you may withdraw consent at any time. You may also object to any processing we base on a legitimate interest (section 5) — tell us why and we stop unless we can show grounds that override yours — and you may ask us to restrict processing while a complaint or a correction is being sorted out. The app lets you delete your account, and download a complete copy of your data, directly from your profile. In Account settings, "Export my data" produces a machine-readable JSON file containing your account and preferences, decks, collections, favourites, friendships, share links, active sessions, in-app notifications, match history, the reports you filed, the users you blocked — never who blocked you — and the ideas and problems you sent, whatever became of them, with the votes you gave. If you cannot use the in-app export, email [email protected] from the address associated with your account and we will send it within 30 days. We respond to all requests within 30 days. You also have the right to lodge a complaint with your local data protection authority.
17. Security
Communication between the app and our server is encrypted via HTTPS. Passwords are hashed with bcrypt (cost factor 12).
Signing in opens a session. Your device holds a signed access token valid for 15 minutes and renews it with a refresh token that we keep only as a hash and that changes at every renewal. Because the session is recorded on our side you can see every signed-in device under Account settings → "Active sessions" and end any of them: logging out ends that device's session, changing your password ends every other device's, and a password reset ends all of them, including the one you asked from. A session you revoke stops working the next time its device renews, and in any case within 15 minutes. If a refresh token is presented after we have already replaced it — what a stolen copy looks like — we destroy that session outright, so the thief and the device both have to sign in again.
For real-time match connections the access token is passed in the connection URL, because browsers cannot set authentication headers on WebSocket connections, and it may therefore appear in the logs of network equipment between you and us; it is usable for 15 minutes. Password-reset tokens expire one hour after issue and are single-use; email verification tokens expire after 24 hours. No security measure is perfect — if you suspect your account is compromised, change your password (which signs every other device out) and contact us.
18. Children
Warlock Assistant is not directed at children. You must be at least 16 to create an account, unless the country you live in sets a lower age for a child's own consent to an online service and you have reached it — in Italy, where we are established, that age is 14. Below it, a parent or guardian has to agree for you. We do not verify age at sign-up and we do not knowingly collect personal data from children. Note that an account is discoverable by its nickname and can receive friend requests from any other user. If you believe a child has created an account, contact us and we will delete it.
19. International transfers
Our server and database are self-hosted by us with the hosting provider OVH, on infrastructure located in France, within the European Economic Area (EEA). Email is delivered through Google's SMTP infrastructure. Cloudflare, which fronts our website (section 6), runs a worldwide network and will answer you from whichever of its locations is nearest, so your IP address and the address you requested may be processed outside the EEA; Cloudflare acts as our processor and relies on the European Commission's Standard Contractual Clauses for those transfers. Scryfall's image CDN is operated by a third party that may serve images from edge locations worldwide; the only data shared with it is your IP address and the URL of the image requested. The same applies to Google's font CDN on the web (section 6(g)), which serves from edge locations worldwide and receives your IP address and the name of the font file requested. Google Firebase processes data on Google's global infrastructure, which includes servers in the United States, and Google relies on the EU–US Data Privacy Framework and the European Commission's Standard Contractual Clauses as the legal basis for those transfers. Apple, which delivers push notifications on iPhone and iPad (section 6(i)) and runs Sign in with Apple, processes that data on its own infrastructure, including in the United States; for people in the EEA, the UK and Switzerland its controller is Apple Distribution International Limited, in Ireland, and it relies on the European Commission's Standard Contractual Clauses for those transfers.
An advertising network or payment provider would very likely process data outside the EEA as well. We will name it, and the safeguard it relies on, in this policy before it receives anything (sections 7 and 8).
20. Changes to this policy
We may update this policy as the app evolves. Each version carries a version number and an effective date, and superseded versions are kept on file. Material changes will be announced in the app, and on the web version they re-open the consent banner so you can review your choice. We will not change the policy in a way that retroactively reduces your privacy without your prior consent.
21. Cookies, local storage, and consent (web)
On the web version the app runs entirely in your browser and sets no advertising or tracking cookies. What it stores falls into three categories, of which only two exist today.
(a) Strictly necessary — always active. The two tokens that keep you signed in, your cached profile, your preferences, and a marker saying this browser is signed in, which is how the presentation page at warlockassistant.com knows to open the app for you straight away (all in local storage, no cookies), plus three things that do make network requests before you choose: the Firebase core SDK, which creates a Firebase Installation ID in your browser and contacts Google; Firebase Remote Config, which fetches feature flags at startup; and Firebase Cloud Messaging, which is initialised at load — it obtains no push token and sends nothing unless you separately grant browser notification permission. In addition the page loads scripts from Google (www.gstatic.com, accounts.google.com) and Apple (appleid.cdn-apple.com) as soon as it opens, so those providers see your IP address, browser user-agent and referring URL before the banner appears. The font fallback described in section 6(g) is in this category too: it fetches from Google's fonts.gstatic.com the first time a non-Latin card name needs to be drawn, regardless of what you choose below, because the UI framework gives us no way to gate or redirect it. Cloudflare, which serves the site (section 6), may likewise set a strictly necessary cookie of its own — typically "__cf_bm" — to tell a browser apart from automated traffic. It is not an advertising cookie and does not follow you to other sites.
(b) Statistics — Firebase Analytics, as described in section 4. It is optional and OFF by default: it is not started and sends no data until you accept the Statistics category. A banner asks you on first visit, and you can review, change or withdraw your choice at any time from "Cookie settings" in your profile or the page footer. Withdrawing consent stops it immediately. Your choice is remembered in your browser together with the date and the policy version, and you will be asked again when this policy changes.
(c) Marketing — does not exist yet. The app sets no advertising or tracking cookie, and the banner offers no marketing category, because there is nothing to consent to. If we introduce advertising (section 7) a Marketing category will be added, OFF by default like Statistics, and your stored choice will be invalidated so the banner asks you again before the first advert is shown.
Push notifications sit outside all three. If you allow notifications in your browser while signed in, the app registers a service worker and obtains a push token from Firebase, which we store against your account. It is controlled by your browser's notification permission and by logging out.
22. Contact
Questions about this policy or your data can be sent to [email protected].
23. Trademark notice
Warlock Assistant is unofficial Fan Content permitted under the Fan Content Policy. Not approved/endorsed by Wizards. Portions of the materials used are property of Wizards of the Coast. ©Wizards of the Coast LLC.
Magic: The Gathering, all card names, card text, mana symbols and card artwork are trademarks and copyright of Wizards of the Coast LLC. Card data, prices and preconstructed decklists are sourced from MTGJSON; card images, rulings and set data are sourced from Scryfall.