After You, Please: Browser Extensions Order Attacks and Countermeasures

Gerardo Schneider; Juan Tapiador; Pablo Picazo-Sanchez

REVIEW 3 major objections 4 minor 19 references

After You, Please: Browser Extensions Order Attacks and Countermeasures

T0 review · 3 major / 4 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read 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…

desk verdict 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. read the letter →

arxiv 1908.02205 v1 pith:4QOTVRRH submitted 2019-08-06 cs.CR

Pablo Picazo-Sanchez , Juan Tapiador , Gerardo Schneider This is my paper · ORCID

classification cs.CR

keywords browserextensionsChromiumcontentscriptsDOMprivacyextensionorderattackmonitorisolatedworldsinformationleakage

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

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.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

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.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Dear Colleague,

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

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

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

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

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

Referee Report

3 major / 4 minor

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.

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 (3)

[Abstract; §4.1; §2] 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.
[§4, Figure 3] 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.
[§4.1, Proposition 2] 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.

minor comments (4)

[§3.2] 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.
[§5.2, Figure 4a] 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.
[Figure 3 and §4] 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.
[§3.3] 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.

Circularity Check

1 steps flagged · score 6.0 of 10

The monitor scheme's protection guarantee is definitional: attacker knowledge is defined as the DOM an extension receives, the Diff/Del construction passes only DOM0, and side-effect/timer channels are explicitly excluded, so the proof restates the construction rather than establishing the abstract's 'effective protection' claim.

self definitional [Section 4.1 ('Does our solution indeed mitigate possible attacks?') with Definition 2 (Section 3.3) and Section 2 microtask/task limitations]
"Deﬁnition 2. ... K(Ei) = {DOM0 | ∃e ∈ EV · e = load()}∪{ DOMi−1} for 1 < i≤ n ... On the contrary, when we measure the knowledge of an extension with our solution, it is thus decreased to DOM0 (given that our solution only passes the original DOM to each extension)."

Definition 2 defines the attacker's default knowledge as the DOM input it receives (K(Ei) = {DOM0} ∪ {DOMi−1}). The monitor solution's Diff/Del modules are defined to delete every extension's diff before passing the DOM onward, so each extension receives exactly DOM0. The claimed result that usual attackers are mitigated is therefore true by construction: it restates the design decision 'pass DOM0' instead of predicting an independent security property. The model also explicitly excludes side-effects and microtasks, and Section 4.1 adds that setInterval-style periodic tasks cannot be controlled through JavaScript alone; the paper's own attack relies on event listeners and post-slot execution, which are outside the proven model.

full rationale

The paper's first contribution—the order-based leakage attack and its demonstration with Pinterest, Evernote, and vidIQ—is self-contained and not circular: it follows from Chromium's documented FIFO injection order and shared DOM synchronization, and the malicious extension's ability to read previously inserted DOM content is an external observation. The circularity is confined to the countermeasure. The formal model (Definition 2) identifies knowledge with the DOM handed to an extension, and the proposed pipeline hands each extension DOM0 (Diff/Del remove prior changes; Apply restores them at the end); the 'proof' of protection is the construction itself. Side-effect channels, which the paper's own attack examples use (event subscription, timers), are explicitly declared out of scope, so the abstract's 'effectively protects the user against usual attackers' overstates what the derivation shows. The strong-attacker robustness proposition (Proposition 2) is likewise conditional on assumptions that are not derived: monitors receive management privileges, the attacker does not, and monitor extensions can be inserted between every pair of already-installed extensions, for which no deployment mechanism is provided in Chromium's installation-order model. These are assumption and feasibility gaps more than equations reducing to themselves, but together they make the headline guarantee largely a restatement of the model's definitions. The initial attack finding is independent and unaffected, so the score reflects partial circularity of the countermeasure claim rather than of the whole paper.

Assumptions & free parameters 0 free parameters · 6 assumptions · 1 invented entities

The formal claims rest on several domain assumptions about Chromium architecture and on two ad hoc assumptions about monitor deployment and privilege that are not established. There are no fitted numeric parameters. The monitor extension is a new proposed component without independent evidence.

assumptions (6)

