Cookie & Tracker Notice

Version 3.4 · effective 2026-10-29 · in force

The short version: no consent banner

RunMyB does not set analytics, advertising, or cross-site tracking cookies. The cookies it does set — described exhaustively below — are the strictly-necessary sign-in and access cookies, plus one functional preference cookie (your workspace selection). Hosted product pages include a small cookieless first-party audience beacon that reports page views to the platform's own same-site endpoint; it stores nothing on your device — no cookies, no local storage — and what it processes is stated precisely below and in the Privacy Policy, Section 4, including the per-product switch that turns it off. A hosted product marked as a demo also shows RunMyB's demo notice, and once you acknowledge that notice one item is kept in your browser's local storage for that product's site: the record of a choice you made by your own action, described below. Under the ePrivacy rule (Art. 5(3)), consent is required to store or read information on your device that is not strictly necessary; what the platform stores is the exempt strictly-necessary and user-requested-preference kind; the name of the time zone your browser reports, which the console reads from your device (described below), is of the strictly-necessary kind; and the platform's audience measurement operates under the commitments stated below. So there is no cookie consent banner.

What we do use

A strictly-necessary console session cookie that keeps you signed in to the console. It is essential to provide the service you asked for, carries no tracking value, and is exempt from consent.
On the hosted console, the sign-in session cookies set by the platform's load balancer, which keep you signed in at the edge. They serve the same strictly-necessary authentication purpose and nothing else.
A workspace-selection preference cookie ("runmyb_working_tenant"): when you belong to more than one workspace and pick the one you are working in, the console remembers your choice in this cookie (HttpOnly, SameSite=Lax, kept for 30 days). It stores only the identifier of the workspace you selected — a preference you set by your own action, read for no other purpose.
On runmyb.com, a colour-scheme preference in your browser's local storage ("runmyb-theme"): only if you press the light/dark switch, the site keeps your choice — the single word "light" or "dark" — so every page shows the mode you picked. It is never sent to us or anyone else, and stays until you switch back to the mode your device already uses (then it is removed) or clear your browser's site data. It is a preference you set by your own action, read for no other purpose.
On hosted product preview domains, a preview access cookie ("__Host-rmb_preview", HttpOnly, Secure, SameSite=Lax): when you open a product preview through an access link, the short-lived access credential from the link is moved into this cookie so the preview keeps working as you navigate, for the remaining life of that credential. It is an access key, not a tracker, and it is stripped before any request reaches the product's own code.
On hosted product pages, the cookieless first-party audience beacon: it runs in the page context of the product page and reports page views — the initial load and subsequent in-app navigations — to the platform's own same-site collection endpoint, sending the visited page's address and the referring page. Its records keep information about the page and the referring site, the time of the visit and, in place of the visitor's network address and browser, a pseudonymous visitor identifier that changes every day; they are kept for up to 30 days and counted into statistics that identify no visitor (Privacy Policy, Section 4).
On the public address of a hosted product marked as a demo — its runmyb.app address or its owner's own domain (Terms of Service & Acceptable Use, Section 15) — the acknowledgement of RunMyB's demo notice, kept in your browser's local storage for that product's site ("rmb-demo-ack"). Such a product shows RunMyB's demo banner on its pages and, on your first visit, a notice in RunMyB's words; only when you press "I understand" on that notice does the platform's script keep a note that you did: the notice's version and, if the notice names one, its specialist field (legal, financial, health or safety), and nothing that identifies you. The note lets the notice be shown once rather than on every page. RunMyB's script never sends it anywhere and reads nothing else from your device beyond the page it runs in. It stays until you clear the site's data in your browser; if the notice changes, it is shown again, and if your browser does not let the site keep the note, the notice is shown again on the next page. Because the note is kept for the product's own site, the product's own code can read it too, as it can anything kept there. It records a choice you make by your own action, read for no other purpose than not asking you again: the same user-requested kind as the colour-scheme preference above.
In the console, the time zone your browser reports: with each message you send in a conversation, the console's own script reads the name of your browser's time zone — such as Europe/Warsaw — and sends it to the platform, so that the times of a product you ask for follow your own time zone (Privacy Policy, Section 2). This read takes only that name and stores nothing on your device, and the name is used only as the Privacy Policy's Section 2 states; a product in your own time zone is an intrinsic and expected part of the service you ask for, so this read is of the strictly-necessary kind and is exempt from consent.
The request itself, which any web server receives. The platform's load balancer keeps a record of each request to the console and to the hosted products — including the visitor's network address, browser information and the address requested — for up to 30 days, for the platform's security and operation and for its statistics (Privacy Policy, Section 4).

Where the console runs without sign-in, no cookie is set at all.

The visitor identifier, stated in this notice and not only in the Privacy Policy. To count unique visitors, the collection endpoint derives a pseudonymous identifier server-side from the visitor's network address and browser information and the product's address, with a key that changes every day, and the beacon's record keeps the identifier, not those values. The identifier is different on every product and every day, and RunMyB does not use it to recognise a visitor across days or across products. This mechanism uses signals every web server already receives and stores nothing on your device; it does not build a device profile, and that — not a bare assertion — is why we say the beacon does no fingerprinting.

