Clikr

Privacy Policy

Last updated: October 23, 2026

This policy explains how Clikr handles personal data and the rights you have under the EU General Data Protection Regulation (GDPR), the UK GDPR, the revised Swiss Federal Act on Data Protection (revFADP), the California Consumer Privacy Act as amended by the California Privacy Rights Act (the CCPA), and other applicable privacy laws.

Data controller

The data controller for personal data processed through Clikr is Mawal AB, a Swedish private limited company registered in Sweden under Org.nr 559279-0462 (VAT SE559279046201), with its registered office at Hallandsgatan 38, 118 57 Stockholm, Sweden. For any privacy question, or to exercise the rights described below, write to us at hello@clikr.app or by post at the registered address above.

What we collect

Clikr turns your phone into a wireless pointer for presentations. We deliberately collect very little, and the pointer movement itself never reaches us. The categories below are everything we process.

  • Session data. When you pair your phone with the browser extension, a temporary session record is created so the two devices can find each other. It holds a session identifier, a sign-in identifier for each device (an anonymous one unless you have signed in), and the connection setup data the two devices exchange through it (technical connection details known as SDP and ICE candidates), which include the IP addresses of both devices. The session identifier appears in the address of the pairing screen, so we remove it from that address before any analytics or error report leaves your device or our servers. The record is not deleted at the moment your session ends: it carries a fixed expiry set when the session starts, about 23 hours later, and is deleted automatically, together with any connection setup data still in it, once that expiry passes. That automatic deletion usually completes within a further day.
  • Device motion and pointer data. Pointer position and gesture data is sent in real time between your phone and the extension. It never reaches our servers. Where your two networks allow it, this data travels directly between your phone and your computer; where they do not, it is relayed through Metered, our relay provider, in a form the relay cannot read (see "What travels between your devices" below).
  • Camera images. If you use the QR code scanner on the pairing screen, your phone's camera runs only while the scanner is open. The images are read on your phone to find the QR code and are never sent to us or anyone else, and never stored. We do not collect them.
  • Anonymous account data. When you open the pairing screen on your phone without being signed in, it signs in to Firebase Authentication anonymously, before any pairing takes place and without asking you for anything. The browser extension does the same on your computer when it prepares a pairing. Each anonymous sign-in creates an account identifier: a random code with no name or email address attached, which is also the sign-in identifier that device puts in the session record described above. Your browser keeps the pairing screen's identifier and uses it again on later visits, until you sign in on that browser, its site data is cleared, or the identifier is deleted after 180 days without use (see "Retention" below). After any of these, the pairing screen's next anonymous sign-in creates a new identifier with a new user record. Under each such identifier we keep a user record in our Firestore database. It holds the plan the identifier is on, which is always the free plan, when the record was created, and any settings you change on the pairing screen, such as the pointer trail or whether speaker notes are shown, so they are remembered. The extension's identifier has no user record.
  • Account data. If you sign in, we store your email address and an account identifier in Firebase Authentication so we can associate a Clikr Pro purchase or a Pro free trial with your account. That account has a user record of its own, separate from any anonymous one. It holds the same plan and settings information, plus your Pro and trial status, the Paddle transaction identifiers of your purchases, which of them were reversed by a refund or chargeback, the time of the latest Paddle event about them, and, if you answer the referral question described below, your answer and when you gave it. It also holds your email preference: whether you asked for product update email, when and where you made that choice (such as the sign-up form or your account settings), and which version of the wording you were shown; a later change replaces the earlier one. We also keep a contact record for your account at Plunk, our email provider, so we can send you the email described under "Email we send you", which lists what that record holds. Signing in is only needed for Pro.
  • Automatic pairing data. Automatic pairing lets a phone signed in with Clikr Pro or a Pro free trial connect to a computer it has paired with before, without scanning that computer's QR code again. It works only where both the pairing screen and your browser extension support it, and it relies on two kinds of record in our Firestore database. A browser extension that supports automatic pairing saves a pairing channel record for its installation once it has been paired with an account as described below, and from then on updates that record whenever it prepares a pairing, including after it is unpaired. An installation that has never been paired that way saves no pairing channel record. The record is filed under a random code the extension creates for that installation. If that record turns out to be held by a different anonymous account, for example because the extension's own anonymous account identifier changed, the extension creates a new code and starts a new record. The extension's QR code carries that code into the address of the pairing screen, and we remove it from that address before any analytics or error report leaves your device or our servers, as we do the session identifier. Once a phone signed in with Clikr Pro or a Pro free trial, with the Connect without scanning switch on, has paired with the extension, the extension sends each phone that connects to it the name of the browser it runs in (such as Chrome or Firefox) and the operating system of the computer (such as macOS or Windows), over the direct connection between them. Only a phone signed in with Clikr Pro or a Pro free trial, with that switch on, keeps them, in its list of paired devices, so it can tell the computers in that list apart. In Firefox the extension sends them only while Firefox's technical and interaction data setting for Clikr is on; you can switch that setting off when you install the extension or later in Firefox's add-on settings, and pairing works the same without them. Switching it off stops the extension sending them from then on; a browser name and operating system a phone has already saved stay in its pairing record, and so in its list of paired devices, until that computer is removed from the list. Neither value is part of the QR code or of any address, so they do not reach our web server, analytics or error reports through the pairing screen's address; they reach our database only inside the pairing record saved under your account, described below. The pairing channel record holds the identifier of the latest session the extension started, when it was last updated, and the extension's anonymous account identifier. Anyone signed in to Clikr, including with an anonymous sign-in, who has the installation's code, for example from one of the extension's QR codes, can read the record; the records cannot be listed or searched. Where the pairing screen supports automatic pairing and you are signed in with Clikr Pro or a Pro free trial, two more things happen while the Connect without scanning switch is on. First, pairing through the QR code of such an extension, or the link behind it, saves a pairing record for that extension under your account's user record. It holds the installation's code, the extension's anonymous account identifier, when the record was saved, and, when the extension sends them as described above, the name of the browser the extension runs in (such as Chrome or Firefox) and the operating system of the computer it runs on (such as macOS or Windows). Second, connecting to such an extension, including one on someone else's computer, makes it store your account identifier on that computer and become paired with your account, replacing any earlier pairing. Until it is unpaired, each session it starts gets an identifier made from your account identifier and the extension's anonymous account identifier, so both can appear in the address of the pairing screen and are stored in the session record and in the pairing channel record. While the switch is off, neither happens: no pairing record is saved under your account, and connecting to such an extension clears any pairing it holds with your account instead.
  • Payment data. If you buy Clikr Pro, the Paddle entity shown in checkout and on your order confirmation collects your payment details and billing address directly from you. We receive only downstream order information from Paddle, such as the transaction identifier and the email address you used at checkout. When you open checkout, we send Paddle your account identifier with the transaction, so the purchase can be matched to your account. We also give Paddle the email address on your account, to fill in the checkout form for you. When you open checkout, we also keep our own record of who that checkout belongs to, filed under the Paddle transaction identifier and holding your account identifier and when you opened it. We make one for every checkout you open, including ones you do not complete. Your account also has one checkout record, updated each time you start a new checkout, that limits how many checkouts your account can open in a short time and lets a checkout you reopen within a few minutes reuse the same transaction. It holds the latest checkout's transaction identifier, its checkout address and when it was created, and how many new checkouts you started in the current 24-hour period and when that period began. We do not receive or store full card details.
  • Diagnostic and error data. On the production site, our error monitoring tool records error and exception details, console warnings and errors, and failed network request details so we can find and fix faults. It also records diagnostic messages we send deliberately when nothing has failed, for example when pairing succeeded but took longer than expected; those carry the same kind of timings, counters and short fixed labels as the analytics events described below. Reports sent from your browser can include technical context such as an IP address and the address of the page they came from, with the session identifier removed as described above. Reports and performance traces sent from our own servers are narrower: they carry the address, method, route and timing of a request, never its headers, body, cookies, or IP address. A server-side report can still contain your account identifier when that identifier is part of the fault being logged, for example a failed purchase or trial activation. If you allow the Performance category in our cookie banner, it also captures a short error-triggered session replay, with all text masked and all images and media blocked.
  • Analytics data. We use Vercel Analytics for usage statistics. It records page views and visitor counts, and the app sends a small set of custom product events of its own. Most of them record only that something happened, for example that the pointer was switched on, that a slide was changed, that the calibration control was held, that a connection dropped, that a link to the Chrome Web Store or Firefox Add-ons was opened, or that a request to rate Clikr was shown. The events about setting up a pairing carry a little more: how long each step of the connection took and the time limits we set for it, which step was slowest or where it stalled, which attempt it was, a short fixed label for why a pairing was refused, and yes or no flags such as whether the connection had ever succeeded. The event for a new user's first successful pairing carries one label for where that user first came from: a campaign tag from the link they followed, or a broad category of the site that sent them, such as a search engine, a social network, an AI assistant or an extension store, and never that site's address. When you first install the browser extension, it opens a welcome page on our site, which sends one event that the extension was installed, carrying one label of the same kind, worked out the same way. The welcome page may also ask an optional question about how you heard about us, with a fixed list of answers. If you choose one, it sends one more event carrying one label of the same kind: the campaign tag from the link you followed if there was one, otherwise the answer you chose. Later events from the same browser that carry this label use your answer in place of the broad category, unless the link you followed carried a campaign tag. One event records that a presenting session reached a coarse length, 5, 15, 30 or 60 minutes after it first connected, and is sent only when you use a control. Like a page view, each event also carries the context Vercel Analytics records for itself, such as the address of the page it happened on, where you came from, basic device information like your browser and operating system, and a coarse country worked out from your IP address. On the pairing screen we replace the session identifier in that address with a placeholder before the event is sent, so the identifier itself is never transmitted. What we attach ourselves is limited to the measurements and labels listed here, plus the referral answer described below: none of it is an account identifier, a token, your pointer or motion data, or the content of anything sent between your phone and the extension. Vercel Analytics uses no cookies and stores nothing on your device. If you allow the Performance category in our cookie banner, the app itself keeps that first-visit label in your browser, together with your answer to the welcome page's question if you gave one, with a note that the first-pairing event was sent, as listed in our Cookie Policy.
  • Referral source. After you create an account, we may show a one-time, optional question asking where you heard about us. If you choose an answer, we store it with your account to understand how people find us, and we count it in aggregate in Vercel Analytics. Answering is optional, and if you skip the question nothing is stored. The welcome page that opens when you install the browser extension may ask the same kind of question. That answer is optional, is a choice from a fixed list, and is not stored with any account; if you allow the Performance category, it is kept in your browser with the first-visit label described above. If you skip it, nothing is recorded or sent.

