{"id":"fe7a5be3-63b4-477a-890d-075aeded3fab","arxiv_id":"1908.02205","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"high","formal_verification":"none","parameter_count":0,"one_line_summary":"An extension at the end of Chrome's execution pipeline can see and steal data added to the shared DOM by earlier extensions, but the proposed monitor-extension defense is not shown to work.","lead":"This paper shows that a malicious browser extension installed last can read private data that other extensions add to web pages, because Chrome runs extensions one after another on the same page. It also proposes a 'monitor extension' isolation scheme, but the scheme is missing a deployment mechanism and its security proof assumes the attacker lacks privileges.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The monitor scheme is only analyzed for synchronous one-shot content scripts; a usual attacker can schedule a timer or MutationObserver at its pipeline slot and read the fully patched DOM after the final Apply, so the claimed effective protection is not established and is in fact false for…","rationale":"The reader's deployment concern is valid and supports rejection. My objection is stronger because it defeats the scheme even under ideal deployment: the paper itself admits it does not handle timers and microtasks, and a setInterval callback is a standard content-script capability. This is not an artificial edge case; it is the same kind of asynchronous behavior used in the paper's own attack examples. The formal model equates knowledge with the DOM received at the extension's pipeline slot and explicitly excludes side-effects, so the proof of 'effective protection' does not cover the attacker that matters. A secondary correctness problem is functional equivalence: because each extension receives only DOM0, extensions whose behavior depends on earlier extensions' output produce a different final page, contradicting Section 4.1's claim that the final HTML is unchanged. These independent problems reinforce the existing REJECT verdict, so no verdict adjustment is needed.","tokens_in":15720,"tokens_out":9104,"duration_ms":111723,"concrete_test":"Build a clean Chromium profile with (i) E1, a benign extension inserting a unique marker (e.g., data-test='leak') into the DOM; (ii) the paper's initial/middle/final monitor extensions installed exactly in the prescribed interleaved order; and (iii) attacker A installed last, whose content script registers setInterval(() => document.body.innerHTML, 2000) and sends a hash to a local server. Load a page with E1 active, wait 3s, and check the exfiltration log. If the marker appears in A's output, the monitor scheme does not protect a usual attacker and the Section 4/abstract guarantee is falsified.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 2 explicitly brackets microtasks as future work ('we are not taking microtasks into consideration... mandatory to modify Chromium's source code'), and Section 4.1 says setInterval tasks 'are not covered in detail' and 'cannot be controlled through JavaScript code alone.' These exclusions are not peripheral: the paper's own attack examples rely on event listeners and side effects that occur after the pipeline slot. In the monitor solution, the attacker's content script is handed DOM0 and its DOM diffs are removed, but nothing prevents that same script from registering a setInterval callback or MutationObserver. When the final Apply module patches the stored diffs into the shared DOM, the callback runs and reads the complete, fully patched page, including Pinterest spans, Evernote notes, or credentials placed by earlier extensions. The formal model defines knowledge only as the DOM input at execution time (Definition 2) and explicitly excludes side-effects; the proofs therefore cannot license the abstract claim of 'effectively protects' against usual attackers. Even a perfect deployment with monitors interleaved between every pair of extensions leaves this bypass open. Consequently the central countermeasure guarantee fails against a capability that a completely unprivileged content script possesses.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper studies a privacy issue in Chromium's extension model: content scripts of installed extensions run sequentially and share a synchronized DOM, so the n-th extension can observe DOM changes made by the first n-1 extensions. The authors formalize this as a knowledge problem, define 'usual' and 'strong' attackers, and propose a countermeasure consisting of monitor extensions that compute per-extension DOM diffs, delete those diffs before passing the DOM to the next extension, and finally merge all diffs into the page. They claim soundness and robustness of the scheme, and report experiments measuring memory and latency overhead.","tokens_in":15935,"tokens_out":4614,"duration_ms":51459,"significance":"The attack observation is valuable and likely novel in this form: it is concrete, demonstrated against popular real extensions (Pinterest, Evernote, vidIQ), and it highlights a genuine gap between Chromium's isolated-world security model and its lack of privacy isolation between extensions. The paper is also commendably explicit about some limitations, such as excluding microtasks and setInterval-based tasks. However, the central countermeasure claim—that the monitor extension 'effectively protects the user against usual attackers as well as against strong attackers'—is not supported by the analysis once asynchronous DOM observers are considered, and the proposed deployment mechanism for interleaving monitors between already-installed extensions is not described. Thus the paper's main positive contribution is the attack demonstration and the conceptual formalization, while the proposed defense is not established.","major_comments":[{"comment":"The claimed protection against 'usual attackers' is not established. Section 4.1 concedes that setInterval periodic tasks 'are not covered in detail' and 'cannot be controlled through JavaScript code alone,' and Section 2 explicitly excludes microtasks, leaving them to future work. These exclusions are not peripheral: an ordinary, unprivileged content script can register a setInterval callback or a MutationObserver during its pipeline slot, and when the final Apply module later patches the stored diffs into the shared DOM, the callback runs and can read the fully patched DOM, including content introduced by earlier extensions. This defeats the Abstract's claim of effective protection against usual attackers, since the formal knowledge model (Definition 2) only counts the DOM input at execution time and Section 3.3 disclaims all extensions' side-effects. The proofs therefore cannot license the unrestricted guarantee stated in the paper.","section":"Abstract; §4.1; §2"},{"comment":"The deployment premise of the proposed solution is unsubstantiated. The scheme requires an initial monitor to run first, a final monitor to run last, and a monitor to run between every pair of original extensions. In Chromium, however, content scripts are ordered by run_at, event propagation, and installation time, so a newly installed extension is appended at the end of the pipeline. The paper does not explain how the set of monitor extensions can be inserted between already-installed extensions. The Secure Preferences and management-permission techniques in Section 3.1 are described as attacker capabilities, not as a defender's deployment mechanism. Without such a mechanism, the proposed extension-only countermeasure cannot be installed into the required configuration on current browsers.","section":"§4, Figure 3"},{"comment":"The robustness guarantee is conditional in a way that removes the strong attacker's defining capability. Proposition 2 states that the solution is robust against strong attackers under the assumption that the monitor extensions have management privileges while the attacker does not. But Definition 3 characterizes a strong attacker precisely by its access to the effects of all extensions, and Section 3.4 describes the strong attacker as one that installs itself interleaved in the pipeline. The assumption that the attacker lacks management privileges therefore excludes the mechanism that the paper itself uses to define the strong attacker, rather than demonstrating a defense against it. The proposition is also stated without a proof. A meaningful robustness claim would need to argue why an unprivileged attacker cannot obtain the required interleaving through Secure Preferences modification or another channel, or explicitly restrict the threat model to exclude such capabilities.","section":"§4.1, Proposition 2"}],"minor_comments":[{"comment":"The sentence 'Finally, we tested it againts vidIQ Vision for YouTube' contains a typo ('againts' for 'against'); additionally, the paragraph about vidIQ reports that the extension asks for a username and password, but then states that all extensions subscribed to key events may obtain both—clarify which mechanism the malicious extension actually exploits.","section":"§3.2"},{"comment":"The reported worst-case HTML parse delay of 5000 ms for 10 extensions is presented without confidence intervals or per-site variance, even though the experiments average over 50 runs of Alexa's Top 30 sites; reporting variance would make the performance claim more robust.","section":"§5.2, Figure 4a"},{"comment":"The notation in Figure 3 is inconsistent with the text: the figure labels the final pipeline output as DOM_{n+1}, while Section 4 describes the final DOM as DOM_n after the stored diffs are applied. The labels should be aligned.","section":"Figure 3 and §4"},{"comment":"The paper uses the term 'monotonic' both for a subsequence in Proposition 1 and for the whole pipeline in the following paragraph, and the promised formal tree definitions for insertions, deletions, and updates in footnote 2 are never given; either define these operations or remove the promise.","section":"§3.3"}],"recommendation":"reject","confidential_remarks":"The attack portion of the paper is a useful and probably publishable observation on its own, and the formalization of default knowledge is a reasonable starting point. However, the countermeasure does not deliver the guarantee stated in the abstract: the standard capability of scheduling asynchronous tasks or observing DOM mutations bypasses the monitor scheme, and the claimed deployment configuration is not achievable with the mechanisms the paper describes. These are architectural obstacles rather than presentation issues, so I do not see a minor revision that would preserve the paper's central contribution."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Dear Colleague,\n\nThe attack is real; the defense is not. If you take one thing from this paper, take the attack: Chrome gives each extension's content script a pipeline slot, and every later script sees the DOM as earlier scripts left it. The authors demonstrate with Pinterest, Evernote, and vidIQ that a malicious extension installed late can read or manipulate data those extensions put in the page. That part is credible, well-illustrated, and worth citing.\n\nWhat is new is the order-specific framing and a formal pipeline/knowledge model. The idea behind the countermeasure—diff each extension's changes, delete them before passing the DOM on, then re-apply at the end—is natural and is implemented as monitor extensions.\n\nThe countermeasure, however, only works for synchronous, one-shot content scripts, and the paper more or less admits that: microtasks are excluded, and setInterval tasks are said not to be covered. This is not a peripheral limitation. An unprivileged malicious extension can register a setInterval callback or a MutationObserver during its slot in the pipeline. The monitor chain erases the DOM diffs before the next extension runs, but the callback stays alive and, after the final Apply patches the stored diffs back into the DOM, it reads the fully assembled page. Their own attack examples use event listeners, which have exactly this persistence property. So the claim in the abstract that the solution 'effectively protects' against usual attackers is not supported; on the evidence in the paper it is false.\n\nTwo more soft spots, in proportion. Deployment: the monitors have to be interleaved between every pair of already-installed extensions, and Chromium orders by installation time. No mechanism is given to insert a newly installed extension into the middle of the pipeline, so the scheme as described cannot be dropped into an existing browser. And the robustness proof (Proposition 2) assumes monitors have management privileges while the attacker does not, so the guarantee is partly baked into the assumption. The paper also never compares against the authors' own prior work [15] on probing attacks, which is a real gap. Performance overhead is large—a reported 5 second HTML parse delay with 10 extensions—and no code or artifact is shipped.\n\nThe attack section deserves a serious referee; the countermeasure sections need major rework. My recommendation: accept for peer review but expect a reject-and-resubmit, with the countermeasure claims either removed or scoped to one-shot synchronous scripts. It is a useful paper about a real leak, wrapped around a solution that does not survive contact with timers.","headline":"A real and demonstrated DOM-order attack against Chrome extensions, paired with a countermeasure whose central guarantee is broken once timers or observers are allowed.","tokens_in":16442,"tokens_out":3427,"would_cite":true,"duration_ms":39123,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A browser extension that runs late in Chromium's extension pipeline can read and tamper with everything earlier extensions add to the page, and the paper proposes a monitor-extension scheme that claims to stop this without modifying the…","keywords":["browser extensions","Chromium","content scripts","DOM privacy","extension order attack","monitor extension","isolated worlds","information leakage"],"falsifier":"On an unmodified Chromium browser, install extension A, then extension B, then the proposed monitor set; if the content B sees still includes A's changes before any monitor has had a chance to diff and delete them, the interleaving premise fails and the scheme cannot deliver its guarantee.","tokens_in":15484,"feed_emoji":"🧩","tokens_out":7197,"duration_ms":70807,"temperature":0.7,"pith_summary":"The paper sets out to show that Chromium's extension model leaks information between extensions: because content scripts run one after another and every DOM change is immediately synchronized to the shared page, an extension placed later in the execution pipeline can read, and even manipulate, everything that earlier extensions added to the page. It demonstrates the attack against real extensions, including Pinterest, Evernote Web Clipper, and vidIQ Vision, where a dummy unprivileged extension collects pins, notes, and credentials. It then proposes a countermeasure built as browser extensions themselves: interleave monitor extensions in the pipeline, have each monitor compute and store the diff produced by an extension, delete those changes before the next extension runs, and merge all diffs back at the end. If the scheme works, the final page is unchanged while every extension only ever sees the original DOM0.","feed_headline":"Extensions leak each other's page data by install order","feed_subtitle":"A late-running malicious extension can read pins, notes, and credentials added by earlier ones; monitors aim to block it.","key_machinery":"The mechanism that carries the attack is Chromium's shared-DOM architecture: each extension's content script runs in an isolated V8 world with its own DOM wrapper, but all wrappers are backed by the same Blink C++ DOM object and are automatically synchronized, so writes by one extension become visible to the next. The countermeasure is a monitor extension composed of four modules: Diff (compare $\\mathrm{DOM}_{i-1}$ with $\\mathrm{DOM}_i$), Store (log the patch), Del (remove the patch from the DOM before the next extension executes), and Apply (patch all stored changes back at the end of the pipeline). Formally it transforms the pipeline $f_n \\circ \\cdots \\circ f_1(\\mathrm{DOM}_0)$ into $f_{E_{\\mathrm{final}}} \\circ f_{E_n} \\circ f_{E_{\\mathrm{mon}}^{n-1}} \\circ \\cdots \\circ f_{E_{\\mathrm{mon}}^1} \\circ f_{E_1} \\circ f_{E_{\\mathrm{initial}}}(\\mathrm{DOM}_0)$, with an initial extension included to capture the browser's own preprocessing of the HTML. The stored patches are kept in a shared table whose entries record the operation, position, and action of each change.","core_discovery":"On the paper's own terms, the central discovery is that the n-th extension in Chromium's extension pipeline can learn all content introduced by the first n−1 extensions, because the DOM wrapper each content script sees is synchronized with the same underlying DOM after every step. A malicious extension needs no extra permissions: it can simply subscribe to events on elements inserted by earlier extensions, or inspect the DOM it receives as input. The paper formalizes this with a notion of default knowledge, $K(E_i) = \\{\\mathrm{DOM}_0\\} \\cup \\{\\mathrm{DOM}_{i-1}\\}$, and notes that in monotonic pipelines (where extensions only insert nodes), later extensions are ordered by what they can see, $E_{i-1} \\sqsubseteq E_i$. The proposed fix claims to make every extension's knowledge equal to $\\mathrm{DOM}_0$ by replacing the natural pipeline with interleaved monitor extensions; the authors prove soundness and robustness for usual attackers and, under assumptions, for strong attackers.","pith_inferences":["The same information leak should appear in any browser or host that gives extensions sequential access to a shared mutable document without isolating writes; the paper's attack description is not specific to one implementation detail.","A practical gap the paper leaves open is deployment: Chromium orders extensions by installation time, and the paper does not show how a newly installed monitor can be inserted between already-installed extensions, so realizing the interleaving may require browser changes or management privileges.","Because the scheme's correctness is argued for monotonic pipelines and the paper excludes microtasks and setInterval-style periodic tasks, timing-based exfiltration and extensions that delete or update existing content remain plausible bypasses even if the diff-store-delete mechanism works.","A testable extension of the idea: replace the extension-level monitors with a MutationObserver inside each isolated world to log changes synchronously, which could reduce the per-extension overhead and handle asynchronous writes."],"forward_implications":["A plain extension installed after Pinterest, Evernote Web Clipper, or vidIQ Vision can harvest the pins, notes, and credentials those extensions place in the page, simply by listening to DOM events on the elements they insert.","Execution order is a privacy ordering: the later an extension runs, the more prior extensions' content it can see, so a malicious store submission needs only be installed late.","With the monitor scheme in place, every extension's input is reduced to the original DOM0, so the knowledge advantage that comes from position in the pipeline disappears.","Because Apply restores all stored diffs at the end, the final page the user sees is the same whether or not the monitors are present, assuming only insertions occur.","The scheme detects a strong attacker who interleaves copies of itself through the pipeline only if the monitors hold management privileges and the user never grants those privileges to the attacker."],"supporting_citations":[{"why":"Google's description of V8 isolated worlds; it is the source for the shared Blink DOM object that makes one extension's changes visible to the next.","marker":"[5]"},{"why":"Chromium project reference; establishes the browser whose extension registry, content-script pipeline, and install-time ordering are attacked.","marker":"[12]"},{"why":"Chrome external extensions documentation; supports the claim that other software can install or modify extensions, enabling pipeline-order manipulation.","marker":"[1]"},{"why":"Jagpal et al. on malicious extensions in official stores; used to argue the order attack evades existing static analysis.","marker":"[8]"},{"why":"Saini et al. colluding extension attack against Firefox; motivates the lack of isolation that the paper transposes to Chromium.","marker":"[14]"},{"why":"Secure Preferences modification document; used to show how install_time can be edited to move an extension to the end of the pipeline.","marker":"[16]"},{"why":"Extensity extension; used to show how management permissions can disable and re-enable extensions to reorder them.","marker":"[4]"}],"fun_headline_variants":["Extension order attack steals earlier extensions' data","Install-order attack reads prior extension data","Malicious extension exploits run order to spy","Countermeasure: monitors block extension order leaks","Install order turns extensions into spies"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The solution stands on the assumption that the user can install monitor extensions between every pair of existing extensions, with the initial monitor first and the final monitor last, and can grant those monitors management privileges while the attacker never receives them; Chromium's install-time ordering gives no mechanism for inserting a new extension between already-installed ones.","fun_headline_variants_meta":{"raw":{"variants":["Extension order attack steals earlier extensions' data","Install-order attack reads prior extension data","Malicious extension exploits run order to spy","Countermeasure: monitors block extension order leaks","Install order turns extensions into spies"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000948,"raw_usage":{"total_tokens":4048,"prompt_tokens":948,"completion_tokens":3100,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":564,"completion_tokens_details":{"reasoning_tokens":3037}},"tokens_in":564,"tokens_out":3100,"duration_ms":22394,"temperature":1.0,"reasoning_tokens":3037,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-14T14:51:53.770459+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"On an unmodified Chromium browser, install extension A, then extension B, then the proposed monitor set; if the content B sees still includes A's changes before any monitor has had a chance to diff and delete them, the interleaving premise fails and the scheme cannot deliver its guarantee.","supporting_citations":[{"cited_title":"Design of V8 bindings","cited_arxiv_id":null,"evidence_quote":"Google's description of V8 isolated worlds; it is the source for the shared Blink DOM object that makes one extension's changes visible to the next."},{"cited_title":"Chromium","cited_arxiv_id":null,"evidence_quote":"Chromium project reference; establishes the browser whose extension registry, content-script pipeline, and install-time ordering are attacked."},{"cited_title":"External Extensions","cited_arxiv_id":null,"evidence_quote":"Chrome external extensions documentation; supports the claim that other software can install or modify extensions, enabling pipeline-order manipulation."},{"cited_title":"Trends and lessons from three years fighting malicious ex- tensions","cited_arxiv_id":null,"evidence_quote":"Jagpal et al. on malicious extensions in official stores; used to argue the order attack evades existing static analysis."},{"cited_title":"Colluding browser extension attack on user privacy and its implication for web browsers","cited_arxiv_id":null,"evidence_quote":"Saini et al. colluding extension attack against Firefox; motivates the lack of isolation that the paper transposes to Chromium."},{"cited_title":"Adlice Software","cited_arxiv_id":null,"evidence_quote":"Secure Preferences modification document; used to show how install_time can be edited to move an extension to the end of the pipeline."},{"cited_title":"Extensity","cited_arxiv_id":null,"evidence_quote":"Extensity extension; used to show how management permissions can disable and re-enable extensions to reorder them."}],"review_version":1}