Frequently Asked Questions

Not yet. LaBrowser currently supports macOS 12+ and Windows 10/11. Linux support is on the roadmap.

Yes. LaBrowser only captures activity within its own window. Anything participants do in Chrome, Safari, or other browsers is completely invisible to the study. This is the core privacy boundary.

Events continue to be captured and stored locally on the participant's computer. When the connection returns, queued events are uploaded automatically. If the interruption is longer-lived, the next launch can resume recovery, and researchers can recover the session from the session page if needed.

It depends on activity level. A 30-minute browsing session with moderate activity typically produces 200-500 events (roughly 50-200 KB of JSON). Screenshots and DOM snapshots are significantly larger.

The default capture rules use CSS selectors that explicitly exclude password fields (input[type='password']). However, if you write a custom capture rule with a selector that matches password inputs, they would be captured. Always review your capture rules carefully.

Yes. Configure the recruitment section of your study to capture platform-specific participant IDs from the join URL. For Prolific, set participant_id_param to "PROLIFIC_PID". The join link can include any URL parameters your platform passes.

Parsers process session events to produce derived data. You can trigger parsing from the Study Console on any session. Results replace previous parser output for that session if re-run.

The participant should return to the join link, download the latest LaBrowser build from that page, and launch again.

Contact the LaBrowser team if you need parser support beyond the built-in analysis tools. The right next step depends on the kind of structured output you need for your study.

Site augmentation makes controlled, declarative changes to the live pages participants visit — hiding or removing elements selected by CSS selector and scoped to a URL pattern. Capture rules observe and record what participants do; augmentation changes what they see. The two are independent: augmentation never records anything on its own, and capture never modifies the page. See Site Augmentation for the full reference.

No. Augmentation is operator-only and strictly declarative: a study config can describe ordinary hide and remove actions and nothing else. There is no mechanism to inject scripts, load remote code, or upload custom plugins. This is the core safety boundary that keeps every change reviewable and reproducible.

Every augmentation action with audit enabled (the default) emits a SITE_AUGMENTATION_AUDIT event for each outcome — applied, skipped, failed, or cleaned up — recording the plugin, action, matched count, and element fingerprints. These events are stored in the session event database alongside everything else. Keep audit on so you retain that evidence trail. See Audit Events.

No. The console ships built-in, versioned templates — such as a generic recommendation-shelf suppression template — that give you a starting point you customize (URL pattern, selector, reason, match limit). When you apply one, you choose an apply mode: add as a new plugin, merge into an existing plugin, or replace matching actions. See Templates.

Data in transit uses HTTPS (TLS). Study data stored by LaBrowser is protected on the hosted service. Local session data on participant machines is not encrypted, and it can remain on the device temporarily for recovery and export workflows, so treat the participant machine as a place where study data may temporarily persist.