Glimsy Privacy Policy

Effective date: 19 October 2026
Version: 2.4 (supersedes version 2.3 of 22 September 2026; change: study time measurement — answer duration and active study time of a deck, solely for the operation of the study features, without the device time zone; clarified backups — daily and weekly backups deleted after 7 days, a one-off backup before an update deleted after 30 days)

This policy applies to the use of the Glimsy application on Android and iOS devices and in web browsers, regardless of the country the user is in. Point 18 additionally applies to visitors to the website glimsy.app.

The policy is made available in Polish and in English. In the event of any discrepancy between the language versions, the Polish version prevails. This reservation does not limit any consumer rights arising from mandatory provisions of the law of the consumer's country of habitual residence.

1. Data controller

The controller of personal data and the owner of the Glimsy application is:

GLIMSY spółka z ograniczoną odpowiedzialnością (a Polish limited liability company)
ul. Zapłocie Duże 223A, 43-300 Bielsko-Biała, Poland
KRS (register number): 0001260619 · NIP (tax ID): 5472262046 · REGON (statistical ID): 545480191

Contact for all matters concerning personal data: support@glimsy.app

The Controller is not required to appoint a data protection officer and has not appointed one. Should this change, information about the officer will be added to this policy.

2. Scope and age of users

The application is aimed broadly at pupils and students and contains no content intended exclusively for adults.

Persons below the age required to consent independently to the processing of personal data under the law of their country (as a rule, below 16 in the European Union, unless national law provides for a lower threshold) may use the application only with the consent of a parent or legal guardian.

The application is not directed to children under 13 within the meaning of United States law (COPPA). If the Controller becomes aware that such a child's data has been collected without the required consent, it will take steps to delete it.

A parent or legal guardian who believes that a child is using the application without appropriate consent may ask the Controller to delete the account and the data.

3. Categories of data processed

3.1. Account data

The user identifier assigned by Firebase Authentication, the e-mail address, whether the address has been verified, the display name and — if supplied by the sign-in provider — a link to a profile picture. In addition, the account creation date, the technical role in the system and a marker indicating that account deletion has begun.

Sign-in takes place by e-mail address and password, through a Google account or through an Apple ID.

3.2. Settings and study configuration

Preferred interface language, light or dark theme, the setting that follows the system theme, and the parameters of the spaced-repetition algorithm (FSRS) at account and individual deck level — model weights, desired retention, maximum interval, fuzz.

3.3. Content created by the user

• Decks: name, description, colour, icon, number of flashcards, timestamps, information about import from an external file, sharing marker, sharing code and an AI provenance marker. The last of these is permanent and cannot be removed or changed — including after the user has rewritten the content — because it serves to discharge the obligation to label machine-generated content referred to in point 6.4 of the Terms of Use. The marker does not limit the user's rights to the content.
• Flashcards: the content of the front and back side, the card type, the link to the deck and technical hashes used for de-duplication.
• Media: metadata of image and audio files — a cryptographic hash of the content, the cloud path, the extension, the MIME type, a usage counter and the owner's identifier.

Audio files are stored solely so that they can be played back as part of a flashcard. They are not subjected to any analysis and in particular are not used for biometric voice identification. The application has no audio recording feature — audio files come exclusively from files selected by the user.

3.4. Study progress and answer history

Algorithm parameters assigned to individual flashcards (card state, next review date, number of repetitions, estimated stability and difficulty, number of lapses), the answer history together with the rating, the moment the answer was given, its duration (described below) and the algorithm parameters in force at the moment the answer was given, as well as study session data: card queues, daily limits, statistics and the identifier of the most recently reviewed card.

Study time measurement. On the study screen, the application measures the time spent on flashcards — in every deck, regardless of the study mode selected — and records it in two places:

• Answer duration — the whole time from the moment a flashcard is shown until it is rated, including any breaks, recorded in the answer history together with the rating. A duration longer than 24 hours is not recorded.
• Daily study time record of a deck — the active time of each rated flashcard (its front and back), counted according to the rules described below, together with the identifiers of the flashcard and of the answer, assigned to the deck and to the day on which the study session started. The same record keeps the choice made when the study time runs out in timed study mode ("Exit" or "Finish"). This record is kept when timed study mode is available in the application.

The active time of a flashcard is counted from the moment it is shown. Counting stops if, for 30 seconds, the user presses neither the "Check" button nor a rating button — other screen touches, scrolling or key presses do not extend counting. Pressing "Check" resumes counting and starts a new 30 seconds, and a rating ends the measurement of the flashcard; the next flashcard starts from zero. Counting is paused — without losing what is left of those 30 seconds — while the application is in the background (in a browser: while its tab is not visible), while another screen is open over the study screen (e.g. editing a flashcard) and during the tutorial. While an audio recording from a flashcard is playing, time keeps being counted and the 30 seconds do not run down. The time of a flashcard that was shown but not rated (e.g. after an answer is undone) is added to the next rated flashcard; the time of flashcards still unrated when the user leaves the study screen is not recorded. A single answer adds at most 5 minutes to the daily record, and any excess is carried over to the next rating in the same session.