We also use this data for two internal purposes. First, we produce statistics for running the business. They draw on the anonymous account and account data described above, including the times Firebase Authentication records for when each account was created, last signed in and last used; on the session and automatic pairing records; on the checkout records described under Payment data, including checkouts that were not completed; and on the order information Paddle holds about those checkouts and about the purchases recorded on accounts. For example, they show how many accounts were created or used in a period, how many are on Pro or a free trial, how many trials were followed by a purchase, how many checkouts were not completed, and how many purchases, refunds and chargebacks there were. They also count how many account deletions our daily deletion job finished or has still to finish, from the deletion records described under Retention. These statistics are counts and totals, plus the amount of each recent purchase, refund and chargeback and whether a purchase followed a free trial, shown without any name, email address or account identifier. They are seen only within Mawal AB; they are not published or shared, and nothing is decided about you from them. Second, when you contact us about your account or a purchase, or when we need to look into a payment, refund or chargeback, we look up that one account's records, including what Paddle holds about its transactions.

Where the data comes from

Most of the data above you give us directly, by opening the pairing screen, pairing a device, signing in, or contacting us. Two categories reach us from a third party. Downstream order information comes from Paddle: the transaction identifier when you open checkout, and the rest after you complete a purchase. For the internal statistics and account lookups described under "What we collect", we also receive from Paddle the status, amount and dates of checkouts you opened but did not complete. Your federated-login identifier comes from Firebase Authentication when you sign in. Where automatic pairing is used, one more reaches us from another user: if someone pairs with the browser extension on your computer, any pairing record saved under their account holds that extension's code and anonymous account identifier, and its browser name and operating system when the extension provides them.

