---
title: 'PrivWeb: In-Browser Privacy for Web Agents'
url: https://www.emergentmind.com/topics/privweb
type: topic
---

# PrivWeb: In-Browser Privacy for Web Agents

PrivWeb is an in-browser privacy-protection layer for LLM-driven web agents that is deployed as a trusted browser add-on, or “system service,” to mediate every interface query from a web agent. It was designed in response to the observation that web agents require interface access and therefore introduce privacy risks that are understudied, particularly from users’ perspective. In a formative study with \(N=15\), users frequently misunderstood agents’ data practices and desired unobtrusive, transparent data management. PrivWeb addresses this setting through a localized LLM that anonymizes private information on interfaces according to user preferences, a privacy categorization schema, and adaptive notifications that selectively pause tasks for user control over information collection for highly sensitive information while offering non-disruptive options for less sensitive information [2509.11939].

## 1. Deployment context and privacy model

PrivWeb is situated in the operational environment of web agents that automate interactions across ordinary websites. Its design assumption is that the agent must access page content, but that access should be mediated rather than granted directly. The system therefore functions as a trusted add-on on web agents, enforcing what the paper describes as “privacy by default”: no sensitive content leaves the client without user consent [2509.11939].

The system’s privacy model is content-aware and preference-dependent rather than globally uniform. It does not treat all private information as equally sensitive. Instead, it uses a privacy categorization schema and a thresholded control policy so that some categories trigger explicit intervention, whereas others are anonymized and merely surfaced through lightweight notification. This design is intended to minimize human oversight while preserving user control over highly sensitive disclosures.

A central implication of this formulation is that privacy protection is embedded into the web-agent interaction loop itself. PrivWeb does not merely audit agent behavior after the fact; it mediates each request for page content and returns a sanitized representation to the agent. This makes the browser the enforcement point for privacy policy.

## 2. Core architecture and request mediation

PrivWeb has four core components: the Browser Add-On, the Localized LLM, the User Preference Manager, and the Task Controller [2509.11939].

The Browser Add-On hooks into the user’s browser via a standard automation API such as Playwright or WebExtensions. It intercepts agent requests for page content, including the DOM tree or screenshots. The Localized LLM is a small on-device model, implemented as Qwen3-8b via Ollama, that classifies and tags detected text elements with privacy categories. It receives batches of extracted element IDs and text and returns structured labels.

The User Preference Manager stores the user’s sensitivity thresholds and per-category “privacy by default” settings. It defines which categories are “highly sensitive,” requiring explicit approval, versus “lower sensitivity,” which are only highlighted. The Task Controller then orchestrates the agent’s execution. It pauses the agent’s action queue whenever “high-sensitivity” elements are about to be sent; otherwise it allows the agent to proceed after unobtrusive annotation. It also updates an in-situ side panel, the “Activity Log,” showing which elements have been redacted or allowed.