The daily study time record is used to operate timed study mode: counting down the study time left for the deck on a given day, selecting flashcards during the session (e.g. the point from which a new flashcard appears depends on how much of the daily time has been used), showing study time in the application and synchronising this time across the user's devices. Time is measured in every deck so that, when a deck is switched to this mode during the day, the study time from that day is taken into account. The answer duration is currently only recorded: the review schedule is calculated from ratings and does not depend on the answer time. We collect it in order to improve the study algorithm, including adapting it in the future to the user's pace; if the answer time starts to affect the review schedule, this policy will be amended accordingly (section 17).

Study time data is not used for advertising, is not passed to the tools for measuring the performance of advertising campaigns (points 18–19) or to the AI assistant, and is not shared with third parties, other than the infrastructure provider (Google Firebase) that stores it on behalf of the Controller. Of the timed study mode data, the AI assistant can read only the deck settings: the selected study mode, the number of daily study minutes and the technical number of these settings; it does not receive the measured study time or answer durations.

Daily study time records are deleted automatically 45 days after the study day (the removal from the database itself usually takes place within a day of that date). The answer duration is kept for as long as the answer history entry it belongs to. Both kinds of data are deleted together with the deck, when the deck's progress is reset and together with the account. Undoing an answer deletes its history entry together with its duration, while the time in the daily record remains, because it reflects time actually spent studying. Until they are saved on the server, ratings together with the measured time may be stored on the device (point 3.9).

3.5. Gamification

Data about study regularity used by the garden mechanism: weather level, daily and total seed counters, the date of the last study session and the list of trophies earned together with their unlock dates.

3.6. Data related to artificial intelligence features

Described in detail in section 7. In short: the content of prompts sent to the assistant, files submitted for processing together with the text extracted from them, the content of conversations with the assistant, the assistant's long-term memory, the flashcard change proposals prepared by the assistant, and metadata for each run (model used, topic, token count, cost, timings).

3.7. Payment and subscription data

Described in detail in section 6. The Controller's database stores: the plan tier, the subscription status, the billing period dates, information about a scheduled cancellation, the identifiers assigned by Stripe (customer, subscription, price, session and payment), a record of purchase intent, the state of the AI credit pool and a summary of the limits arising from the plan.

The Controller does not receive and does not store the payment card number, the CVC code, the expiry date, the card brand, the billing address, the tax identification number or the name shown on the card. That data remains solely with the payment provider.

3.8. Technical, diagnostic and security data

• Information about network availability, used to control synchronisation and to block operations that require connectivity.
• A register of the devices used on the account: platform, application version, date of first and last use.
• A register of the actions performed on the account, used to order operations across devices.
• Security events: rejections by protective gates together with the reason code and the user identifier, without the content of the message.
• Application crash reports collected by Firebase Crashlytics — device model, application and operating system version, the time the error occurred, the call stack and the user identifier, together with abbreviated diagnostic records preceding the crash.
• Register of AI feature failures — a record of events in which a request sent to the assistant ended with no response for technical reasons. The register contains: the account identifier, the date and time of the event, the type of operation, the error code, the error category, the diagnostic trace identifier, the request identifier, the plan in force at the time of the failure and whether the credit was returned to the pool. It contains neither the content of the prompt nor the response. It serves solely to assess refund requests fairly — it makes it possible to confirm a well-founded claim without requiring the user to prove it, and to distinguish it from an unfounded one. The legal basis is the Controller's legitimate interest (Art. 6(1)(f) GDPR). Details are set out in the Refund Policy.
• Record of the consent given at purchase — the fact that consent was given to the immediate commencement of the service, together with a timestamp, a fingerprint of the text to which the consent related, and the IP address and browser identifier used at that moment. The record contains neither order content nor card data. The legal basis is a legal obligation arising from consumer protection law (Art. 6(1)(c) GDPR) and the accountability principle for consent (Art. 7(1) GDPR). Details in point 6.6.
• IP address and browser identifier — stored persistently in two cases only, described in point 6.6: opening the subscription management portal, and recording the consent given at the moment of purchase.
• IP address in request rate limiting — with every message sent to the assistant, the IP address serves as the key of a counter limiting the number of requests per unit of time. The counter lives in a cache for 60 seconds and is neither stored persistently nor linked to message content. The purpose is to protect the service against abuse and excessive load; the legal basis is the Controller's legitimate interest (Art. 6(1)(f) GDPR).
• Forced updates of the mobile application — in key and important cases (backward-incompatible changes in communication with the server, fixing security vulnerabilities), the Controller may require the Android and iOS application to be updated to a minimum version, but only once that version is already available for download on Google Play and the App Store. For this purpose, the application fetches from the server (Google Firebase) a configuration document containing the minimum required version for its platform and compares it with the installed version number on the device. The application version number is not sent to the server for this purpose — the server receives only the platform (Android or iOS), which follows from the address of the document fetched, and technical connection data (e.g. the IP address) to the extent necessary to handle the request. The Controller does not store any data relating to this check on the server. The most recently fetched settings and the highest known required version are stored locally (point 3.9) so that the requirement also applies without an internet connection. A forced update does not delete the user's data. The purpose is to ensure that the service works correctly for the user and that everyone uses only a secure version of the application; the legal basis is the Controller's legitimate interest in ensuring the security and correct operation of the service (Art. 6(1)(f) GDPR).