Lawful basis for processing

We process personal data only where a lawful basis under Article 6(1) of the GDPR applies.

  • Running the free pairing service. Processing session, anonymous account and device motion data so the phone and extension can connect, and so the pairing screen remembers your settings, rests on our legitimate interest in providing a working presentation tool (Article 6(1)(f)).
  • Providing Clikr Pro and the Pro free trial. Processing account and payment data to deliver the Pro features you purchased or are trialing rests on performance of a contract (Article 6(1)(b)).
  • Offering Clikr Pro. Loading Paddle's checkout script, with the ProfitWell script it brings, when you choose to buy, which sends Paddle and ProfitWell your IP address, rests on our legitimate interest in offering Clikr Pro for sale with a working checkout (Article 6(1)(f)). Using the country our host works out from your IP address to show the Pro price in your local currency, which sends Paddle only that country code, rests on our legitimate interest in showing a price in your own currency (Article 6(1)(f)). Keeping the record of who a checkout belongs to for a checkout you do not complete, in case a payment for it reaches us later, and keeping your account's checkout record, which limits how many checkouts an account can open in a short time, rests on our legitimate interest in a checkout that works reliably and is protected from misuse (Article 6(1)(f)).
  • Automatic pairing. Processing the automatic pairing data described above, including the pairing records and pairing channel records, so that a phone can connect to a computer it has paired with before without scanning its QR code again, rests on our legitimate interest in offering automatic pairing (Article 6(1)(f)).
  • Service email. Sending you account, sign-in, and order confirmation messages rests on performance of a contract (Article 6(1)(b)).
  • Product update email. Sending you product update email, only if you asked for it, rests on your consent (Article 6(1)(a)). Keeping the record of your email preference, including a withdrawal, rests on our legitimate interest in being able to show what you chose and when (Article 6(1)(f)). Keeping your plan and Pro free trial status in your contact record at our email provider for every signed-in account, including one that did not ask for product update email, so that the right email follows if you ask for it later, rests on our legitimate interest in sending only the email that fits your account (Article 6(1)(f)).
  • Error monitoring and performance traces. Processing error and exception details, console warnings and errors, failed network request details, the deliberate diagnostic messages described above, and server-side performance traces (the route and timing of a request, produced for successful requests as well as failed ones) to keep the service secure, find faults, and fix them rests on our legitimate interest in a reliable and secure service (Article 6(1)(f)).
  • Session replay. The error-triggered session replay is part of our error monitoring, but because it stores information on your device it runs only with your consent (Article 6(1)(a)), given through the Performance category in our cookie banner. You can withdraw that consent at any time, which stops the replay.
  • Analytics. Processing page views, visitor counts and the custom product events described above, so we can see which features are used and whether pairing is working, rests on our legitimate interest in understanding and improving the service (Article 6(1)(f)).
  • Internal statistics and account lookups. Using the data described above to produce the internal statistics described under "What we collect", and looking up a single account's records to answer a question about it or look into a payment, refund or chargeback, rests on our legitimate interest in running and improving our business and supporting our customers (Article 6(1)(f)).
  • Account deletion. Keeping the deletion record and, for an account that started the free trial with a verified email address, the coded form of that address described under Retention, so that we can finish a deletion that was interrupted, recognise a late payment, refund or chargeback notification for the deleted account without applying it, answer questions about the deletion, and stop the same address from starting a second free trial, rests on our legitimate interest in completing deletions reliably, handling payments correctly and protecting the free trial from misuse (Article 6(1)(f)).
  • Legal compliance. Keeping payment records and responding to lawful requests rests on compliance with a legal obligation (Article 6(1)(c)).

