Privacy & Compliance Guide

Last updated August 6, 2026

A practical guide for deploying the Rebase widget lawfully. Rebase is designed for staging and QA environments first; when you capture data from real users — especially in production — you are the controller and Rebase is the processor, and this page explains the responsibilities that sit with you and the controls we give you to meet them.

This guide is informational, not legal advice. For the contractual terms governing our processing, see the Data Processing Addendum and Privacy Policy.

1. Who is responsible for what

When you embed the widget, you decide what is collected and why, so you are the controller of the personal data in the feedback your end-users submit. Rebase processes that data on your documented instructions as the processor. The obligations below — lawful basis, consent, transparency, and responding to data-subject requests — are the controller’s to meet; our job is to give you the technical controls to do so.

2. Start in staging

Rebase is built as a staging-first product: install it in your QA, staging, or preview environments to catch bugs before they ship. That is where it earns its keep — and non-production environments rarely process real end-user personal data, which keeps your compliance surface small. Production use is fully supported when you want feedback from real users; the rest of this guide walks through the responsibilities that come with it.

3. Establish a lawful basis

Capturing end-user data on your site needs a lawful basis under Article 6. The two that typically apply:

• Consent (Art. 6(1)(a)): the cleanest basis where the widget may capture identifiable end-user content. Gate the widget behind your consent flow (see §4).
• Legitimate interests (Art. 6(1)(f)): may apply for internal bug diagnostics, but requires a documented balancing test and clear notice. Don’t rely on it for special-category data.

Update your own privacy notice to name Rebase as a processor and link your users to it. The widget is cookieless (see our Cookie Policy), so embedding it does not by itself add tracking cookies that would trigger ePrivacy consent — but the data you capture still needs a lawful basis.

4. Gate the widget behind your consent flow

If you rely on consent, load Rebase only after the user has consented. The loader script controls when capture begins, so the simplest pattern is to inject (or enable) the script from your consent manager’s “accepted” callback rather than on every page load. Where you must load it earlier, configure aggressive masking (below) so nothing identifiable is buffered before consent.

5. Configure masking

Rebase hard-blocks the sensitive field types outright and lets you tighten or relax everything else per element. Capture happens behind explicit user action (the “report” button), and hard-blocked values are masked at the point of observation — never buffered in the clear.

• Password, payment, OTP, hidden, and telephone fields are hard-blocked — their values are never capturable, and no configuration can re-enable them.
• Ordinary input values are captured. Values in other <input>, <textarea>, and contenteditable fields are recorded so the repro trail can show what was entered (Typed “SAVE20 ” in “Discount code” — the trailing space is often the bug). They leave the page only inside a report someone deliberately submits: the stored session tail and automatic error captures always re-mask them, and every captured value is swept for token and secret patterns.
• To mask every field instead, set privacy.maskAllInputs: true in the widget configuration. Values are then captured as their shape (length as ••••), not their value. Consider this for production deployments that capture from real end-users.
• data-rebase-block — the element is dropped from capture entirely (absent from the screenshot, serialized HTML, and interaction trail). Use it for any region that may render PII.
• data-rebase-mask — keep the element’s shape but mask its value/text.
• data-rebase-unmask — opt a specific subtree back into capture when you’ve enabled aggressive masking. (Hard-blocked fields are never re-enabled.)
• Existing privacy markers are honored. If you already mark sensitive elements for Hotjar, FullStory, Sentry, PostHog, or LogRocket (data-hj-suppress, fs-mask/fs-exclude, data-sentry-mask/data-sentry-block, ph-no-capture, data-private), Rebase respects them as mask/block on day one. (We deliberately do not honor third-party unmask markers — only your own data-rebase-unmask.)

Network capture defaults to metadata only (method, path, status, timing — query strings stripped, credential headers redacted); request/response bodies are off unless you opt in per origin. Console capture is limited to errors and warnings, with secrets and URLs scrubbed.

6. Avoid special-category data

Rebase is not intended to process special-category data (health, biometrics, and so on). Where pages may render it, block those regions with data-rebase-block and confirm your lawful basis and any Article 9 condition before enabling capture there.

7. Defense in depth

Beyond the in-page masking you configure, Rebase scrubs again on our servers before anything is stored: URLs, secret patterns (tokens, keys, bearer credentials), emails, and card-like numbers are redacted from captured markup, console output, network bodies, and the interaction trail. Content sent to our AI triage model is minimized and fenced as untrusted data. This is a safety net, not a substitute for configuring masking on your side.

8. Retention & erasure

Screenshots are retained for up to 90 days depending on your plan and served only via short-lived signed URLs. To honor an end-user’s erasure request, deleting the ticket removes its associated diagnostic context and screenshot; reach out if you need help locating tickets for a specific data subject. See the DPA for deletion and return on termination.

9. Data-subject requests

As the controller, you handle access, correction, and erasure requests from your end-users. Rebase assists by appropriate technical measures — see §8 of the DPA. If a data subject contacts us directly, we refer them to you.

10. Contact

Questions about deploying Rebase compliantly, or to request a countersigned DPA? Email [email protected].