Privacy & Compliance Guide

Last updated June 17, 2026

A practical guide for deploying the Rebase widget on your production site in line with the GDPR and similar laws. Rebase is the processor; you are the controller — 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. 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 §3).
  • 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.

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

4. Configure masking

Rebase masks by default and lets you tighten or relax per element. Capture happens behind explicit user action (the “report” button), and sensitive values are masked at the point of observation — never buffered in the clear.

  • Inputs are masked by default. Every <input>, <textarea>, and contenteditable value is captured as its shape (length as ••••), not its value.
  • Password, payment, OTP, hidden, and telephone fields are hard-blocked — their values are never capturable, and no configuration can re-enable them.
  • 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.

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

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

7. Retention & erasure

Screenshots are retained for 90 days by default 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.

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

9. Contact

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