domain assumption The functional effect of an extension can be represented as a tree transformation using only insertions, deletions, updates, or no operation.
Introduced in Section 3.3 (Definition 1). This excludes side effects such as network calls, persistent JavaScript listeners, timers, and microtasks, which the paper explicitly says are out of scope.
domain assumption All DOM changes made by one extension are visible to later extensions because all isolated worlds share the same underlying Blink C++ DOM object.
Stated in Section 2 and used throughout the attacker model. The attack depends on this being true in Chromium.
domain assumption When extensions share run_at and event propagation settings, Chromium executes them in FIFO order by installation time.
Section 3 item 3. This is what lets the attacker place itself at the end of the pipeline.
ad hoc to paper A user-level extension can insert monitor extensions between every pair of already installed extensions, with an initial monitor first and a final monitor last.
Assumed in Section 4 and Section 5 ('our extension based solution inserts a middle monitor extension between every two original extensions'). No Chrome API or mechanism is provided.
ad hoc to paper Monitor extensions are granted management privileges and the attacker is not granted the same privileges.
Proposition 2 in Section 4.1 states robustness is conditional on this. Since both monitors and attackers are ordinary extensions installed by the user, this is not established.
domain assumption All relevant extension behavior occurs synchronously during the initial content-script execution, so tasks, microtasks, and setInterval callbacks can be ignored.
Section 2 excludes microtasks and Section 4.1 says periodic tasks such as setInterval are not covered. The knowledge claims are only meaningful under this restriction.

invented entities (1)

Monitor extension chain with Diff, Store, Del, and Apply modules
purpose: Interleave with original extensions to delete each extension's DOM changes before the next extension runs, then replay all changes at the end, simulating isolated execution.
The paper describes and tests only its own prototype; no code is shipped, no third-party replication is reported, and the deployment mechanism for inserting the monitors into an existing pipeline is not shown.

how reviews work

0 comments

Cite this review

Pith. "Pith review of After You, Please: Browser Extensions Order Attacks and Countermeasures." pith.science (2026). https://pith.science/paper/4QOTVRRH

@misc{pith2026190802205,
  author       = {Pith},
  title        = {Pith review of: After You, Please: Browser Extensions Order Attacks and Countermeasures},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/4QOTVRRH}},
  note         = {Machine review of arXiv:1908.02205}
}

read the original abstract

Browser extensions are small applications executed in the browser context that provide additional capabilities and enrich the user experience while surfing the web. The acceptance of extensions in current browsers is unquestionable. For instance, Chrome's official extension repository has more than 63,000 extensions, with some of them having more than 10M users. When installed, extensions are pushed into an internal queue within the browser. The order in which each extension executes depends on a number of factors, including their relative installation times. In this paper, we demonstrate how this order can be exploited by an unprivileged malicious extension (i.e., one with no more permissions than those already assigned when accessing web content) to get access to any private information that other extensions have previously introduced. Our solution does not require modifying the core browser engine as it is implemented as another browser extension. We prove that our approach effectively protects the user against usual attackers (i.e., any other installed extension) as well as against strong attackers having access to the effects of all installed extensions (i.e., knowing who did what). We also prove soundness and robustness of our approach under reasonable assumptions.

Figures

Figures reproduced from arXiv: 1908.02205 by the authors.

**Figure 2.** Browser Extensions Architecture in Chromium this world concept means that the content scripts of each extension will run its own JavaScripts over different DOMs. However, all these DOMs are synchronized so that all changes made by each individual JavaScript will automatically be sent to other DOMs (other wrappers and the main DOM the user sees). According to the official documentation, V8 has three different worl… view at source ↗