3.9. Data stored locally on the device

A copy of the data of the most recently signed-in user and a session marker (these enable offline work and a faster start), local application settings, the record of consent to the use of AI features, a cache of the runtime security policy, and a local database of decks and flashcards that keeps the application working without an internet connection. Flashcard ratings not yet saved on the server wait on the device in a queue together with the measured study time (point 3.4) and are removed from it once saved.

The device also holds a local journal of AI feature failures, tied to the signed-in account. It records only those failures the server could not learn about — a dropped connection, a device-side timeout, a response cut off midway. Each entry consists of the date and time, the type of operation, the error code, the server response code and the conversation session identifier; neither prompt nor response content is stored. The journal holds at most the 100 most recent entries and keeps them for 60 days. It is not sent to the server and is not, on its own, evidence in refund proceedings — it serves as a lead supplementing the server-side register described in point 3.8. It disappears when the application is uninstalled or its data is cleared.

The application uses Firebase Analytics and Meta SDK, but the Controller's purpose in doing so is solely to measure the performance of advertising campaigns, carried out only after the user has given a separate consent in the window shown the first time the application is launched — this is described in detail in section 19. Beyond that measurement the application uses no other behavioural analytics tool, displays no advertising and does not send newsletters.

The Controller itself does not use any analysis of user behaviour to show users personalised content, personalised advertising or a personalised product and does not profile individual users for advertising purposes. The only tailoring to a particular person is the operation of the spaced-repetition algorithm and of timed study mode on the basis of that person's ratings and study time, described in point 3.4; it is not used for advertising. With the user's consent, however, the Controller carries out — both on the glimsy.app website and within the application itself — an aggregate measurement of advertising-campaign performance: on the website it checks which pages and elements visitors readily open and which they skip, and which ads they come from (point 18); in the application it checks how many people who saw an ad installed the application, created an account and started using it (point 19). In both cases the Controller's own purpose is limited to reaching its audience better and running better-targeted campaigns; as noted in points 18.1 and 19.1, Meta may nonetheless use the data passed to it for its own purposes as well.

3.10. Data related to measuring the performance of advertising campaigns in the application

Described in detail in section 19. In short: events passed with the user's consent to Meta SDK (application launch, account creation, opening a deck together with the display of the first flashcard and that deck's identifier, entry into the AI features, and, in the browser, starting and completing a subscription purchase) and — in a narrower range — to Firebase Analytics (first launch after installation, screen changes, account creation, and, in the browser, starting and completing a purchase). Accompanying data: the device's advertising identifier, the application instance identifier, the device model and operating system version, the language, the approximate location at country level, and the IP address at the moment of sending.

4. Legal bases for processing

For minors, use of the application may require the consent of a parent or legal guardian where the law applicable to the user's place of residence so provides.

Withdrawing consent to AI features does not affect the lawfulness of processing carried out before the withdrawal and does not restrict the use of the remaining features of the application.

Whether providing data is required. Providing an e-mail address and creating an account is a requirement for concluding and performing the contract for use of the application — without them an account cannot be created, the user's identity cannot be confirmed and materials cannot be synchronised across devices; refusal means the application cannot be used to the extent that requires an account. Providing any other data is voluntary and follows from how the application is used: the content of decks and flashcards is created on the user's initiative, and data passed to the AI features only after separate consent has been given. Refusing to provide data that is not necessary to conclude the contract results solely in the unavailability of the part of the functionality it concerns.

5. Purposes of processing

Creating and maintaining an account; creating, editing, importing and deleting decks and flashcards; enriching flashcards with images and audio; running the study process, scheduling reviews and recording the answer history; measuring study time and operating timed study mode; operating the gamification mechanism; sharing decks with other users at the owner's request; providing artificial-intelligence features; executing and settling payments and servicing paid plans; ensuring security and data isolation between users; preventing abuse, including attempts to obtain AI credits without paying; limiting the rate of requests sent to the assistant; enabling offline operation; diagnosing errors and failures; enforcing updates of the mobile application to a secure, server-compatible version; measuring the performance of advertising campaigns on the website and in the application, only with consent (points 18–19).

6. Payments and subscriptions

6.1. Who the seller is

Payments in Glimsy are handled under the Stripe Managed Payments model. This means that the merchant of record is Stripe, not Glimsy sp. z o.o.

In practice:

• On the card statement the user will see the descriptor LINK.COM* together with the transaction description, and the purchase is described as "Sold through Link".
• Receipts and invoices are issued by Stripe — the entity shown on the document is, as a rule, Sold through Link, LLC. In countries where Stripe does not take over tax settlement, the invoice contains the details of Glimsy sp. z o.o.
• VAT is calculated, collected, reported and remitted by Stripe — this covers Poland and the entire European Union as well as more than eighty other countries.
• All transactional messages — receipts, invoices, refund confirmations, credit notes and some subscription notifications — are sent by Stripe.
• Payment disputes (chargebacks) are handled by Stripe on its own account.
• The user is given access to a Link account, where they can review their order history, cancel the subscription, and change the payment method and billing details.