The data flow is specified in six steps. First, the agent calls the Browser Add-On for page content and gets the raw DOM tree \(D\). Second, the add-on extracts all text-bearing elements \(E=\{e_1 \ldots e_n\}\), assigning each a unique ID \(u_i\) and text \(t_i\). Third, the Localized LLM performs a classification step with input \(\{(u_i,t_i)\}\) and output \(\{(u_i,c_i)\}\), where \(c_i \in \{\text{financial}, \text{ID}, \text{name}, \ldots\}\). Fourth, the Preference Manager maps each \(c_i\) to a sensitivity score \(s_i \in \{1,2,3\}\). Fifth, the Task Controller redacts or annotates: if \(s_i \ge 3\), the agent is paused and a modal “Allow/Deny” prompt is shown; if \(1 \le s_i < 3\), the element is silently anonymized and highlighted briefly, and the task proceeds. Sixth, the sanitized DOM \(D'\) is sent back to the web agent.

The paper formalizes the redaction rule as
\[
D' \;=\;\bigl\{e\in D \mid s(e)<T_{\text{block}}\bigr\}\;\cup\;\bigl\{A(e)\mid s(e)\ge T_{\text{block}}\bigr\},
\]
where \(A(e)\) is the anonymization, by deletion or replacement by a placeholder, and \(T_{\text{block}}=3\) [2509.11939].

## 3. Sensitivity schema and anonymization policy

PrivWeb uses a three-level sensitivity ranking \(s \in \{1,2,3\}\) together with a two-tiered notification and control policy [2509.11939].

At \(s=3\), designated “highly sensitive,” the schema includes financial info, identity documents (ID), online identities, and email addresses. These categories trigger explicit “Allow/Deny” control and therefore block the agent pending user input. At \(s=2\), designated “moderately sensitive,” the schema includes personal name, postal address, phone number, and demographic and health attributes. These elements receive unobtrusive highlight and side-panel listing. At \(s=1\), designated “low sensitivity,” the schema includes affiliation, educational record, timestamps, and geo-location; these are handled similarly to \(s=2\), but with lower visual priority.

The control rule is stated as
\[
\text{Action}(e)=
\begin{cases}
\text{Pause + prompt}, & s(e)\ge 3,\\
\text{Anonymize + highlight}, & s(e)\in\{1,2\}.
\end{cases}
\]
This policy is operationalized through two thresholds: \(T_{\text{block}}=3\) and \(T_{\text{notif}}=1\). When the decision function returns \(\text{Block\_and\_Prompt}\), the Task Controller suspends the agent’s action queue and injects a modal “Allow/Deny” with context, such as “Agent wants to use your bank account number.” When it returns \(\text{Silent\_Highlight}\), a 3-second inline bounding box plus side-panel entry appear and execution continues.

The anonymization pipeline is DOM-centric. The add-on parses the DOM, collects all tags with text, including div, span, input, textarea, and related elements, and builds the list \(\{(u_i,t_i)\}\). The LLM is invoked once per page with a system prompt framing “identify PII in this list and output JSON of \{id, class\} pairs.” The redaction algorithm then either pauses the relevant element or applies \(A(D[u_i])\), that is, deletion or masking. The paper explicitly states that no formal differential-privacy guarantee is claimed; anonymization is by omission or placeholder replacement.

## 4. Localized LLM integration and technical performance

The implementation uses Qwen3-8b hosted locally via Ollama with default parameters [2509.11939]. The paper also reports alternative tested models: GPT-4o, Qwen3-4b, and DeepSeek-7b. On the reported technical evaluation dataset of 2,041 steps over 107 sessions containing 2,189 unique PII instances, Qwen3-8b achieved 75.4% overall accuracy and 100% on address, geo-location, demographic, and health.

The model comparison reported in the paper includes GPT-4o at 82.1% average accuracy, Qwen3-4b at 58.9%, and DeepSeek-7b. For latency per DOM page, DeepSeek-7b is reported at 8.52 s, Qwen3-8b at 6.42 s, Qwen3-4b at 4.05 s, and Qwen3-1.7b at 2.86 s. The paper characterizes these latencies as acceptable in user testing.

These figures define the system’s technical trade space. PrivWeb prioritizes on-device processing and client-side retention of sensitive content over minimum inference latency. A plausible implication is that the design is oriented toward trust and data locality rather than high-throughput realtime interaction. The paper’s stated privacy guarantee remains “Privacy by default”—no sensitive content leaves the client without user consent.

## 5. User study design and empirical findings

The user study enrolled \(N=14\) participants, with 8 M and 6 F, mean age \(=23.2\), \(SD=2.6\), and mixed CS/non-CS backgrounds [2509.11939]. It used a within-subjects design in which each participant performed six web tasks under three conditions: PrivWeb, defined as notification plus control; n/c, defined as notification only and no control for private information access; and n/b, defined as baseline with no notification or control. The tasks were drawn from the Mind2Web benchmark and spanned travel booking, shopping, information retrieval, entertainment, and related scenarios.

The measurement suite comprised 7-point Likert instruments for Cognitive Load, using NASA-TLX dimensions of Mental, Physical, Temporal, Performance, Effort, and Frustration; Trust, using Jian et al.’s Trust in Automation Scale; Perceived Control, using PCTL; User Experience, using UMUX-Lite; and Perceived Privacy Protection, using Zhou et al.’s Rescriber metrics of “Unnecessary information protection,” “Personal information protection,” “Reduce concern,” and “Willingness to use.” Statistical analysis used Friedman’s \(\chi^2\) with Nemenyi post-hoc at significance level \(\alpha=0.05\).

The reported findings show no significant differences on five TLX dimensions, while Frustration was lower with PrivWeb than with notification-only n/c, with \(\chi^2_2=8.346\), \(p=0.015 < 0.05\). Trust was higher for PrivWeb than for n/b, with \(\chi^2_2=7.000\), \(p=0.030 < 0.05\). Privacy Protection measures showed stronger effects: “Unnecessary information protection” yielded \(\chi^2_2=11.375\), \(p=0.003 < 0.01\); “Personal info protection” yielded \(\chi^2_2=14.816\), \(p<0.001\); and “Reduced concern” yielded \(\chi^2_2=16.148\), \(p<0.001\). PrivWeb significantly outperformed both baselines in post-hoc tests on these privacy metrics.

The paper further reports no losses in Perceived Control, with \( \text{PCTL } \chi^2_2=5.778, p=.06\); User Experience, with \( \text{UMUX } \chi^2_2=4.500, p=.10\); or Willingness to Use, with \(\chi^2_2=1.469, p=.50\). Qualitatively, 13 of 14 participants preferred PrivWeb. Reported comments include: “Awareness without agency is anxiety-provoking; PrivWeb’s controls restore safety,” “Tiered notifications strike the right balance—critical data prompts me, routine data stays in the background,” and “I felt more in control without extra mental effort.”

## 6. Relation to visual PII protection and the broader PrivWeb setting

A related line of work addresses privacy-preserving deployment for computer-use agents at the screenshot level rather than primarily through DOM mediation. WebPII introduces “a fine-grained synthetic benchmark of 44,865 annotated e-commerce UI images” for visual PII detection, together with WebRedact, “a 2-class object detector (text vs. image) based on YOLOv8 (Ultralytics) running at 640×640 input resolution for CPU” [2603.17357].

WebPII defines nine fine-grained PII and identifier categories: full names and personal names; addresses; email addresses and usernames; phone numbers; payment details; order identifiers; tracking numbers and delivery codes; dates; and financial totals. Its benchmark design emphasizes an extended PII taxonomy, anticipatory detection for partially-filled forms, and scalable generation through VLM-based UI reproduction. The reported generation pipeline produces 44,865 images and 993,461 total bounding-box annotations, using Faker, the ABO product database, LLM-extracted metadata, React rendering under Vite/Playwright, DOM queries over data attributes such as `data-pii`, `data-product`, and `data-order`, and a four-stage VLM-based UI reproduction loop with human-in-the-loop correction of 39% of layouts over approximately 312 iterations amortized across 25 variants and all fill states [2603.17357].

Its evaluation uses mean Average Precision at IoU \(=0.5\),
\[
\mathrm{mAP@50} \;=\;\frac{1}{|\mathcal{C}|}\sum_{c\in\mathcal{C}} \mathrm{AP}_c(0.5),
\]
and reports, on Test\(_{\text{Cross–Company}}\), Tesseract + Presidio at 0.183 mAP@50 and 1.3 s latency, LayoutLMv3 + GPT-4o-mini at 0.357 and 2.9 s, WebRedact at 0.753 and 20 ms, and WebRedact-large at 0.842 with 312 ms on CPU or 13 ms on GPU. Cross-Page, Cross-Company, and Cross-Type splits yield 0.797, 0.753, and 0.728 mAP@50 respectively [2603.17357].

This suggests that PrivWeb and WebPII occupy adjacent layers of the same privacy problem. PrivWeb concentrates on localized LLM-based classification, thresholded anonymization, and adaptive user control for web-agent access to page content. WebPII concentrates on visual PII detection in screenshots, including transaction-level identifiers and partially filled forms. A plausible implication is that the two approaches are complementary: PrivWeb addresses content-aware mediation within browser interaction flows, while WebPII provides a practical component for on-device, real-time PII redaction when cloud-hosted inference or screenshot transmission becomes part of the system design.

## 7. Interpretive issues and limitations

PrivWeb’s reported results establish that unobtrusive, transparent data management and selective user control can reduce perceived privacy risks without increasing cognitive effort in the reported study design [2509.11939]. At the same time, the paper does not claim a formal differential-privacy guarantee, and its anonymization mechanism is limited to omission or placeholder replacement. Its enforcement logic is intentionally simple, relying on fixed thresholds \(T_{\text{block}}=3\) and \(T_{\text{notif}}=1\), a three-level sensitivity schema, and a once-per-page classification pass.

The technical evaluation also indicates a latency-accuracy trade-off characteristic of localized LLM deployment. Qwen3-8b delivers 75.4% overall accuracy with 6.42 s per DOM page, whereas smaller models reduce latency, down to 2.86 s for Qwen3-1.7b, at the cost of model capacity. The paper reports these latencies as acceptable in user testing, but does not represent the system as a realtime detector in the sense used by WebRedact’s 20 ms CPU inference [2603.17357].

A common misconception would be to equate PrivWeb with a generic notification overlay. The paper’s contribution is narrower and more structured: a trusted browser add-on that mediates agent requests, classifies extracted text with a localized LLM, maps categories to sensitivity scores, and applies a two-tiered control policy before returning a sanitized DOM. Another misconception would be to read its privacy claims as cryptographic or formally private; the paper explicitly does not do so. Instead, PrivWeb is best understood as a client-side, content-aware guardrail for LLM-powered web automation, with empirical support for reduced perceived privacy risk and preserved usability under the reported conditions.

Source: https://www.emergentmind.com/topics/privweb