**Figure 3.** Architecture of our solution and its four [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗

Figures from the paper (1 more)

**Figure 4.** Figure 4: Evaluation of our proposal according to W3C parameters [PITH_FULL_IMAGE:figures/full_fig_p011_4.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

19 extracted references · 19 canonical work pages

[15]

La- tex gloves: Protecting browser extensions from probing and revelation attacks

Alexander Sjösten, Steven Van Acker, Pablo Picazo-Sanchez, and Andrei Sabelfeld. La- tex gloves: Protecting browser extensions from probing and revelation attacks. Power, page 57, 2018

work page 2018
[1]

External Extensions

Chrome. External Extensions. https://developer.chrome.com/ extensions/external_extensions, 2018

work page 2018
[2]

W3C DOM4

W3C DOM Technical Committee. W3C DOM4. https://www.w3.org/TR/ domcore/, 2018

work page 2018
[3]

Google Chrome Developer

Jake Archibald. Google Chrome Developer. Tasks, microtasks, queues and schedules. https://jakearchibald.com/2015/ 12 tasks-microtasks-queues-and-schedules/ , 2018

work page 2015
[4]

Extensity

Extensity. Extensity. https: //chrome.google.com/ webstore/detail/extensity/ jjmflmamggggndanpgfnpelongoepncg, 2018

work page 2018
[5]

Design of V8 bindings

Google. Design of V8 bindings. https://chromium.googlesource. com/chromium/src/third_party/+/ master/WebKit/Source/bindings/ core/v8/V8BindingDesign.md# World, 2018

work page 2018
[6]

Chromium Secure Prefer- ences

HMAC. Chromium Secure Prefer- ences. http://www.adlice.com/ google-chrome-secure-preferences/ , 2018

work page 2018
[7]

Measuring the Crit- ical Rendering Path

Ilya Grigorik. Measuring the Crit- ical Rendering Path. https: //developers.google.com/web/ fundamentals/performance/ critical-rendering-path/ measure-crp, 2018

work page 2018

Show all 19 references

[8]

Trends and lessons from three years ﬁghting malicious ex- tensions

Nav Jagpal, Eric Dingle, Jean-Philippe Gravel, Panayiotis Mavrommatis, Niels Provos, Mo- heeb Abu Rajab, and Kurt Thomas. Trends and lessons from three years ﬁghting malicious ex- tensions. In USENIX, pages 579–593, 2015

2015
[9]

Bubbling and captur- ing

JavaScript. Bubbling and captur- ing. https://javascript.info/ bubbling-and-capturing, 2018

2018
[10]

Browser ﬁnger- printing: A survey

Pierre Laperdrix, Nataliia Bielova, Benoît Baudry, and Gildas Avoine. Browser ﬁnger- printing: A survey. 2019

2019
[11]

How many ﬁrefox users have add-ons installed? https: //blog.mozilla.org/addons/2011/ 06/21/firefox-4-add-on-users/ , 2018

Mozilla Add ons Blog. How many ﬁrefox users have add-ons installed? https: //blog.mozilla.org/addons/2011/ 06/21/firefox-4-add-on-users/ , 2018

2011
[12]

Chromium

Chromium Projects. Chromium. https:// www.chromium.org, 2018

2018
[13]

Rogowski, M

R. Rogowski, M. Morton, F. Li, F. Monrose, K. Z. Snow, and M. Polychronakis. Revisiting browser security in the modern era: New data- only attacks and defenses. In EuroS&P, pages 366–381, April 2017

2017
[14]

Colluding browser extension attack on user privacy and its implication for web browsers

Anil Saini, Manoj Singh Gaur, Vijay Laxmi, and Mauro Conti. Colluding browser extension attack on user privacy and its implication for web browsers. Computers & Security, 63:14 – 28, 2016

2016
[16]

Adlice Software

Tigzy. Adlice Software. Chrome Secure Preferences Modiﬁcation. https://cs. chromium.org/chromium/src/rlz/ lib/machine_id.cc?sq=package: chromium, 2018

2018
[17]

Navigation timing

W3C. Navigation timing. https://www. w3.org/TR/navigation-timing/, 2018

2018
[18]

Browser Statistics

w3schools. Browser Statistics. https: //www.w3schools.com/browsers/, 2018

2018
[19]

Understanding malvertising through ad-injecting browser extensions

Xinyu Xing, Wei Meng, Byoungyoung Lee, Udi Weinsberg, Anmol Sheth, Roberto Perdisci, and Wenke Lee. Understanding malvertising through ad-injecting browser extensions. In WWW, pages 1286–1295, 2015. 13

2015

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.

[1] [15]

La- tex gloves: Protecting browser extensions from probing and revelation attacks

Alexander Sjösten, Steven Van Acker, Pablo Picazo-Sanchez, and Andrei Sabelfeld. La- tex gloves: Protecting browser extensions from probing and revelation attacks. Power, page 57, 2018

work page 2018

[2] [1]

External Extensions

Chrome. External Extensions. https://developer.chrome.com/ extensions/external_extensions, 2018

work page 2018

[3] [2]

W3C DOM4

W3C DOM Technical Committee. W3C DOM4. https://www.w3.org/TR/ domcore/, 2018

work page 2018

[4] [3]

Google Chrome Developer

Jake Archibald. Google Chrome Developer. Tasks, microtasks, queues and schedules. https://jakearchibald.com/2015/ 12 tasks-microtasks-queues-and-schedules/ , 2018

work page 2015

[5] [4]

Extensity

Extensity. Extensity. https: //chrome.google.com/ webstore/detail/extensity/ jjmflmamggggndanpgfnpelongoepncg, 2018

work page 2018

[6] [5]

Design of V8 bindings

Google. Design of V8 bindings. https://chromium.googlesource. com/chromium/src/third_party/+/ master/WebKit/Source/bindings/ core/v8/V8BindingDesign.md# World, 2018

work page 2018

[7] [6]

Chromium Secure Prefer- ences

HMAC. Chromium Secure Prefer- ences. http://www.adlice.com/ google-chrome-secure-preferences/ , 2018

work page 2018

[8] [7]

Measuring the Crit- ical Rendering Path

Ilya Grigorik. Measuring the Crit- ical Rendering Path. https: //developers.google.com/web/ fundamentals/performance/ critical-rendering-path/ measure-crp, 2018

work page 2018