Glimsy sp. z o.o. remains the provider of the service — it is responsible for its content, quality, availability and substantive support. The Terms of Use describe this division in detail.

6.2. Data passed to the payment provider

In order to complete a purchase, the Controller passes the following to Stripe: the user's account identifier, the e-mail address, the selected plan, the amount, the currency and the billing period.

Payment card details are entered by the user directly on Stripe's page — they never pass through the Controller's systems. Stripe applies the Payment Card Industry Data Security Standard (PCI-DSS) and, in relation to payment data, acts as an independent controller under its own privacy policy, available at https://stripe.com/privacy.

Transactions are settled by one of the Stripe entities acting as acquirer: Stripe Payments Company or Stripe Technology Europe, Limited.

6.3. What Stripe passes back

The Controller receives only data that contains no sensitive information: the customer, subscription, price, session and payment identifiers, the amount, the currency, the payment status and the billing period dates.

6.4. Deletion of data held by Stripe

The user may apply directly to Stripe for the deletion of data relating to purchases made under this model. Stripe will then cancel the subscription and delete the relevant data also from the Controller's Stripe account, informing the Controller of that fact. Such a request may result in the termination of paid access to the application.

6.5. AI credits

Use of AI features is settled in credits granted together with the plan. The Controller stores the state of the credit pool, the amounts reserved and consumed, and the dates of the period the pool relates to. A trail of the decision to allow or reject a paid operation is also recorded — which plan was in force and what the estimated cost was.

6.6. IP address and browser identifier

The IP address and the browser identifier (User-Agent) are stored persistently in two situations.

First: each time the subscription management portal is opened, together with the session identifier and the time of opening.

The sole purpose is to be able to demonstrate who made a change to the subscription and when — in particular a cancellation — in the event of a payment dispute or a challenged transaction. The legal basis is the Controller's legitimate interest (Art. 6(1)(f) GDPR) in defending against unjustified chargebacks.

Second: at the moment of proceeding to purchase, together with a timestamp and a fingerprint of the declaration displayed at that moment. This record is the proof that the user requested performance to begin before the withdrawal period expired and was informed of the consequences — an obligation under Art. 15(3) of the Polish Consumer Rights Act and under the accountability principle for consent (Art. 7(1) GDPR). Without it the Controller would have nothing with which to show that the declaration was made at all. The record contains neither order content nor card data.

Both records are append-only and are not deleted together with the account. Their purpose is to evidence a fact against the very party who may later dispute it, so erasing them at that party's request would defeat them — the ground provided by Art. 17(3)(e) GDPR (establishment, exercise or defence of legal claims). The purchase-consent record is kept for six years, like the payment documentation it belongs to.

Outside these two cases the IP address is not stored persistently. The brief, sixty-second use of the IP address in the request rate-limiting counter is described in point 3.8.

7. Artificial intelligence features

7.1. Nature of the features and consent

The AI features are a prototype, are available only within paid plans and require separate, explicit consent given in the application before first use. Consent may be withdrawn at any time in the settings — withdrawal disables the AI features without affecting the remaining capabilities of the application.

7.2. What data reaches the model providers

The following is passed to external language model providers:

• the content of the prompt entered by the user, unaltered,
• files submitted for processing — text documents as extracted text, and images and PDF pages in graphical form,
• fragments of the user's existing flashcards, passed as context so that newly created material does not duplicate what the user already has,
• the content of earlier messages in the conversation and the assistant's long-term memory (point 7.5).

Neither the account identifier nor the e-mail address is included in the content sent to the models.

The Controller does not pseudonymise or anonymise content before passing it to a provider. Users should bear this in mind and should not place in prompts or in submitted files any data they do not wish to send outside the application — in particular other people's personal data and information covered by confidentiality obligations.

PDF documents are converted to images locally on the Controller's server; the PDF file itself is not passed to the model provider.

The application does not transcribe audio recordings — no such feature exists and no speech recognition provider is used.

7.3. Model providers

The Controller does not use models from providers outside the list above and, in particular, does not send data to providers outside the European Union and the United States.

The Controller reserves the right to change a provider or a model where justified by the quality, cost, availability or security of the service. This applies in particular to auxiliary models used for validation and moderation — models from other providers available through OpenRouter, for example Anthropic, may be used in that role. The current list of providers is maintained in this policy, and users will be informed of the addition of a new provider in accordance with section 17.

7.4. Use of content for model training