Special category data

We do not intentionally collect special category data such as data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic or biometric data, health data, or data concerning a person's sex life or sexual orientation (Article 9 GDPR). Clikr has no free-text fields or content uploads that would invite it.

What travels between your devices

Pointer and gesture data is sent over a WebRTC connection between your phone and your computer. It does not pass through our servers. The Firebase Firestore signaling server is used only to set up that initial connection. It is not a channel for pointer movement.

Both your phone and the browser extension ask Metered, our relay provider, for connection credentials when they set up a pairing, so that a relay is available if one turns out to be needed. That request alone means Metered receives the public IP address of each device, including on pairings that then connect directly and never use a relay. A device that is still holding a recent set of credentials reuses them and makes no request. That covers only the credentials request. Separately, whenever a device has Metered's credentials to use, its browser also contacts Metered's relay servers directly. It does so while it prepares or sets up a pairing (on the extension's side, before your phone has even joined), again whenever the connection is re-established, and it can keep doing so at regular intervals for as long as the connection stays open. This happens whether the credentials are new or reused and whether or not the pairing then connects directly. So Metered receives the public IP address of each device even when neither device makes a credentials request, and can tell when a pairing starts and roughly how long it lasts.

The connection is direct between your two devices whenever your networks allow it. Where they do not, which is common on symmetric NAT, on mobile networks behind carrier-grade NAT, and on many corporate and hotel networks, the connection is relayed through Metered instead. The public IP address of each device reaches Metered in that case, along with the timing and volume of the traffic. Everything the connection carries stays encrypted between your phone and your computer for the whole journey, so the relay passes it on without being able to read it. We do not store it.

If usable connection credentials cannot be obtained, because the request fails, times out, comes back with nothing usable, or cannot be made at all, your devices fall back to a public Google STUN server. That server learns the public IP address of each device but cannot carry any traffic, so a pairing that needed a relay then fails rather than being routed anywhere else. Like Metered's relay servers, it is contacted while a pairing is prepared or set up and can keep being contacted at regular intervals while the connection stays open, so it can also tell when a pairing starts and roughly how long it lasts.

Some browser-extension features send a small amount of information read from the page you are presenting back to your phone over that same connection: the current slide's speaker notes, a low-resolution thumbnail of the next slide, your position in the deck (the slide number and the total), and whether a video on the page that has started is currently playing or paused (or an empty message meaning there is no video to control, which is also what is sent if you decline). Like pointer data, none of it passes through our servers, it is covered by the same encryption when the connection is relayed, and none of it is stored anywhere by us. These features are optional and are switched off unless you allow the extension to read page content. You can change that choice at any time from the extension.

Sub-processors and recipients

We share personal data with the recipients below, strictly for the purposes described in this policy. Each acts as our processor on our instructions, except Paddle, which is an independent controller for the buyer relationship and for the data its checkout script receives when you choose to buy.

  • Google Firebase (Google Ireland Limited). Provides Firebase Authentication, including the anonymous sign-in, and the Firestore database we use for signaling and user records, so it stores the session records described under "What we collect", including the IP addresses in their connection setup data, and the account identifiers, email addresses, user records, pairing records and pairing channel records described there, as well as the checkout records described under Payment data. See firebase.google.com/support/privacy.
  • Metered (The Next Path Software Consulting Inc., Canada). Provides the relay service that lets your phone and the browser extension reach each other when a direct connection is not possible. It receives the public IP address of both devices whenever they request connection credentials, which they do when setting up a pairing unless the device is still holding a recent set, and, separately, whenever the browser on either device contacts its relay servers while preparing, setting up or keeping open a pairing, which happens whether or not the pairing connects directly. That contact also lets it tell when a pairing starts and roughly how long it lasts. On a relayed pairing it also carries the connection itself, seeing the addresses, timing and volume of that traffic but not its content, which stays encrypted between your two devices. See metered.ca/privacy.
  • Paddle. Merchant of Record and an independent data controller for payment, billing, fraud prevention, and tax-compliance data it collects directly from you at checkout. The specific Paddle entity is the one shown in checkout and on your order confirmation. We also give Paddle your account identifier with each checkout, so the purchase can be matched to your account, and the email address on your account, to fill in the checkout form for you. Paddle handles card data under the PCI DSS standard; we never receive it. Paddle's checkout script loads from Paddle's servers only when you choose to buy: when you click a button to buy or upgrade to Pro, or open a checkout link from us or Paddle. Paddle then receives your IP address and the technical details any web request carries, such as your browser type, even if you close the checkout without buying. Paddle's script also loads a script from ProfitWell, a Paddle service, which receives your IP address and the same technical details. Paddle is an independent controller for this data too, and handles it under its own privacy notice. To show the Pro price in your local currency, our server asks Paddle for the price in the country our host works out from your IP address. The only information about you in that request is the country code; it never includes your IP address. See paddle.com/legal/privacy.
  • Vercel Inc. Hosts the web application, so it processes the technical data any web host handles, including the address and IP address of every request, and a coarse country it works out from that IP address, which our server uses to show the Pro price in your local currency. It also provides cookieless analytics, which receives the page views, visitor counts and custom product events described under "What we collect", along with context of its own such as the address of the page, with the pairing session identifier stripped out of it, and a coarse country worked out from the request IP address. See vercel.com/legal/privacy-policy.
  • Sentry (Functional Software, Inc.). Provides error monitoring and the error-triggered session replay described above. It processes error and exception data, console warnings and errors, failed network request details, the deliberate diagnostic messages described above, and the masked replay. Reports sent from your browser carry the address of the page they came from, with the pairing session identifier stripped out of it before sending. From our servers it also receives the address and HTTP method of a request, plus performance traces covering the route and how long it took. Those server-side reports and traces deliberately exclude request headers, request bodies, cookies, and IP addresses, though a logged fault can include your account identifier. Ingestion is handled through Sentry's European endpoint. See sentry.io/privacy.
  • Plunk. Our email provider. It sends the email described under "Email we send you", so it processes the content of each email it sends, including your email address, and it holds the contact record described there. It stores our email contacts in the European Union (Germany). See useplunk.com/privacy.
  • Amazon Web Services (Amazon SES), as Plunk's sub-processor. Delivers the email Plunk sends for us to your mail provider, so it processes your email address and the content of each email. See aws.amazon.com/privacy.

On the fallback path described under "What travels between your devices", a public Google STUN server also receives the public IP address of each device. It carries none of the traffic between your two devices. Because each device can keep contacting it at regular intervals while the connection stays open, it can also tell when a pairing starts and roughly how long it lasts, and it receives nothing else.

We may disclose personal data when we are legally required to do so, for example to comply with a court order, a regulatory request, or other legal process, or when disclosure is necessary to protect our rights or the safety of others. The basis for this is compliance with a legal obligation (Article 6(1)(c)) and our legitimate interests (Article 6(1)(f)). Where the law allows and it does not prejudice an investigation, we will tell you before we respond.

Business transitions

If we are involved in a merger, acquisition, financing, reorganization, bankruptcy, or sale of all or part of our assets, your personal data may pass to the acquiring party or successor entity as part of that transaction. We will require any successor to honor the commitments in this policy. For California residents, this kind of asset transfer is not a sale of personal information under the CCPA.

International transfers

Some of our recipients process data outside the European Economic Area, including in the United States and Canada. Where that happens, we rely on the safeguards in Chapter V of the GDPR. Where the European Commission has decided that a country outside the EEA offers an adequate level of protection, as it has for Canadian recipients subject to PIPEDA, we rely on that decision. For transfers to a US recipient that is certified under the EU-US Data Privacy Framework, we rely on that Framework, and for UK personal data on the UK Extension to it (the UK-US Data Bridge). For all other non-adequate transfers we rely on the European Commission's Standard Contractual Clauses (Decision (EU) 2021/914), and for UK personal data on the UK International Data Transfer Addendum. You can ask us which mechanism applies to a given recipient. Plunk stores our email contacts in the European Union (Germany). Amazon Web Services, which delivers the email Plunk sends for us, is a US company, and transfers to it rely on the mechanisms above.

Retention

Session records, including the session identifier, the sign-in identifiers and the connection setup data with the IP addresses it contains, are held by our signaling server with a fixed expiry set when the session starts, about 23 hours later, and are deleted automatically once that expiry passes; that automatic deletion usually completes within a further day. They are not deleted at the moment your session ends, and an abandoned pairing attempt is deleted the same way. Device motion data is never stored by us, on either the direct or the relayed path described above. The underlying analytics records are kept by Vercel under its own retention schedule, determined by the Web Analytics retention limit of the Vercel plan we are on rather than by us; ask us and we will tell you what that limit is at the time. We use them only in aggregate, and only for as long as they are useful for understanding how the service is used. We delete an anonymous account identifier, together with its user record and the device pairings stored under it, once it has gone 180 days without use. Use means that device signing in with the identifier or renewing its sign-in, which happens whenever Clikr is used on it while it keeps that identifier. The deletion runs once a day, so it usually happens within a day or two after the 180 days pass. Clearing that browser's site data or later signing in does not delete them sooner, but you can ask us to delete them earlier if we can tell which one is yours (see "Verifying requests and timing" below). The copy of the identifier in a session record is deleted with that record, as described above. A copy of an extension's identifier in a pairing record saved under a signed-in account is kept as long as that pairing record, as described below. Each time the extension prepares a pairing it overwrites the session identifier and time in its pairing channel record. We delete a pairing channel record once the extension's anonymous account identifier stored in it has gone unused for 180 days. The extension uses that identifier whenever it prepares a pairing, so this happens about 180 days after the extension is removed, stops being used, or moves to a new record, and you can ask us to delete a record sooner if we can tell which one is yours. A record last updated while the extension was paired with your account holds your account identifier as part of that session identifier, and keeps it until the extension updates that record again without being paired with your account, or until the record is deleted as above. Pairing records are kept until you remove them from the list of paired devices on the pairing screen, or until a later pairing with the same installation code replaces them. We set no other limit: they are kept, including after your Pro access ends or while that list is not shown to you, until you ask us to delete them or your account. Account data is kept while your account exists and is deleted on request. The checkout records described under Payment data are kept the same way: the record of who each checkout belongs to, including for checkouts you did not complete, and your account's checkout record are kept while your account exists and deleted with it on request. We keep the record of who a checkout belongs to after checkout closes because Paddle can tell us about a payment, refund or chargeback for that checkout long after you opened it, and we use that record to apply it to the right account. Diagnostic and error data, including server-side performance traces, is kept for as long as needed to investigate and fix faults and to keep the service secure, and longer where the law requires. Payment, order, and invoice records that Mawal AB holds are kept for seven years to meet Swedish accounting and tax obligations (Bokföringslagen 1999:1078). Paddle keeps its own records under its own privacy notice.

When your account is deleted, whether you delete it yourself or we delete it at your request, we keep a deletion record: your account identifier and the times the deletion was requested, started and finished. We use it to finish a deletion that was interrupted, to recognise a payment, refund or chargeback notification from Paddle that arrives for the deleted account without applying it, and to answer questions about the deletion. It is kept until 12 months after the deletion finishes. If the account had started the Pro free trial and its email address was verified, we also keep a coded form of that address, made with a secret key we keep outside the database so that the database alone does not reveal the address, together with the time it was made. We use it only to stop the same address from starting a second free trial, and keep it for 12 months. A browser extension that was paired with the deleted account keeps your account identifier in its own storage until you remove the extension or pair it with another account, and until then the pairing channel and session records it writes carry that identifier. Payment, order and invoice records held by Mawal AB and by Paddle are not affected by a deletion and are kept as described above.

Your contact record at Plunk, described under "Email we send you", is kept while your account exists and is deleted when your account is deleted. If Plunk cannot confirm that deletion at the time, our daily deletion job retries it, and your sign-in record, which holds your email address, is kept until the contact record is gone. Plunk keeps its own sending logs under its own terms and our agreement with it.

Your rights

Under the GDPR and the UK GDPR you have the right to access your personal data, to have it corrected, to have it erased, to restrict its processing, to receive a portable copy, to withdraw consent where processing is based on consent, and not to be subject to decisions based solely on automated processing that produce legal or similarly significant effects. You also have the right to lodge a complaint with a supervisory authority (see below). To exercise any of these rights, write to us at hello@clikr.app. Residents of Switzerland and of US states with comprehensive privacy laws have comparable rights, described where they differ in the sections below.

Where the account menu offers Download your data, you can also download a copy of the data we hold about your signed-in account yourself. It saves a file in JSON, a common machine-readable format, with your account details, your user record, your pairing records, your purchase and checkout records, the pairing sessions your account took part in, and the pairing channel and session records carrying your account identifier that belong to extensions in your list of paired devices. The file says how to ask us for anything it leaves out, and what Paddle and our error monitoring, analytics, and connection providers may hold about you. It does not include data kept under the anonymous identifier the pairing screen used before you signed in, which is not linked to your signed-in account (see Verifying requests and timing below).

Where Settings offers Delete account, you can also delete your signed-in account yourself, after confirming it is you by signing in again if you last signed in more than a few minutes ago. Deleting it removes your sign-in, your user record and settings, your pairing records, your checkout records, the pairing channel and session records your pairing records lead to, and the session records your account created. From a session your account joined, your account identifier and connection setup data are removed, and the rest of that session record is left to expire as described under Retention. Most of this happens at once and the rest within about a day. What a deletion keeps, and for how long, is described under Retention. You can still ask us by email to delete your data instead.

Your right to object

You have the right to object at any time to our processing of your personal data where that processing is based on our legitimate interests. This includes the processing of session, anonymous account, automatic pairing, motion, analytics, and error-monitoring data described above, keeping the record of who a checkout belongs to for checkouts you do not complete and your account's checkout record, and loading Paddle's checkout script when you choose to buy and using the country worked out from your IP address to show the Pro price in your local currency. It also includes using your data for the internal statistics and account lookups described under "What we collect", and keeping the deletion record and the coded email address described under Retention. It also includes keeping the record of your email preference described under "Email we send you". It also includes keeping your plan and Pro free trial status in your contact record at our email provider, described there too. If you object, we will stop that processing unless we can show compelling legitimate grounds that override your interests, rights, and freedoms, or unless we need the data to establish, exercise, or defend legal claims. To object, email us at hello@clikr.app.

Verifying requests and timing

To protect your data, we confirm your identity before acting on a rights request, normally by asking you to send it from the email address on your account or to provide information that matches it to our records. We do not use that information for anything else. An anonymous account has no name or email address attached, and outside automatic pairing its identifier is never shown to you, so we usually cannot tell which anonymous account is yours. Unless you can give us information that lets us identify it, we may be unable to act on a request about it (Articles 11(2) and 12(2) of the GDPR), and we will tell you so. When automatic pairing is used with a browser extension, that extension's anonymous account identifier can appear in the address of the pairing screen. A pairing record kept under a signed-in account, described under "What we collect", also connects the anonymous account of the extension it describes with that signed-in account. Under the GDPR and the UK GDPR we respond within one month, extendable by up to two further months for complex or numerous requests, and we will tell you within the first month if an extension is needed. For California residents we respond within 45 days, extendable by a further 45 days with notice to you.

US state privacy rights

If you live in a US state with a comprehensive privacy law (including California, Virginia, Colorado, Connecticut, Utah, Texas, Oregon, Montana, Iowa, Delaware, New Jersey, Tennessee, Minnesota, Maryland, and other states whose laws come into force from time to time), you may have the right to know what personal information we hold about you, to delete it, to correct it, to receive a portable copy, to opt out of the sale or sharing of personal information and of targeted advertising, and to appeal a decision we make about a request. Mawal AB does not meet the statutory thresholds that would make the CCPA or similar laws mandatory for us, so we extend these rights voluntarily to residents of those states. To exercise them, email us at hello@clikr.app. You may use an authorized agent; we will still need to verify your identity and the agent's authority.

We do not sell your personal information and we do not share it for cross-context behavioral advertising as those terms are defined under the CCPA. We run no advertising or marketing pixels and operate no financial incentive program, and we will not discriminate against you for exercising any privacy right. Because there is no sale or sharing to opt out of, there is no opt-out signal for us to act on. If we ever change that, we will treat a valid Global Privacy Control (GPC) signal from your browser as a request to opt out of any sale or sharing.

Children

Clikr is a general-audience tool and is not directed to children. Under the GDPR (Article 8) the digital-consent age is 16 by default, and EU and EEA member states may lower it to no less than 13. In Sweden, where we are established, it is 13. Other countries may set a different age. We do not knowingly collect personal data from children below the applicable age. If you are a parent or guardian and believe a child has given us personal data, contact us and we will delete it promptly.

Automated decisions

We do not make decisions about you based solely on automated processing that produce legal or similarly significant effects. Clikr has no artificial intelligence or machine learning features, and your Pro free trial simply stops at the end of its 14-day period with no automatic charge and no automated profiling.

Email we send you

We send service email: account and sign-in messages and order confirmations. These are necessary to provide the service and rest on performance of a contract (Article 6(1)(b)), so they are not marketing messages and have no opt-out.

Service email includes a welcome email, usually right after you create a signed-in account, the email verification and password-reset messages, and, when you ask to reset the password of an account that signs in with Google, an email saying so. We send these through Plunk, our email provider. When that is not possible, Firebase Authentication (Google) sends the verification or password-reset email instead.

We also send product update email: occasional tips and product news about Clikr, covering new features and notable changes to the service. You get it only if you ask for it, by ticking the email updates box when you sign up or by turning on the email preference in your account settings. Anonymous accounts have no email address and never receive it. Although this kind of email is informational rather than promotional, we treat it as marketing, and sending it rests on your consent (Article 6(1)(a)). We send it only to an email address that has been verified, for example through the link in our verification email or by signing in with Google, which verifies the address. We do not send marketing SMS or push notifications.

Product update email includes tips for getting started, about two days after you sign up, and, if you start the Pro free trial and have not bought Pro, a reminder about three days before the trial ends and a request for feedback once it has ended, as well as occasional product news. We send it through Plunk, only to a verified address that asked for it.

Plunk holds a contact record for your signed-in account, including an account created before we started using Plunk. It holds your email address; whether you may receive product update email (subscribed or unsubscribed); whether your address is verified; your plan (free or Pro) and, if you started the Pro free trial, when it ends; when we last sent you a verification or password-reset email, or an email saying that your account signs in with Google; and notes of events such as signing up, starting the Pro free trial, buying Pro or having a purchase refunded. A verification or password-reset email carries its link to Plunk with the email, and we remove the link from your contact record after sending the email. Plunk holds your plan and Pro free trial status for every signed-in account, including one that did not ask for product update email, so that the right email follows if you ask for it later. That rests on our legitimate interest in sending only the email that fits your account (Article 6(1)(f)). The contact record is kept and deleted as described under Retention.

You can withdraw your consent at any time: turn off the email preference in your account settings, use the unsubscribe link in every product update email, or email us at hello@clikr.app. Withdrawing does not affect processing that took place before it, and it never affects the service email above, which is part of the service itself. When you turn product update email on or off, we store your choice with the time you made it, where you made it, such as the sign-up form or your account settings, and the version of the wording you were shown; a later change replaces the earlier one. We keep that record, including a withdrawal, to be able to show what you chose and when, which rests on our legitimate interest (Article 6(1)(f)). It is kept as long as your account exists and is deleted with your account.

Every product update email has an unsubscribe link and one-click unsubscribe headers, and Plunk records an unsubscribe made from an email.

For every email Plunk sends for us, service and product update email alike, neither we nor Plunk track whether you open it or click its links.

Cookies

Our use of cookies and similar technologies, the categories we use, and how to give or withdraw consent are described in our separate Cookie Policy.

Security

We protect personal data with measures appropriate to the risk: encryption in transit, access controls on our systems, vendor due diligence, and data processing agreements with our processors. The peer-to-peer design means pointer data is never collected on our servers in the first place. No online service can be perfectly secure, but we work to keep the risk low.

Data breach notification

If a personal data breach occurs, we will notify the competent supervisory authority without undue delay and, where feasible, within 72 hours, as required by Article 33 of the GDPR. Where a breach is likely to result in a high risk to your rights and freedoms, we will also inform you without undue delay under Article 34, and we will meet any applicable US state breach notification requirements.

Complaints and supervisory authorities

You have the right to lodge a complaint with a data protection supervisory authority. Our lead supervisory authority in the EU is the Swedish Authority for Privacy Protection (Integritetsskyddsmyndigheten, IMY), at imy.se. EU and EEA residents may also complain to the authority in their own country, which you can find through the European Data Protection Board's directory at edpb.europa.eu. If you are in Switzerland, you can complain to the Federal Data Protection and Information Commissioner (FDPIC) at edoeb.admin.ch. If you are in the United Kingdom, you can complain to the Information Commissioner's Office at ico.org.uk. California residents can also contact the California Privacy Protection Agency or the California Attorney General. In any other country, please contact your local data protection authority.

Changes to this policy

We may update this policy as Clikr evolves. The "Last updated" date at the top reflects the most recent change. If a change is material, we will tell you by email or with a prominent notice on the site before it takes effect.

Contact us

For any privacy question, or to exercise a right described above, contact Mawal AB at hello@clikr.app or by post at Hallandsgatan 38, 118 57 Stockholm, Sweden.