The commitments the no-banner posture rests on, as our own obligations rather than a citation: the beacon stores nothing on your device and reads nothing from it beyond the page context it runs in; its statistics are aggregates that identify no visitor; it does no cross-site tracking; its output is not consolidated with other data about you; its records are kept for a bounded period (Privacy Policy, Section 4); and every hosted product has a per-product opt-out that turns the beacon off entirely. The French CNIL's guidance on strictly-aggregate first-party audience measurement supports this posture; the commitments above are ours and stand on their own. The 2.0 edition of this notice promised that introducing any tracker would be preceded by an update to this notice; the 3.0 update was that promised update for the audience beacon, published before the beacon served. If we ever introduce a tracker that requires consent, that change re-triggers a consent requirement and this notice will again be updated first.

Changes

This notice is published, dated, and versioned. It does not require your acceptance; it is informational.

Version history (the document's changelog)

1.0 — initial draft edition. 2.0 — final edition: names the strictly-necessary cookies actually set (the console session cookie; the hosted edge's sign-in session cookies); final register (0529/E5). 3.0 — names the cookieless first-party audience beacon in hosted product pages and narrows the former blanket we-read-nothing claim honestly (the beacon reads the page context it runs in — the visited page's address and the referring page — and still sets no cookies and uses no storage); this update itself fulfils the update-this-notice-first promise recorded in 2.0 (0537). 3.1 — completeness and candour corrections (effective on posting): two cookies the platform sets are now named — the console's workspace-selection preference cookie and the hosted-preview access cookie on product domains — and the opening no longer claims the set is sign-in cookies only; the beacon's hash inputs are now named in this notice (network address and browser signature), matching the Privacy Policy; what the beacon reports (page views including in-app navigations) and what is kept server-side (host, referrer host, day-scoped visitor hash — the path is dropped) are stated precisely; the no-banner conditions are stated as our own commitments with the CNIL guidance as supporting context; the no-fingerprinting claim restated in its reasoned form. 3.2 — corrections (effective on posting, 2026-10-16; the Privacy Policy's edition 6.2 makes the matching correction of its Section 4): the notice said that the platform keeps aggregate counts only, that the request itself is transient transmission data, that the network address and browser signature behind the visitor hash are never logged and never stored, that the daily salt makes the hash unlinkable across days, and that retention holds no raw identifiers. That was inaccurate from 3.0 on: the platform's load balancer keeps a record of each request, with the visitor's network address, browser identifier and the address requested, for 30 days, and the beacon keeps a record of each page view, with its time, the page's host, the referring host and the daily visitor identifier, for 7 days, under a key the platform holds. The notice now states, by category and with a maximum period of up to 30 days, what the beacon's and the load balancer's records keep and why; that the identifier differs per product and per day and is not used to recognise a visitor across days or across products; and that the no-banner posture rests on the beacon storing nothing on the device and being the platform's own first-party audience measurement. It also names the runmyb.com colour-scheme preference kept in local storage; the exemption sentence covers stored items, not only cookies. The earlier entries are left as written; this entry is the record that their statements on retention were wrong. 3.3 — a disclosure (effective on posting, 2026-10-19, published with the Terms of Service & Acceptable Use's edition 6.0, whose Section 15 describes demo notices, and the Privacy Policy's edition 6.6; posted before any hosted product is marked as a demo): names a new item the platform keeps on a visitor's device — on the public address of a hosted product marked as a demo, the acknowledgement of RunMyB's demo notice in the browser's local storage for that product's site (rmb-demo-ack), kept only when the visitor presses the notice's I understand button, holding the notice's version and, if it names one, its specialist field, and nothing that identifies the visitor; RunMyB's script never sends it anywhere and reads nothing else from the device beyond the page it runs in; it stays until the visitor clears the site's data, and the notice is shown again if it changes or if the browser does not let the site keep the note; the product's own code can read it, as it can anything kept for its site; it records a choice the visitor makes by their own action, read for no other purpose than not asking again, of the same user-requested kind as the colour-scheme preference, so it is exempt from consent and no consent banner is added. The short version now says that a product marked as a demo keeps this one item once the visitor acknowledges its notice; the audience beacon still stores nothing on the device. 3.4 — a disclosure (effective on posting, 2026-10-29, published with the Privacy Policy's edition 7.2): names a read the console's own script makes from your device — the name of the time zone your browser reports, such as Europe/Warsaw, read and sent to the platform with each message you send in a conversation, so that the times of a product you ask for follow your own time zone (Privacy Policy, Section 2); the read takes only that name and stores nothing on your device, and the name is used only as the Privacy Policy's Section 2 states; a product in your own time zone being an intrinsic and expected part of the service you ask for, the read is of the strictly-necessary kind, exempt from consent, so no consent banner is added. The short version now names that read beside what the platform stores.