Cookie & Tracker Notice
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. Under the ePrivacy rule (Art. 5(3)), consent is required to store or read information on your device that is not strictly necessary; the platform's stored cookies are the exempt strictly-necessary and user-requested-preference kind, and its 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 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. What is kept server-side is less than what is sent: the page's host (the path is dropped), the referrer's host, and a day-scoped visitor hash; the platform keeps aggregate counts only.
- Standard, transient transmission data (the request itself) that any web server sees.
Where the console runs without sign-in, no cookie is set at all.
The visitor hash, stated in this notice and not only in the Privacy Policy. To count unique visitors without retaining identity, the collection endpoint derives a keyed hash server-side from the visitor's network address and browser signature, salted with a value that changes daily, and discards the raw values immediately — they are never logged and never stored. The daily salt makes the hash unlinkable across days. This mechanism uses signals every web server already receives, holds them only inside a single request, and reduces them to a day-scoped counter input; 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 produces aggregates only; it does no cross-site tracking; its output is not consolidated with other data about you; retention is bounded (aggregate counts, no raw identifiers); 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.