In every request sent to OpenRouter the Controller sets a preference to route traffic only to providers that do not store content non-transiently and do not use it to train models (the data_collection: deny parameter in OpenRouter's documentation). This applies to all generative requests — creating and assessing flashcards, conversations with the assistant, reading text from images, the research mode, moderation and prompt-manipulation detection.

That preference governs the choice of the model provider. OpenRouter itself, as the intermediary, processes the data passed to it in accordance with its own privacy policy and the agreement concluded with the Controller.

For the provider the Controller connects to directly — Google Cloud Vertex AI — that provider's own terms and privacy policy apply.

The Controller does not use user content to train its own models.

7.5. Assistant memory

The assistant has a long-term memory which by design remembers information the user gives in conversation — for example a name, study goals or preferences — and recalls it in later conversations in order to tailor its answers. Remembered information is passed to the model provider with every subsequent message.

A user who does not want particular information to be remembered should not give it to the assistant in conversation.

7.6. Files submitted to AI features

Supported formats: PDF, TXT, MD, DOCX, PPTX, PNG and JPEG. The following limits apply: 50 MB per file, 10 files per message, 100 files per session, 100 uploads per day, and a total account capacity of 5 GB and 500 files.

Files are stored in Firebase Storage, in the area assigned to the user's account, together with the text extracted from them. Files with identical content are not duplicated.

Files remain available until the user deletes them or the account is deleted — the user retains control over them and may delete them at any time. Files are not deleted automatically after a predetermined period.

7.7. Safeguards

The Controller makes every effort to ensure that the AI features do not generate inappropriate content and are not vulnerable to abuse. The measures applied include, among others: a prohibited-intent filter operating before the model is called at all, moderation of generated flashcards by a separate model, detection and removal of personal data and profanity from responses, a control preventing the disclosure of another user's data, and multi-layered detection of prompt manipulation attempts. The gates operate in deny mode where there is doubt.

The application of these measures is not a guarantee. Given the nature of language models, the Controller cannot ensure that generated content will always be correct, complete or appropriate. The rules on liability for AI-generated content are set out in the Terms of Use.

7.8. What we record about AI usage

The content of conversations with the assistant, the assistant's memory, the flashcard change proposals prepared, and metadata for each run: the model used, the topic, the token count, the cost and processing times. The metadata serves credit settlement and quality analysis; on account deletion the topic is erased and the user identifier is replaced with an irreversible hash.

Model responses may be held temporarily in a cache for 24 hours, and provider-side context for 2 hours.

Full archiving of prompt and response content for diagnostic purposes is disabled in the production environment and cannot be enabled without a code change.

8. Sharing decks with other users

A user may share their own deck by generating a sharing code. Use of this feature is voluntary.

What to know before sharing:

• The person who receives the code sees the deck name, its description, the number of flashcards and the owner's technical identifier. They do not see the owner's user name or e-mail address.
• From the moment a deck is shared, its basic details become visible to every signed-in and verified user of the application, not only to the person given the code. The content of the flashcards remains inaccessible until the code is used.
• The code may be single-use — in that case, its use by the first person closes off any further use.
• A copy of the deck made by the recipient becomes their own data; later withdrawal of sharing or deletion of the original does not remove the copy from their account.
• The Controller maintains an internal register of the provenance of deck copies, accessible to the Controller only.
• Sharing can be switched off at any time — the code then stops working and no new person can copy the deck. For security reasons the record that sharing took place remains in the database in an inactive form; its sole purpose is to make it impossible to reactivate or reuse a code once revoked.

9. Recipients of data

The Controller does not sell personal data and does not disclose it for marketing purposes, with two exceptions: with the consent of a visitor to the glimsy.app website, the visitor's browser passes to Google and Meta technical data used to analyse traffic and measure the performance of the Controller's marketing campaigns (point 18); and with the consent of a user of the mobile or browser application, the same companies receive technical data used to measure the performance of the Controller's advertising campaigns within the application (point 19).

Data may be disclosed to the following categories of recipient:

10. Transfers outside the European Economic Area

The core infrastructure of the application is located within the European Union: the Firestore database runs in the multi-region eur3 (Belgium and the Netherlands), and the server functions and the flashcard vector comparison service run in region europe-west1 (Belgium).

OpenRouter, Inc. — the only AI provider with which the Controller has a direct contract — is a United States entity, as are the model providers to which OpenRouter routes requests (point 7.3). Data passed as part of the AI features may therefore be processed outside the European Economic Area. The same applies to Google LLC and Meta Platforms, Inc. (points 18 and 19), Stripe, Resend and to some Google and Expo services. The vector comparison of flashcards in Google Cloud Vertex AI takes place in the europe-west1 region.

These transfers take place on the basis of the mechanisms provided for in data protection law, in particular standard contractual clauses and, for providers covered by an appropriate programme, adequacy decisions.

A copy of the safeguards applied, or information about where they have been made available, can be obtained by writing to support@glimsy.app.

11. Retention periods

User data is stored for as long as the account exists. The Controller does not delete accounts merely for inactivity, so that a user can return to studying with their existing progress intact.

Exceptions:

• Trash — decks and flashcards moved to the trash are permanently deleted after 7 days, unless the user restores them earlier.
• Daily study time records of a deck (point 3.4) — 45 days from the study day, after which they are deleted automatically. The answer duration is kept for as long as the answer history entry it belongs to.
• Accounting documentation — the audit of payment events is retained for 6 years, in accordance with tax and accounting legislation, including after the account is deleted.
• Records serving the defence against payment disputes and abuse — the subscription portal access log, the trail of decisions granting paid access, credit consumption registers and security events — are retained for as long as the Controller's legal obligation or legitimate interest lasts. Security events must survive account deletion, because otherwise deleting the account would be a way to erase the traces of abuse.
• Generation metadata and cost registers — the document is retained, while the content and the user identifier are, on account deletion, erased and replaced with an irreversible hash respectively.
• AI response cache — 24 hours.
• Register of AI feature failures — 6 years, the same as the accounting documentation it is connected with. The register serves solely to verify refund requests; its contents are enumerated in point 3.8. These records survive account deletion, because otherwise deleting the account would make it impossible to deal with a refund request submitted earlier.
• Record of the consent given at purchase — six years, like the accounting documentation of the payment it belongs to. It is not deleted together with the account (Art. 17(3)(e) GDPR).
• Data on the performance of advertising campaigns (Meta SDK, Firebase Analytics, points 18–19) — on the Controller's side, visible only as aggregate campaign statistics; the retention period for the underlying events on Google's and Meta's side follows those providers' own retention settings, over which the Controller does not have full control. The record of the consent decision (and any withdrawal of it) is stored locally on the user's device or in the browser, until that decision is changed.

The Controller does not maintain its own long-term backups of user data. Solely for service continuity and recovery after a failure, the application database is backed up automatically in the Google Cloud (Firebase) infrastructure within the European Union: copies made daily and once a week are deleted automatically after 7 days, and the ability to restore the database to a chosen moment covers the last 7 days. Before a service update that changes how data is stored, the Controller may make a one-off copy of the database, deleted automatically after 30 days. Data of a deleted account may remain in these copies until they are deleted automatically; the copies are not used for any other purpose.

12. Account deletion

The user may delete the account in the application settings. The operation requires an internet connection.

The following are deleted: the Firebase Authentication account; the user document together with settings, subscription data, the credit pool, gamification data, the device register and the action register; all decks together with flashcards, answer history (including answer durations), study sessions and daily study time records; the content of conversations with the AI assistant and its memory; media metadata; all of the user's files in cloud storage, including images, audio files and files submitted to the AI features.

The process usually takes a matter of seconds and in some cases may take up to a few hours.

Beyond the records listed in section 11, the following also remain after account deletion: metadata of assistant conversation sessions, unapproved flashcard change proposals prepared by the assistant, a technical marker guarding against a repeated request, records of deck shares that were made, the internal register of the provenance of deck copies, the register of AI feature failures, the record of payment intents and credit top-ups, the records of the consent given at purchase, and — stripped of user content — the cost diagnostics of AI runs. The user may request the deletion of these records at support@glimsy.app; the Controller will delete them unless a legal obligation or an ongoing complaint procedure prevents it.

Deleting the account in the application does not delete data held by Stripe in connection with purchases made — for that, the user should apply directly to Stripe (point 6.4).

13. User rights

The user has the right of access to their data, and the rights to rectification, erasure, restriction of processing, data portability, objection to processing based on legitimate interest, and to lodge a complaint with a supervisory authority — in Poland this is the President of the Personal Data Protection Office (Prezes Urzędu Ochrony Danych Osobowych), ul. Stawki 2, 00-193 Warsaw.

Where processing is based on consent — which is the case for the AI features — the user has the right to withdraw it at any time.

13.1. Exercising rights in practice

Most rights can be exercised by the user directly in the application: deleting the account together with the data, reviewing account, deck and progress data, changing settings, withdrawing consent to AI features, deleting uploaded files.

For matters requiring manual handling — for example issuing a copy of the data — please write to support@glimsy.app, from the e-mail address linked to the account or indicating that address in the message. The Controller may refuse to act on a request if it is unable to reliably confirm the identity of the person making it.

Responses are given within the periods provided for by law.

13.2. No automated decision-making

The Controller does not apply to users automated decision-making producing legal effects or similarly significantly affecting them within the meaning of Art. 22 GDPR. The spaced-repetition algorithm serves solely to calculate the study schedule, and the AI security gates are limited to allowing or rejecting a single operation in the application.

The review schedule is calculated automatically on the basis of the ratings given by the user; the answer duration currently does not affect it. Calculating the schedule on the basis of study results may constitute profiling within the meaning of Art. 4(4) GDPR; it serves study only, not advertising. In timed study mode, the application selects flashcards for study on the basis of the measured time and, once the number of minutes chosen by the user has elapsed, offers to end the day's study of the deck. None of these determinations is a decision based solely on automated processing that produces legal effects or similarly significantly affects the user within the meaning of Art. 22 GDPR: they only determine when and which flashcards appear in study, do not affect access to the application, the plan, the price or any other rights of the user, and the user can at any time change the study settings, finish the reviews after the time has elapsed ("Finish") or reset a deck's progress. To the extent that processing is based on Art. 6(1)(f) GDPR (recording the answer duration in order to improve the spaced-repetition algorithm), the user has the right to object under Art. 21 GDPR (point 13.1).

14. Data security

The measures applied include: encryption in transit (HTTPS/TLS), authentication and authorisation on the Firebase Authentication side, database security rules restricting access to the data owner alone and blocking access once account deletion has begun, application integrity verification (App Check), verification of the signature of messages from the payment provider, replay-resistant controls, and a set of controls protecting against paid access being granted without payment.

Despite these measures, the risk associated with processing data in IT systems cannot be entirely excluded. Should a personal data breach be identified, the Controller will take the steps required by law, including — where necessary — notifying the supervisory authority and the users.

15. Browser version — local storage

In the web version the application uses browser mechanisms (Local Storage, IndexedDB and similar) in order to maintain the session, remember settings and provide offline operation and a data cache.

The local journal of AI feature failures described in point 3.9 is stored by the same means, as is the record of the consent decision on measuring the performance of advertising campaigns (analytics and marketing), described in point 19.4.

These mechanisms serve solely to maintain the session, remember settings and enable offline operation — on their own they do not personalise advertising or content and do not serve the sale of data. Measuring the performance of advertising campaigns in the browser version, described in point 19, takes place through separate tools (Meta SDK, Firebase Analytics) and only after consent has been given. The user may remove local data by clearing browser data for the application's domain.

16. Notice for California users (CCPA/CPRA)

The Controller itself does not sell personal data and does not use it to build behavioural profiles of users for advertising purposes (the operation of the spaced-repetition algorithm and of timed study mode is described in point 3.4). The tools described in points 18 (website) and 19 (application) serve the Controller solely for aggregate traffic analysis and measuring the performance of its own advertising campaigns, not for building profiles, and operate only after the visitor's or the application user's consent, which can be withdrawn at any time or simply not given. Because Meta Platforms Ireland Limited also processes the data it receives this way for its own purposes, including ad selection (points 18.1 and 19.1), passing this data to Meta may constitute a "sale" or "sharing" within the meaning of the CCPA/CPRA. A California resident may object to this by withdrawing consent as described in points 18.4 and 19.4, and may request that such disclosure stop by writing to support@glimsy.app.

Users covered by those laws have the right to know the categories and specific pieces of personal information processed, the right to deletion (subject to statutory exceptions), the right to correction, the right to limit the use of sensitive information, and the right not to be treated adversely for exercising these rights. Requests should be sent to support@glimsy.app.

17. Changes to the policy

The policy may change, in particular where new features are introduced, the scope or manner of processing changes, providers change, or legislation or supervisory authority guidance changes.

The current version is always available at https://glimsy.app/en/privacy-policy/ (Polish version: https://glimsy.app/pl/privacy-policy/) and may also be presented in the application settings. Users will be informed of material changes — new categories of data, new purposes of processing, a change of controller or the addition of a new AI model provider — by a message in the application or in another appropriate manner. If the law requires fresh consent, the user will be expressly informed of this.

18. The glimsy.app website — traffic and campaign-performance analysis

18.1. Purpose and scope

With the visitor's consent, given separately for each tool, the glimsy.app website uses two tools: Google Analytics 4 (Google Ireland Limited) and Meta Pixel (Meta Platforms Ireland Limited). They serve solely for aggregate analysis of traffic on the website and for assessing the performance of marketing campaigns: the Controller wants to know which pages and elements visitors readily open and which they skip, and which ads they come from, in order to reach its audience better and run better-targeted campaigns.

The Controller does not carry out profiling analysis of individual users. It does not build profiles of people, does not assess or predict the behaviour or characteristics of particular people, does not link this data to accounts in the application and does not use it to personalise content, advertising or the product. It sees the results only as aggregate statistics. In Google Analytics, Google signals and ad personalisation are turned off, and consent covers only the storage of analytics data. This section covers only the glimsy.app website. A comparable but separate measurement of advertising-campaign performance within the Glimsy mobile and browser application itself — with its own tools, its own consent and its own scope of data — is described in point 19.

Meta may, however, use the data collected by Meta Pixel for its own purposes as well, including ad selection, under the rules set out in its privacy policy — the Controller has no influence over this.

18.2. Google Analytics — what data, and who sees it

After consent is given, the visitor's browser passes to Google: the address and title of the page visited, the address of the referring page (including campaign parameters), events on the page (page views, scrolling, clicks on outbound links and similar), information about the device and browser, approximate location (country, city) and a random identifier stored in the _ga and _ga_* cookies (valid for up to 2 years). Google Analytics 4 does not log or store IP addresses, although the IP address reaches Google's servers at the moment the measurement is sent. In this respect Google is a processor acting on behalf of the Controller. The Controller sets the data retention period in Google Analytics to 14 months.

18.3. Meta Pixel — what data, and who sees it

After consent is given, the visitor's browser passes to Meta: the page address and title, the address of the referring page (including the parameters of the advertisement the visitor came from), the IP address, the browser identifier (User-Agent) and an identifier stored in the _fbp cookie (valid for up to 90 days; if the visitor came from an advertisement, also _fbc). The Controller does not receive from Meta any data identifying individual people — it sees only aggregate campaign statistics. On Meta's side this data is not fully anonymous: the cookie identifier and IP address may be linked by Meta to its own accounts and used in accordance with its rules (Meta’s privacy policy). In this respect the Controller and Meta are joint controllers (Article 26 GDPR); the Controller is responsible for the information and for obtaining consent, and rights regarding data processed by Meta can also be exercised directly with Meta.

18.4. Consent and withdrawing it

Neither tool is loaded until the visitor consents in the window asking for consent: until then the browser does not connect to Google's or Meta's servers. Consent can be given for all tools at once (“I agree”), only for selected ones (after expanding the “Choose services” list and turning on the switches, which are off by default), or refused for all (“No, thanks”). Refusal does not limit use of the website.

Consent can be changed or withdrawn at any time — also for a single tool — with the “Cookies” button in the footer of every page; withdrawal removes the tool's cookies and does not affect the lawfulness of processing carried out before it. The record of the decision itself (the value for each tool and the date) is kept in the browser's local storage and is necessary to remember the choice.

18.5. Transfer outside the EEA

Google and Meta may transfer data to their companies in the United States (Google LLC, Meta Platforms, Inc.). The transfer relies on an adequacy decision (the EU–U.S. Data Privacy Framework) or on standard contractual clauses.

19. The mobile and browser application — measuring advertising-campaign performance

19.1. Purpose and scope

With the user's consent, given separately for analytics and for marketing in a window shown the first time the application is launched — before signing in — the Glimsy application (iOS, Android and the browser version) uses two tools: Meta SDK (Meta Platforms Ireland Limited) and Firebase Analytics, built on Google Analytics 4 (Google Ireland Limited). The Controller's purpose in doing so is solely to measure the performance of advertising campaigns: the Controller wants to know how many people who saw an ad installed the application, created an account and started using it, in order to reach its audience better and run better-targeted campaigns.

The Controller does not build psychological or behavioural profiles of individual people on this basis. It does not assess or predict the characteristics or behaviour of particular users, and does not personalise content, advertising or the product on this basis. It sees the results only as aggregate campaign statistics.

Meta may, however, also use the events it receives for its own purposes, including ad selection, under the rules set out in its own privacy policy — the Controller has no influence over this.

Before consent is given, neither tool is activated and the application does not connect to Meta's or Google's servers for measurement purposes. Declining consent does not restrict anything — all features of the application work the same way without it.

19.2. Meta SDK — what data, who sees it, what role

After consent to marketing is given, the application passes to Meta Platforms Ireland Limited the following events: application launch, account creation, opening a deck together with the display of the first flashcard — including the identifier of the deck opened — and entry into the artificial-intelligence features. In the browser version, additionally: opening a page of the application, starting a subscription purchase, and a completed purchase together with the amount, the currency, the plan name and the payment session identifier (this last one serves only so that Meta can recognise a repeated report of the same transaction and not count it twice).

Two things we do not pass to Meta: screen changes, and — in the mobile version — the start and the completion of a purchase. A subscription is bought in the browser only, so on iOS and Android those events never occur at all.

Passed together with the events are: the device's advertising identifier (on iOS, only after separate consent in Apple's system window — point 19.5; on Android, the Google advertising identifier), the application instance identifier, the device model and operating system version, the language, the approximate location at country level, and the IP address at the moment of sending.

