A practical guide for deploying the Rebase widget lawfully. When you capture data from real people on your website, you are the controller and Rebase is the processor. 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 reports and packets your end-users send. 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. Live and test websites

Rebase is built for the websites your customers use, where reports and packets come from real people. It also works on test, staging and local websites, which rarely hold real personal data and so keep your compliance surface small. On a live website, the rest of this guide walks through the responsibilities that come with it, including deciding whether Replay needs your visitors' consent.

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 sets no cookies (see our Cookie Policy). It does use your site's own browser storage: session storage for a short, scrubbed reload tail and a correlation id, local storage for small settings markers, and IndexedDB for saved packet history, which is on by default for each website and can be turned off per website. ePrivacy rules cover access to device storage generally, not only cookies, so include this storage in your own assessment. The data you capture also needs a lawful basis.

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.

Typed values are always masked in reports. Values typed into other <input>, <select>, <textarea>, and contenteditable fields appear in a report's actions only as dots (••••), never as the value. Screenshots mask these fields by default too.

To show ordinary field values in screenshots, mark individual fields with data-rebase-unmask, or set data-privacy='{"maskAllInputs":false}' on the installation script. Typed values in a report's actions stay masked either way, hard-blocked fields are never shown, and every captured value is swept for token and secret patterns.

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: method, path, status and timing, with query strings stripped and credential headers redacted. Request bodies are off unless you add data-capture-bodies="true" to the installation script. The body of a failed response is captured, scrubbed and shortened so the report shows the error. 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, replays and captured details (the timeline, console and network entries, the selected element, and device and customer context) are kept for your plan’s evidence history: 30 days on Starter, 90 on Growth and 180 on Scale. Replays are kept for at most 30 days on every plan. After that they are deleted. What the report says stays until you delete the report: its title, description, status, page address, environment, release, AI-suggested title and follow-up question (for a packet, its description, support reference and Slack context). Rebase shows screenshots and replays only to signed-in members of your workspace, and the issues it creates in a tracker you connect include the screenshot and captured details. To honor an end-user’s erasure request, an Owner or Admin can delete the report or packet from its page in Rebase: it is removed from Rebase with its captured details, screenshot and replay, and copies in database backups expire within 60 days. Issues already sent to your tracker stay there, so delete those in the tracker too. Reach out if you need help locating reports 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 support@rebase.dev.

Privacy & compliance guide.