Glimsy Privacy Policy

Effective date: 31 August 2026
Version: 2.0 (supersedes the version of 9 July 2026)

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.

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 response time 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.

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).

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.

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 does not use Firebase Analytics or any other behavioural analytics tool. It displays no advertising, does not profile users for marketing purposes and does not send newsletters.

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; 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.

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.

Data may be disclosed to the following categories of recipient:

The Controller does not use behavioural analytics tools, advertising systems or marketing platforms.

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 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.
• 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).

The Controller does not maintain its own long-term backups of user data. Data may be present in the standard copies created by the infrastructure provider solely for service continuity purposes.

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 and study sessions; 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.

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.

These mechanisms do not serve behavioural advertising or the sale of data. The user may remove local data by clearing browser data for the application's domain.

16. Notice for California users (CCPA/CPRA)

The Controller does not sell personal data and does not share it for behavioural advertising purposes within the meaning of the CCPA/CPRA.

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. Contact

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