As regards the events passed to Meta, the Controller and Meta are joint controllers of the data (Article 26 GDPR): the Controller is responsible for the information and for obtaining consent, while Meta processes the data it receives also for its own purposes — including ad selection — as an independent controller, under the rules of its own privacy policy (Meta's privacy policy).

19.3. Firebase Analytics — what data, who sees it, what role

After consent to analytics is given, the application passes to Google Ireland Limited the following events: the first launch of the application after installation, screen changes (the screen name only, without deck or flashcard identifiers), account creation, and, in the browser version, additionally the start of a subscription purchase and a completed purchase together with the amount, the currency, the plan name and the transaction identifier.

The range of events passed to Google is narrower than the one in point 19.2: opening a deck and entering the artificial-intelligence features go to Meta only, and Google does not receive them. Google is also given no deck or flashcard identifier whatsoever.

The accompanying data are: the application instance identifier and, on Android, the Google advertising identifier, the device model and operating system version, the language, the approximate location at country level, and the IP address at the moment of sending.

In this respect Google is a processor acting on behalf of the Controller, and does not use this data for its own purposes.

19.4. Consent and withdrawing it

Consent to analytics and consent to marketing are given separately, in the window shown the first time the application is launched, before signing in. Until the user gives consent, neither tool is activated.

Consent can be withdrawn at any time in the application's Settings, with one switch for each tool. Withdrawal disables further data collection and does not affect the lawfulness of processing carried out before the withdrawal. The record of the decision itself is stored locally on the user's device, and, in the browser version, in the browser's local storage (point 15).

19.5. iOS — a separate system-level consent (App Tracking Transparency)

On iOS, independently of the consent described in point 19.4, iOS shows its own window asking for consent to tracking (App Tracking Transparency). Without consent in that window, the device's advertising identifier is not used, even if the user gave consent in the in-app window described in point 19.4.

20. Contact

Glimsy sp. z o.o.
ul. Zapłocie Duże 223A, 43-300 Bielsko-Biała, Poland
support@glimsy.app