This page is about browser extensions as the object of a measurement: what they leak, what they can be made to do, whether a page can tell which ones you have installed, and how you get a corpus of them in the first place. It is not about uBlock Origin as a classifier — that is Requests and Filter lists — and it is not about the browser's own anti-tracking machinery, which is Browser protection.

The distinction matters because the corpus does not respect it. Of the 218 papers in the seven-venue corpus that a candidate sweep pulls out as possibly being about extensions, 92 turn out to be papers that built an extension to collect their data or to ship their defence, and 68 are papers that measured extensions. If you search for “browser extension” you will mostly find the first kind.

• Arcanum [1Xie, Qinge; Kasi Murali, Manoj Vignesh; Pearce, Paul; Li, Frank (2024): "Arcanum: Detecting and Evaluating the Privacy Risks of Browser Extensions on Web Pages and Web Content", in: Proceedings of the USENIX Security Symposium. (Link)], USENIX Security 2024 — the current template for a whole-store study. Dynamic taint tracking inside Chrome, every one of “all 113,099 functional extensions in the Chrome Web Store” driven against seven real logged-in sites. Read §4.1 for how those sites were chosen and instrumented, and §4.2 with Table 4 for what a 2.68% base rate looks like.
• Carnus [2Karami, Soroush; Ilia, Panagiotis; Solomos, Konstantinos; Polakis, Jason (2020): "Carnus: Exploring the Privacy Threats of Browser Extension Fingerprinting", in: Proceedings of the Network and Distributed System Security Symposium. (Link)], NDSS 2020 — four extension-fingerprinting vectors implemented and compared in one paper, with the per-vector yield printed side by side. The single best orientation to the detection problem.
• Peeking through the Window [3Agarwal, Shubham; Fass, Aurore; Stock, Ben (2024): "Peeking through the window: Fingerprinting Browser Extensions through Page-Visible Execution Traces and Interactions", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)], CCS 2024 — the current fingerprinting vector: execution traces, the global JavaScript namespace and storage side effects. Read it as the answer to “is extension fingerprinting solved by MV3?”
• Trends and Lessons from Three Years Fighting Malicious Extensions [4Jagpal, Nav; Dingle, Eric; Gravel, Jean-Philippe; Mavrommatis, Panayiotis; Provos, Niels; Rajab, Moheeb Abu; Thomas, Kurt (2015): "Trends and Lessons from Three Years Fighting Malicious Extensions", in: Proceedings of the USENIX Security Symposium. (Link)], USENIX Security 2015 — the only paper in this corpus written from inside the store, with submission-time data no outside crawl can reproduce. Old, and irreplaceable.
• Privacy vs. Profit [5Lukić, Karlo; Papadopoulos, Lazaros (2026): "Privacy vs. Profit: The Impact of Google's Manifest Version 3 (MV3) Update on Ad Blocker Effectiveness", in: Proceedings on Privacy Enhancing Technologies. (Link)], PoPETs 2026 — the most recent measurement of what Manifest V3 did to ad blocking, and a useful corrective to the assumption that it broke it.
• “I have no idea how to make it safer” [6Agarwal, Shubham; Mrowczynski, Rafael; Hellenthal, Maria; Stock, Ben (2025): ""I have no idea how to make it safer": Studying Security and Privacy Mindsets of Browser Extension Developers", in: Proceedings of the USENIX Security Symposium. (Link)], USENIX Security 2025 — twenty-one extension developers, interviewed with coding tasks. Read it before you write a “developers should” sentence.
• Then the vendor documentation, because no paper is current on Manifest V3. Every external figure below was fetched on 2026-09-02.

The population is defined by a rule written before the first count, and by a hand verdict on every candidate; both are in scripts/ext_fold.mjs and the reasoning is on browser_extensions. A paper is in scope if it produces a reported finding about extensions — their code, their store listings, their permissions, their effect on a page, the set a user has installed, or the people who write and use them. A paper that only ships an extension is out.

68 papers are in scope — 1.2% of the 5,859-paper corpus. In absolute terms the topic has not grown much (9 papers in 2010–2013, 14 in 2014–2017, 19 in 2018–2021, 15 in 2022–2024, 11 in the provisional 2025–2026 slice) and as a share of a corpus that quadrupled it has shrunk: 1.8%, 1.8%, 1.3%, 0.8%, 0.9%.

It is a USENIX Security topic: 24 of the 68 are there (35.3%) against USENIX's 24.1% share of the corpus as a whole, and 12 each at IEEE S&P and TheWebConf, 8 at CCS, 6 at NDSS, 5 at PoPETs and 1 at IMC — which is 1.5% of the in-scope papers against IMC's 10.9% of the corpus. If you are used to reading IMC for measurement papers, this is not where this literature is.

(* 2025–2026 is provisional: CCS and IMC 2026 have not been held and IEEE S&P and TheWebConf 2026 are incompletely selected. See corpus.)

Two rows are worth staring at. Over-privilege was a 2010–2013 question and stopped: three of its four papers are from before 2014 and the fourth, TKPERM, is from 2020. Nothing since asks whether extensions request more permission than they use. The last row is one paper — [7Snyder, Peter; Ansari, Lara; Taylor, Cynthia; Kanich, Chris (2016): "Browser Feature Usage on the Modern Web", in: Proceedings of the ACM Internet Measurement Conference. (DOI)], IMC 2016 — and it is the only one that treats an installed extension as a confounder of the measurement rather than as its subject. That is a gap, not a consensus.

The asymmetry is the practical point. Firefox gives you a research API and exact numbers; Chrome gives you a sitemap and rounded ones. A study that needs install counts as a weight has better data on the smaller store, and [3Agarwal, Shubham; Fass, Aurore; Stock, Ben (2024): "Peeking through the window: Fingerprinting Browser Extensions through Page-Visible Execution Traces and Interactions", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)] says so in its own text: the Chrome Web Store “provides only inaccurate numbers for popular extensions (e.g., 1,000+)”, which is why its user-reach figures are lower bounds.

Mozilla has since added something Chrome has no equivalent of: a data_collection_permissions manifest key, surfaced on the API as current_version.file.data_collection_permissions. It is a machine-readable declaration of what the add-on collects. Do not assume it is populated. Measured on 2026-09-02 over the 400 most-installed listed Firefox extensions: 78.5% declared nothing (an empty array), 15.8% declared [“none”], and 5.8% named at least one data category. It is a real signal and it is currently a signal about 5.8% of the catalogue.

ext_corpus.py

#!/usr/bin/env python3
"""Build a browser-extension corpus from the two stores that let you.
 
Neither store gives you a research API. What they give you is:
 
  Chrome Web Store   an XML sitemap of item detail pages, and an undocumented
                     CRX endpoint that still serves the packed extension.
  Firefox AMO        a real, paginated, public JSON API.
 
Three things this gets right that a naive scraper does not, each of which
silently corrupts a corpus:
 
  1. ``/detail/<id>`` answers **HTTP 200 for an id that does not exist**. The
     store is a single-page app and renders a generic shell. Existence has to be
     read out of the <title>: a live item is "<name> - Chrome Web Store", a
     missing one is exactly "Chrome Web Store". A status-code check silently
     admits every delisted extension in your seed list.
  2. The CRX endpoint returns **204 No Content**, not an error, when
     ``prodversion`` is not a plausible four-part Chrome version. Tutorials pass
     "120.0"; that produces an empty corpus that looks like a network problem.
  3. The sitemap enumerates **items**, not extensions: themes are in it too, and
     so are ids whose detail page no longer resolves. Counting <loc> lines and
     calling the result "the number of Chrome extensions" is wrong by about a
     quarter, in the direction that flatters the number.
 
Stdlib only. Rate-limited by default, because the point is a reproducible
corpus, not a fast one.
 
    python3 ext_corpus.py --self-test
    python3 ext_corpus.py --sitemap-count
    python3 ext_corpus.py --exists ddkjiahejlhfcafbddmgiahcphecmpfh
    python3 ext_corpus.py --crx ddkjiahejlhfcafbddmgiahcphecmpfh -o /tmp/ubol.crx
    python3 ext_corpus.py --amo-count
"""
import argparse
import gzip
import io
import json
import re
import sys
import time
import urllib.error
import urllib.request
 
UA = ("Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) "
      "Chrome/140.0.0.0 Safari/537.36")
# A four-part version from a real Chrome release train. A two-part string makes
# the CRX endpoint answer 204 with an empty body.
PRODVERSION = "140.0.7339.80"
SITEMAP = "https://chromewebstore.google.com/sitemap"
CRX = ("https://clients2.google.com/service/update2/crx"
       "?response=redirect&os=linux&arch=x86-64&os_arch=x86_64&nacl_arch=x86-64"
       "&prod=chromiumcrx&prodchannel=unknown&prodversion={pv}"
       "&acceptformat=crx2,crx3&x=id%3D{id}%26uc")
AMO = "https://addons.mozilla.org/api/v5/addons/search/?app=firefox&type=extension&page={p}"
 
ID_RE = re.compile(r"^[a-p]{32}$")
TITLE_RE = re.compile(rb"<title>([^<]*)</title>", re.I)
 
 
def fetch(url, timeout=40):
    """Return (status, body). A 204 comes back as (204, b'') rather than raising."""
    req = urllib.request.Request(url, headers={
        "User-Agent": UA,
        "Accept-Encoding": "gzip",
        "Cookie": "CONSENT=YES+",
    })
    try:
        with urllib.request.urlopen(req, timeout=timeout) as r:
            body = r.read()
            if r.headers.get("Content-Encoding") == "gzip":
                body = gzip.decompress(body)
            return r.status, body
    except urllib.error.HTTPError as e:
        return e.code, e.read()
 
 
def sitemap_ids(pause=0.3):
    """Every item id the Chrome Web Store sitemap lists. Yields (shard, id)."""
    status, body = fetch(SITEMAP)
    if status != 200:
        raise SystemExit(f"sitemap index returned HTTP {status}")
    shards = re.findall(rb"<loc>([^<]+)</loc>", body)
    if not shards:
        raise SystemExit("sitemap index carried no <loc> entries — the format changed")
    for shard_url in shards:
        u = shard_url.decode()
        st, b = fetch(u)
        if st != 200:
            print(f"  WARN shard {u} returned HTTP {st}", file=sys.stderr)
            continue
        for loc in re.findall(rb"<loc>([^<]+)</loc>", b):
            m = re.search(r"/detail/(?:[^/]+/)?([a-p]{32})$", loc.decode())
            if m:
                yield u, m.group(1)
            else:
                print(f"  WARN unparsed sitemap URL: {loc.decode()[:100]}", file=sys.stderr)
        time.sleep(pause)
 
 
def item_exists(ext_id):
    """True iff the Chrome Web Store has a live detail page for this id.
 
    NOT a status-code check: /detail/<nonexistent> is HTTP 200.
    """
    if not ID_RE.match(ext_id):
        raise ValueError(f"not a Chrome extension id: {ext_id!r}")
    status, body = fetch(f"https://chromewebstore.google.com/detail/{ext_id}")
    if status != 200:
        return False
    m = TITLE_RE.search(body)
    if not m:
        return False
    title = m.group(1).decode("utf8", "replace").strip()
    return title != "Chrome Web Store" and title.endswith("Chrome Web Store")
 
 
def download_crx(ext_id, prodversion=PRODVERSION):
    """Bytes of the packed extension, or None. Verifies the Cr24 magic number."""
    status, body = fetch(CRX.format(pv=prodversion, id=ext_id))
    if status == 204:
        raise RuntimeError(
            f"{ext_id}: HTTP 204 with an empty body. This is what the endpoint "
            f"returns for an implausible prodversion ({prodversion!r}) as well as "
            f"for an id it will not serve — the two are indistinguishable here.")
    if status != 200:
        return None
    if body[:4] != b"Cr24":
        raise RuntimeError(f"{ext_id}: served {len(body)} bytes that are not a CRX "
                           f"(magic {body[:4]!r})")
    return body
 
 
def amo_count():
    """(count, first page of results) from Firefox AMO's public API."""
    status, body = fetch(AMO.format(p=1))
    if status != 200:
        raise SystemExit(f"AMO API returned HTTP {status}")
    d = json.loads(body)
    return d["count"], d["results"]
 
 
def self_test():
    """Three cases from the real store. All three must hold or the guard is vacuous.
 
    A test that only checks the positive case passes even when item_exists()
    is replaced by `return True`.
    """
    cases = [
        ("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", False, "a fabricated id"),
        ("cjpalhdlnbpafiamejdnhcphjbkeiagm", False,
         "uBlock Origin: a Manifest V2 extension, removed from the store 2026-08-31"),
        ("ddkjiahejlhfcafbddmgiahcphecmpfh", True, "uBlock Origin Lite (MV3)"),
    ]
    ok = True
    for ext_id, want, why in cases:
        got = item_exists(ext_id)
        flag = "ok  " if got == want else "FAIL"
        if got != want:
            ok = False
        print(f"{flag} item_exists({ext_id[:8]}...) = {got}, expected {want}  # {why}")
    blob = download_crx("ddkjiahejlhfcafbddmgiahcphecmpfh")
    print(f"ok   download_crx(uBOL) -> {len(blob)} bytes, magic {blob[:4].decode()}")
    try:
        download_crx("ddkjiahejlhfcafbddmgiahcphecmpfh", prodversion="120.0")
        print("FAIL a two-part prodversion should have raised")
        ok = False
    except RuntimeError as e:
        print(f"ok   a two-part prodversion raises: {str(e)[:60]}...")
    n, results = amo_count()
    print(f"ok   AMO reports {n} listed Firefox extensions; first result "
          f"{results[0]['slug']!r} with {results[0]['average_daily_users']} daily users")
    print("SELF-TEST", "PASSED" if ok else "FAILED")
    return 0 if ok else 1
 
 
def main():
    ap = argparse.ArgumentParser(description=__doc__,
                                 formatter_class=argparse.RawDescriptionHelpFormatter)
    ap.add_argument("--self-test", action="store_true")
    ap.add_argument("--sitemap-count", action="store_true")
    ap.add_argument("--sitemap-ids", metavar="FILE")
    ap.add_argument("--exists", metavar="ID")
    ap.add_argument("--crx", metavar="ID")
    ap.add_argument("-o", "--out", metavar="FILE")
    ap.add_argument("--amo-count", action="store_true")
    a = ap.parse_args()
 
    if a.self_test:
        return self_test()
    if a.sitemap_count or a.sitemap_ids:
        ids, per_shard = set(), {}
        for shard, ext_id in sitemap_ids():
            ids.add(ext_id)
            per_shard[shard] = per_shard.get(shard, 0) + 1
        print(f"shards: {len(per_shard)}")
        print(f"item ids, with duplicates: {sum(per_shard.values())}")
        print(f"distinct item ids:         {len(ids)}")
        print("NOTE: these are STORE ITEMS. Themes are in here too, and so are "
              "ids with no live detail page. Sample with item_exists() before "
              "calling any of this a count of extensions.")
        if a.sitemap_ids:
            with open(a.sitemap_ids, "w") as f:
                f.write("\n".join(sorted(ids)) + "\n")
        return 0
    if a.exists:
        print(item_exists(a.exists))
        return 0
    if a.crx:
        blob = download_crx(a.crx)
        if blob is None:
            print("not served", file=sys.stderr)
            return 1
        if a.out:
            open(a.out, "wb").write(blob)
            print(f"{len(blob)} bytes -> {a.out}")
        else:
            print(f"{len(blob)} bytes, magic {blob[:4].decode()}")
        return 0
    if a.amo_count:
        n, results = amo_count()
        print(f"AMO listed Firefox extensions: {n}")
        for r in results[:5]:
            f = r["current_version"]["file"]
            print(f"  {r['slug']:<28} {r['average_daily_users']:>10} daily users  "
                  f"permissions={len(f['permissions'])} "
                  f"data_collection={f.get('data_collection_permissions')}")
        return 0
    ap.print_help()
    return 0
 
 
if __name__ == "__main__":
    sys.exit(main())

The self-test is the part to copy rather than the fetching. It asserts three cases, not one:

ok   item_exists(aaaaaaaa...) = False, expected False  # a fabricated id
ok   item_exists(cjpalhdl...) = False, expected False  # uBlock Origin: a Manifest V2 extension, removed from the store 2026-08-31
ok   item_exists(ddkjiahe...) = True, expected True  # uBlock Origin Lite (MV3)
ok   download_crx(uBOL) -> 9665461 bytes, magic Cr24
ok   a two-part prodversion raises: ddkjiahejlhfcafbddmgiahcphecmpfh: HTTP 204 with an empty bod...
ok   AMO reports 99677 listed Firefox extensions; first result 'ublock-origin' with 10766677 daily users
SELF-TEST PASSED

Replacing the body of item_exists with return True makes the third line pass and the first two fail, so the test reports SELF-TEST FAILED. A one-case test of the form “the extension I know exists is found” passes on that mutant. The same applies to the prodversion case: without the negative case, a 204-swallowing bug is invisible.

Every in-scope paper that crawled a store states a size. Here is every Chrome-store extension corpus in the 68 with n ≥ 5,000, sorted by year. The rule is the size alone — the word the paper used for its own sampling is a column, not a filter, so nothing is quietly left out:

Nineteen of the 27 rows say exhaustive; three say nothing at all; three are explicitly top-N samples of the store rather than the store; one is purposive and one is a pre-existing dataset. That spread is itself the finding: “we crawled the Chrome Web Store” is a sentence with at least five different meanings in this literature.

Six of those rows are not what they look like, and none of the papers is wrong:

• 1,000,000 [9Thomas, Kurt; Bursztein, Elie; Grier, Chris; Ho, Grant; Jagpal, Nav; Kapravelos, Alexandros; McCoy, Damon; Nappa, Antonio; Paxson, Vern; Pearce, Paul; Provos, Niels; Rajab, Moheeb Abu (2015): "Ad Injection at Scale: Assessing Deceptive Advertisement Modifications", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)] is not a store size. It is the union of a web crawl, Safe Browsing and the store over three and a half years, and its own headline is that 50,870 of those were ad injectors.
• 501,349 [10Laperdrix, Pierre; Starov, Oleksii; Chen, Quan; Kapravelos, Alexandros; Nikiforakis, Nick (2021): "Fingerprinting in Style: Detecting Browser Extensions via Injected Style Sheets", in: Proceedings of the USENIX Security Symposium. (Link)] is every version ever seen from mid-2014 to mid-2019. The same paper's snapshot figure is 116,485.
• 113,099 [1Xie, Qinge; Kasi Murali, Manoj Vignesh; Pearce, Paul; Li, Frank (2024): "Arcanum: Detecting and Evaluating the Privacy Risks of Browser Extensions on Web Pages and Web Content", in: Proceedings of the USENIX Security Symposium. (Link)] is the functional subset: the paper says it excluded items that are listed as extensions but are Chrome OS apps.
• 10,620 / 10,000 / 10,000 [8Sanchez-Rola, Iskander; Santos, Igor; Balzarotti, Davide (2017): "Extension Breakdown: Security Analysis of Browsers Extension Resources Control Policies", in: Proceedings of the USENIX Security Symposium. (Link)] [11Starov, Oleksii; Nikiforakis, Nick (2017): "Extended Tracking Powers: Measuring the Privacy Diffusion Enabled by Browser Extensions", in: Proceedings of the ACM Web Conference. (DOI)] [12Starov, Oleksii; Nikiforakis, Nick (2017): "XHOUND: Quantifying the Fingerprintability of Browser Extensions", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)] are top-N samples of the store, not the store. They are in the table because the rule is mechanical; they are not store sizes.

Which is why 2022's 186,434 and 2024's 113,099 are not evidence that the store shrank. Name the unit — snapshot, cumulative, functional subset, or top-N — before you compare two figures, and expect a factor of two either way if you do not.

Only 51.4% of the 74 extension-corpus tuples across the 38 papers that built one state a snapshot date at all — 21 of those 38 papers, 55.3%. The corpus-wide reporting rate for population.listVersion is 43.0%, but that is computed over the 5,712 papers that drew any study population, so it is a baseline, not a comparison: the two figures are over different populations and the difference between them is not a measured effect.

For a figure for today: Google publishes none. The sitemap gives 356,984 item IDs on 2026-09-02. Downloading and unpacking the CRX for a deterministic 200-item sample of them puts the composition at 146 extensions, 44 themes and 8 legacy Chrome apps out of 198 served — 73.7% extensions — so the store lists on the order of 260,000 extensions, with an interval a 200-item sample can only bound loosely. Third-party trackers publish confident numbers that disagree with each other by more than a factor of two; none of them is Google, none states its unit, and the most-cited of them is behind a bot wall that will not answer an automated fetch. Firefox is the one you can quote exactly: 99,677 listed extensions.

The pattern to notice: the released artefacts are the tools, not the corpora. All four research artefacts above are code; exactly one of them also ships a dataset, and that dataset is the 4,446 extensions the paper found fingerprintable rather than the 116,485 it analysed. If your study needs the same extensions a 2019 paper studied, you will be reconstructing them from IDs, and the store will have deleted some.

This is the part of the topic where the answer has changed, so date everything.

And a caution on the other side of the same coin: an extension whose purpose is to defeat fingerprinting is itself a fingerprint. [20Nguyen, Hoang Dai; Vadrevu, Phani (2025): "Breaking the Shield: Analyzing and Attacking Canvas Fingerprinting Defenses in the Wild", in: Proceedings of the ACM Web Conference. (DOI)] analysed the canvas defences of “18 browser extensions in Chrome and Firefox” and recovered the original canvas from nine of the randomising ones; [18El Hajj Chehade, Saiid; Stock, Ben; Troncoso, Carmela (2025): "Double-Edged Shield: On the Fingerprintability of Customized Ad Blockers", in: Proceedings of the USENIX Security Symposium. (Link)] fingerprints the filter list rather than the blocker. Both results say the same thing: installing a countermeasure moves you into a smaller anonymity set, and a study that treats “has a privacy extension” as protection rather than as an attribute has the sign wrong.

Chrome 130 (October 2024) added use_dynamic_url to web_accessible_resources. The documentation is exact: “If true, only allow resources to be accessed through a dynamic ID. A dynamic ID is generated per session. That means it is regenerated when the browser restarts or the extension reloads.”⁶⁾

It is opt-in, so whether the vector is closed is a measurement, not a documentation question, and there is one published measurement of it. [3Agarwal, Shubham; Fass, Aurore; Stock, Ben (2024): "Peeking through the window: Fingerprinting Browser Extensions through Page-Visible Execution Traces and Interactions", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)], working on a January 2024 snapshot, reports that “we only observe 109 fingerprintable extensions using this option” — 109 out of the 3,398 behaviourally active extensions in its own set. It also notes that its vectors would work regardless.

Two years on, over a different population — a deterministic sample of the sitemap on 2026-09-02, downloading the CRX and parsing manifest.json:

population: 356984 sitemap ids; every-1784th deterministic sample of 200

CRX served: 198   204 refused: 2   not served: 0   unparsed: 0   network errors: 0
manifest_version histogram: {3: 180, 2: 17, None: 1}
item kind, from the manifest: extension=146 theme=44 app=8
  -> extensions are 73.7% of the served items
of the 146 extensions, declare web_accessible_resources: 46  (31.5%)
  use_dynamic_url on EVERY entry: 0
  use_dynamic_url on SOME entries: 0
  no use_dynamic_url anywhere:     46   <- still probeable by extension id

Manifest V2 items still served by the CRX endpoint: 17
  of which the store detail page still resolves: 16
  by kind: {'extension': 0, 'theme': 9, 'app': 8}
  -> manifest_version 2 in the store today is a THEME or a legacy Chrome APP,
     not a surviving Manifest V2 extension.

The vector is open, and the two measurements agree: the mitigation exists and is almost unused. Treat “MV3 killed extension enumeration” as false until somebody re-measures it at store scale; sandbox/war_dynamic_url.py is committed so that they can, and it prints its sample size.

There is a plausible reason, and it is also measured. [6Agarwal, Shubham; Mrowczynski, Rafael; Hellenthal, Maria; Stock, Ben (2025): ""I have no idea how to make it safer": Studying Security and Privacy Mindsets of Browser Extension Developers", in: Proceedings of the USENIX Security Symposium. (Link)] put the key in front of extension developers and found that “15/17 participants did not comment at all on specific S&P threats and related concepts”, with two of them asking what use_dynamic_url was. An opt-in mitigation that its intended adopters have not heard of is not a mitigation yet.

Two consequences for a study design. If you are building a fingerprinting result, WAR probing is a Chrome-only, opt-out-able vector and your Firefox arm needs a behavioural technique or it will read zero. If you are building a defence or a prevalence result, the vectors that no platform change touches — DOM, styles, user actions, execution traces — are the ones to key on, and [3Agarwal, Shubham; Fass, Aurore; Stock, Ben (2024): "Peeking through the window: Fingerprinting Browser Extensions through Page-Visible Execution Traces and Interactions", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)] is the current baseline to beat.

The method ladder, dated. Each rung is still used; the top two are what a 2026 paper is expected to do.

Two 2020s additions to the leakage question are worth naming because they are new objects, not new methods. [34Ferreira Torres, Christof; Willi, Fiona; Shinde, Shweta (2023): "Is Your Wallet Snitching On You? An Analysis on the Privacy Implications of Web3", in: 32nd USENIX Security Symposium (USENIX Security 23). (Link)] turned the question around and measured the web: 1,325 of the top 100K sites run scripts that probe whether the visitor has a wallet extension installed, which makes extension detection a thing you can measure in the wild rather than only in a lab. And [35Vekaria, Yash; Canino, Aurelio Loris; Levitsky, Jonathan; Ciechonski, Alex; Callejo, Patricia; Mandalari, Anna Maria; Shafiq, Zubair (2025): "Big Help or Big Brother? Auditing Tracking, Profiling, and Personalization in Generative AI Assistants", in: Proceedings of the USENIX Security Symposium. (Link)] audited generative-AI assistant extensions, finding that 8 of 9 generate their responses server-side — so the extension is a pipe to a third party by design, and the taint-tracking methods above stop at the network boundary.

Two base rates worth carrying in your head, because a new detector will be compared against them: 2.13% of extensions leak privacy-sensitive information by hybrid taint [13Chen, Quan; Kapravelos, Alexandros (2018): "Mystique: Uncovering Information Leakage from Browser Extensions", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)], and 2.68% propagate sensitive data from a real site to a sink [1Xie, Qinge; Kasi Murali, Manoj Vignesh; Pearce, Paul; Li, Frank (2024): "Arcanum: Detecting and Evaluating the Privacy Risks of Browser Extensions on Web Pages and Web Content", in: Proceedings of the USENIX Security Symposium. (Link)]. They are six years and two methods apart and they agree to within half a percentage point. A method that reports 30% is reporting something else, and should say what.

The vulnerability papers are a single fourteen-year argument about one design: extensions run privileged code next to hostile page content, and the boundary leaks. [36Djeric, Vladan; Goel, Ashvin (2010): "Securing Script-Based Extensibility in Web Browsers", in: Proceedings of the USENIX Security Symposium. (Link)] 2010 and VEX [22Bandhakavi, Sruthi; King, Samuel T.; Madhusudan, P.; Winslett, Marianne (2010): "VEX: Vetting Browser Extensions for Security Vulnerabilities", in: Proceedings of the USENIX Security Symposium. (Link)] 2010 attacked the old Firefox XPCOM model; [21Carlini, Nicholas; Felt, Adrienne Porter; Wagner, David (2012): "An Evaluation of the Google Chrome Extension Security Architecture", in: Proceedings of the USENIX Security Symposium. (Link)] 2012 evaluated Chrome's replacement — isolated worlds, privilege separation, a permission system — and found 70 vulnerabilities in 40 of 100 reviewed extensions anyway. [37Akhawe, Devdatta; Saxena, Prateek; Song, Dawn (2012): "Privilege Separation in HTML5 Applications", in: Proceedings of the USENIX Security Symposium. (Link)] 2012 showed why: in half the extensions they analysed, fewer than 5% of functions need any privilege at all, so the privileged surface is almost entirely gratuitous. Eleven years later [38Kim, Young Min; Lee, Byoungyoung (2023): "Extending a Hand to Attackers: Browser Privilege Escalation Attacks via Extensions", in: Proceedings of the USENIX Security Symposium. (Link)] found 59 vulnerabilities in 40 extensions in the same architecture, caused by the same requirement being violated. EmPoWeb [25Somé, Dolière Francis (2019): "EmPoWeb: Empowering Web Applications with Browser Extensions", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)] is the sharpest version: 197 extensions whose message listeners let an arbitrary web page borrow the extension's privileges.

A different failure of the same boundary is that extensions rewrite the security headers the server sent. [39Agarwal, Shubham (2022): "Helping or Hindering?: How Browser Extensions Undermine Security", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)] analysed three Chrome Web Store snapshots and found 1,129 extensions that interfere with security-related request or response headers, 205 of which “strip the entire CSP header”. If your measurement reads a header out of the browser rather than off the wire, an extension in the profile can have changed it.

The password-manager strand is the same problem with a concrete asset. [40Anliker, Claudio; Lain, Daniele; Capkun, Srdjan (2025): "Phishing Attacks against Password Manager Browser Extensions", in: Proceedings of the USENIX Security Symposium. (Link)] imitated the extension's own UI inside the page and reports “a high average attack success rate of 31.25%” across the password managers it tested, with a peak of 58.82% for one of them — an attack that exists because the extension draws its interface in a context the page controls.

Over-privilege has stalled. The corpus's permission papers are [23Guha, Arjun; Fredrikson, Matthew; Livshits, Benjamin; Swamy, Nikhil (2011): "Verified Security for Browser Extensions", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)] 2011 (“1,139 popular Chrome extensions”; nearly a third request full privileges over arbitrarily many sites), [41Chia, Pern Hui; Yamamoto, Yusuke; Asokan, N. (2012): "Is this app safe?: a large scale study on application permissions and risk signals", in: Proceedings of the ACM Web Conference. (DOI)] 2012 (5,943 extensions alongside Android and Facebook apps), [42Dong, Xinshu; Chen, Zhaofeng; Siadati, Hossein; Tople, Shruti; Saxena, Prateek; Liang, Zhenkai (2013): "Protecting sensitive web content from client-side vulnerabilities with CRYPTONS", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)] 2013 (23 of the top 30 Chrome extensions request access to Gmail) and TKPERM [43Shezan, Faysal Hossain; Cheng, Kaiming; Zhang, Zhen; Cao, Yinzhi; Tian, Yuan (2020): "TKPERM: Cross-platform Permission Knowledge Transfer to Detect Overprivileged Third-party Applications", in: Proceedings of the Network and Distributed System Security Symposium. (Link)] 2020. Nothing since. Manifest V3 changed the permission model — host permissions became optional and revocable at runtime — and no paper in this corpus has measured what that did.

Eleven of the 68 papers ask this, and they are the most methodologically varied group on the page, because “protect” has to be operationalised differently every time.

• Against a stated policy. [44Franken, Gertjan; Van Goethem, Tom; Joosen, Wouter (2018): "Who Left Open the Cookie Jar? A Comprehensive Evaluation of Third-Party Cookie Policies", in: Proceedings of the USENIX Security Symposium. (Link)] generated test cases for every mechanism a browser has to issue a request and ran them against “7 browsers and 46 browser extensions”; the imposed policy could be bypassed in virtually every one. This is the template: build the adversarial test suite first, then run the tools through it.
• Against a live attack. [45Ukani, Alisha; Haddadi, Hamed; Snoeren, Alex C.; Snyder, Peter (2025): "Local Frames: Exploiting Inherited Origins to Bypass Content Blockers", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security, pp. 1349-1363. (DOI)] found that content blockers do not apply their rules inside frames that inherit their parent's origin, and disclosed “all 19 vulnerabilities found to the six affected parties”. Four of the six have patched.
• On cost rather than efficacy. [46Borgolte, Kevin; Feamster, Nick (2020): "Understanding the Performance Costs and Benefits of Privacy-focused Browser Extensions", in: Proceedings of the ACM Web Conference. (DOI)] measured page-load time, bytes, CPU and memory for eight privacy extensions and found they perform similarly to or better than no extension at all — the counter-intuitive result that a blocking tool usually saves more work than it costs.
• On a specific automated behaviour. [47Demir, Nurullah; Urban, Tobias; Pohlmann, Norbert; Wressnegger, Christian (2024): "A Large-Scale Study of Cookie Banner Interaction Tools and their Impact on Users' Privacy", in: Proceedings on Privacy Enhancing Technologies, pp. 5-20. (DOI)] configured six cookie-banner interaction tools to express different choices across a stratified Tranco sample and measured what actually landed in the cookie jar. Its finding that the tools interacted with only about 65% of banners is the kind of number you need before you use one as a crawl treatment (Consent).
• On the defence's own mechanism. [20Nguyen, Hoang Dai; Vadrevu, Phani (2025): "Breaking the Shield: Analyzing and Attacking Canvas Fingerprinting Defenses in the Wild", in: Proceedings of the ACM Web Conference. (DOI)] and [18El Hajj Chehade, Saiid; Stock, Ben; Troncoso, Carmela (2025): "Double-Edged Shield: On the Fingerprintability of Customized Ad Blockers", in: Proceedings of the USENIX Security Symposium. (Link)], above.

The through-line: none of these treats “the extension is installed” as the outcome. Each defines a concrete thing the extension is supposed to prevent and then tries to make it happen anyway. A study that reports “we installed uBlock Origin” and moves on has skipped the measurement.

Seven of the 68 papers study the humans rather than the code, and all but one are from 2021 onwards. They are worth knowing about because they are the only papers here that ask what the numbers above mean to anyone.

• [48Nisenoff, Alexandra; Borem, Arthur; Pickering, Madison; Nakanishi, Grant; Thumpasery, Maya; Ur, Blase (2023): "Defining "Broken": User Experiences and Remediation Tactics When Ad-Blocking or Tracking-Protection Tools Break a Website's User Experience", in: Proceedings of the USENIX Security Symposium. (Link)], USENIX Security 2023, scraped 18,932 reviews and issue reports for ten blocking tools from the Chrome, Firefox and Mac extension stores and coded the breakage users describe. If your study asks “does this blocker break sites”, this is the taxonomy to code against rather than inventing one.
• [49Schöni, Lorin; Kubicek, Karel; Zimmermann, Verena (2024): "Block Cookies, Not Websites: Analysing Mental Models and Usability of the Privacy-Preserving Browser Extension CookieBlock", in: Proceedings on Privacy Enhancing Technologies, pp. 192-216. (DOI)], PoPETs 2024, put 42 participants in front of a specific privacy extension with eye-tracking. It is the rare paper that measures whether the tool a security paper proposed is usable by the people it was proposed for.
• [6Agarwal, Shubham; Mrowczynski, Rafael; Hellenthal, Maria; Stock, Ben (2025): ""I have no idea how to make it safer": Studying Security and Privacy Mindsets of Browser Extension Developers", in: Proceedings of the USENIX Security Symposium. (Link)], USENIX Security 2025, interviewed 21 extension developers with coding tasks. The finding a measurement paper should absorb: the vulnerabilities in the papers above are not carelessness, they are the documented API working as designed.

Store reviews are a data source here, and an unusual one: they are one of the few public per-extension signals that comes from users rather than from the vendor. [28Pantelaios, Nikolaos; Nikiforakis, Nick; Kapravelos, Alexandros (2020): "You've Changed: Detecting Malicious Browser Extensions through their Update Deltas", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)] used rating anomalies as the first stage of malicious-extension detection for the same reason.

Only 11 of the 68 in-scope papers name Manifest V3 at all — the earliest in 2020, and seven of the eleven from 2024 onwards. Every result older than those is a result about Manifest V2, and that platform no longer exists in Chrome.

The other browsers did not follow. Firefox supports both, and keeps blocking webRequest: MDN documents webRequestBlocking as an ordinary API permission with no Manifest V3 restriction⁸⁾. Microsoft Edge has not set a date: its own policy documentation says “the timeline of the migration hasn't been established”⁹⁾. So a cross-browser extension study in 2026 is comparing two different extension platforms, and has to say which.

If your instrument is an extension — and for 92 of the 218 candidate papers it was — three MV3 properties will bite:

• The background page is a service worker and it dies. Chrome terminates it “after 30 seconds of inactivity” and when “a single request, such as an event or API call, takes longer than 5 minutes to process”; and “any global variables you set will be lost if the service worker shuts down”¹⁰⁾. An in-memory request log is a bug.
• You can still observe requests; you cannot block them. “Aside from webRequestBlocking, the webRequest API is unchanged and available for normal use”, and blocking “is only available to policy installed extensions”. Passive instrumentation survives MV3 unchanged. A blocking treatment arm does not, unless you install the extension by enterprise policy.
• Rule-based blocking has hard numeric ceilings. declarativeNetRequest as documented on 2026-09-02: at most 100 static rulesets, of which 50 may be enabled; 30,000 guaranteed static rules and 30,000 dynamic rules; 5,000 session rules, 5,000 “unsafe” dynamic and 5,000 “unsafe” session rules; 1,000 regular-expression rules, each under 2 KB compiled; getMatchedRules callable 20 times per quota interval¹¹⁾. For scale: EasyList on 2026-09-02 (version 202609020241) is 80,470 non-comment lines¹²⁾ against a 30,000-rule guaranteed static allowance. That gap is the whole argument about MV3 and ad blocking, and the section below is the only measurement of it in this corpus.

The argument was that MV3 would cripple content blocking. The one measurement of it in this corpus, [5Lukić, Karlo; Papadopoulos, Lazaros (2026): "Privacy vs. Profit: The Impact of Google's Manifest Version 3 (MV3) Update on Ad Blocker Effectiveness", in: Proceedings on Privacy Enhancing Technologies. (Link)], PoPETs 2026, ran MV3 and MV2 ad blockers over the same sites in July 2025 and found no significant difference in ads blocked — means of 1.42 and 1.46 — while MV3 blocked more trackers per site than MV2 and produced no substantial difference in breakage. The one clear MV3 effect it found was cosmetic: placeholder frames left where an ad was removed, in 21% of cases against 0% under MV2.

That is one paper, on a sample of a few hundred sites, and it measures the blockers that survived the migration rather than the ones that did not. But it is the current evidence, and it points the other way from the consensus. If you are going to assert that MV3 broke ad blocking, measure it.

The corpus has exactly one paper on this: [7Snyder, Peter; Ansari, Lara; Taylor, Cynthia; Kanich, Chris (2016): "Browser Feature Usage on the Modern Web", in: Proceedings of the ACM Internet Measurement Conference. (DOI)], IMC 2016, which instrumented a browser and re-ran its feature census with AdBlock Plus and Ghostery installed. Its result — a set of “approximately 10%” of browser features “which ad and tracking blockers prevent from executing more than 90% of the time” — is the only estimate in this corpus of how much an installed extension changes what a crawl sees.

That should worry you more than it seems to worry the field, because:

• a measurement extension is itself detectable by every vector in the table above, so it is a crawler-detection signal (Crawler detection);
• a blocking extension in the profile is an uncontrolled treatment on every request-level measurement you make (Requests);
• and [44Franken, Gertjan; Van Goethem, Tom; Joosen, Wouter (2018): "Who Left Open the Cookie Jar? A Comprehensive Evaluation of Third-Party Cookie Policies", in: Proceedings of the USENIX Security Symposium. (Link)] showed that the extension policies themselves can be bypassed — “an analysis of 7 browsers and 46 browser extensions”, with the policy bypassable in virtually every one — so “we ran with uBlock Origin” is not a statement about what was actually blocked.

Report the extension set, with versions, the way you report the browser version. The extraction schema has no field for it, so this page cannot tell you how often anyone does — which is itself the answer: it is not a thing the field records.

• “Extensions in the store” is at least four different numbers. Snapshot, cumulative-over-time, functional-subset, and items-including-themes. Three published corpora in the table above are each a different one of these.
• Install counts are rounded in Chrome and exact in Firefox. A user-weighted result computed from Chrome's displayed counts is a lower bound, and [3Agarwal, Shubham; Fass, Aurore; Stock, Ben (2024): "Peeking through the window: Fingerprinting Browser Extensions through Page-Visible Execution Traces and Interactions", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)] says so about its own 169M-user figure.
• HTTP 200 from a store detail page is not existence. See the box at the top.
• The CRX endpoint's 204 is indistinguishable from a refusal. Fail loudly on it; do not treat an empty body as “no such extension”.
• A delisted extension is still installed on millions of machines. The store is the supply, not the population. Chrome's own timeline says removed MV2 extensions “will remain installed”. A store-only study measures availability, not exposure.
• The extension you download is not the extension the user runs. Update deltas are where malice arrives [28Pantelaios, Nikolaos; Nikiforakis, Nick; Kapravelos, Alexandros (2020): "You've Changed: Detecting Malicious Browser Extensions through their Update Deltas", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)], and the December 2024 Cyberhaven compromise is the worked example: a phishing attack on a developer's Web Store credentials published a malicious version of a legitimate extension, live for about 25 hours¹³⁾. A single-snapshot corpus cannot see this.
• Extension IDs are stable, and they are derived, not assigned. Chromium's id_util.cc computes them as the “First 16 bytes of SHA256 hashed public key”, hex-encoded and mapped from 0–f onto a–p “to avoid ever having a completely numeric host”. So an ID persists across versions and across store removal, and it changes only if the developer rotates the signing key. Key on the ID, not on the name.
• Store policy is a variable too. The Chrome Web Store's 2026 policy update, enforced from 2026-08-01, requires that “any user data collected by an extension must now be strictly necessary to the extension's disclosed single purpose” and that “all data collection be prominently disclosed”¹⁴⁾. A disclosure-versus-behaviour study [31Bui, Duc; Tang, Brian; Shin, Kang G. (2023): "Detection of Inconsistencies in Privacy Practices of Browser Extensions", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)] run before and after that date is measuring two different rulebooks.
• Seven venues. Everything above about “the literature” is about CCS, IMC, NDSS, PoPETs, USENIX Security, TheWebConf and IEEE S&P. Extension work also appears at ACSAC, EuroS&P, ASIACCS, SOUPS and CODASPY, none of which is in this corpus. The clearest casualty is Sjösten et al., Discovering Browser Extensions via Web Accessible Resources, CODASPY 2017 — the paper that introduced WAR probing, which appears in the reference list of in-scope papers here and is not itself available to be counted.

• Requests — uBlock Origin as a classifier of requests, which is the other half of this topic.
• Filter lists — the lists the blocking extensions consume, and why “blocked implies tracker” is circular.
• Browser protection — the browser's own anti-tracking machinery, which is a different mechanism with a different failure mode.
• Fingerprinting — extension detection is one attribute among many; the unicity arithmetic lives there.
• Crawler detection — your measurement extension is fingerprintable by every vector on this page.
• Mobile and app measurement — the same store-crawling problem on a different platform: sampling frames, delisting churn, and what a store listing does and does not tell you about installs.
• Stateful stateless — an extension's effect only appears in a profile that persists.
• Ethics — downloading and executing a hundred thousand third-party programs is a decision with an ethics section.
• Provenance of this page's figures.

Corpus figures come from the 5,859-paper extraction over seven venues (CCS, IMC, NDSS, PoPETs, USENIX Security, TheWebConf, IEEE S&P), 2010–2026. Any claim about “the literature” here is a claim about those seven venues, and extension work is also published at ACSAC, EuroS&P, ASIACCS, SOUPS and CODASPY, which are absent. 2025 and 2026 venue-years are provisional — see corpus.

The 68-paper population is a candidate sweep plus a hand verdict on every one of 218 candidates, not a keyword count: a bare /browser extensions?/i fires on 535 papers. The rule was written before the first figure was computed, the report fails if the sweep and the hand map diverge in either direction, and widening the sweep to any extension artefact string adds 32 papers and zero in-scope ones. Every per-paper figure quoted above was checked against the paper's own text as a verbatim phrase (64 of 64 located, all of them in the de-columned rendering the extraction itself read).

All external figures were fetched on 2026-09-02 and are re-checkable with scripts/external_checks_browser_extensions.sh. The Chrome Web Store sitemap count, the item sample, the use_dynamic_url sample and the AMO data_collection_permissions measurement are original to this page; each is a single-day snapshot of a store that changes daily.

The full query log — every population and denominator, the report script and its unedited output, the hand verdicts, the quotes spot-checked, and the external sources verified or rejected — is at browser_extensions, including which review passes this page has had and which one it is still missing. Corpus-level caveats are on corpus.

[1]

Xie, Qinge; Kasi Murali, Manoj Vignesh; Pearce, Paul; Li, Frank (2024): "Arcanum: Detecting and Evaluating the Privacy Risks of Browser Extensions on Web Pages and Web Content", in: Proceedings of the USENIX Security Symposium. (Link)

[2]

Karami, Soroush; Ilia, Panagiotis; Solomos, Konstantinos; Polakis, Jason (2020): "Carnus: Exploring the Privacy Threats of Browser Extension Fingerprinting", in: Proceedings of the Network and Distributed System Security Symposium. (Link)

[3]

Agarwal, Shubham; Fass, Aurore; Stock, Ben (2024): "Peeking through the window: Fingerprinting Browser Extensions through Page-Visible Execution Traces and Interactions", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)

[4]

Jagpal, Nav; Dingle, Eric; Gravel, Jean-Philippe; Mavrommatis, Panayiotis; Provos, Niels; Rajab, Moheeb Abu; Thomas, Kurt (2015): "Trends and Lessons from Three Years Fighting Malicious Extensions", in: Proceedings of the USENIX Security Symposium. (Link)

[5]

Lukić, Karlo; Papadopoulos, Lazaros (2026): "Privacy vs. Profit: The Impact of Google's Manifest Version 3 (MV3) Update on Ad Blocker Effectiveness", in: Proceedings on Privacy Enhancing Technologies. (Link)

[6]

Agarwal, Shubham; Mrowczynski, Rafael; Hellenthal, Maria; Stock, Ben (2025): ""I have no idea how to make it safer": Studying Security and Privacy Mindsets of Browser Extension Developers", in: Proceedings of the USENIX Security Symposium. (Link)

[7]

Snyder, Peter; Ansari, Lara; Taylor, Cynthia; Kanich, Chris (2016): "Browser Feature Usage on the Modern Web", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[8]

Sanchez-Rola, Iskander; Santos, Igor; Balzarotti, Davide (2017): "Extension Breakdown: Security Analysis of Browsers Extension Resources Control Policies", in: Proceedings of the USENIX Security Symposium. (Link)

[9]

Thomas, Kurt; Bursztein, Elie; Grier, Chris; Ho, Grant; Jagpal, Nav; Kapravelos, Alexandros; McCoy, Damon; Nappa, Antonio; Paxson, Vern; Pearce, Paul; Provos, Niels; Rajab, Moheeb Abu (2015): "Ad Injection at Scale: Assessing Deceptive Advertisement Modifications", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)

[10]

Laperdrix, Pierre; Starov, Oleksii; Chen, Quan; Kapravelos, Alexandros; Nikiforakis, Nick (2021): "Fingerprinting in Style: Detecting Browser Extensions via Injected Style Sheets", in: Proceedings of the USENIX Security Symposium. (Link)

[11]

Starov, Oleksii; Nikiforakis, Nick (2017): "Extended Tracking Powers: Measuring the Privacy Diffusion Enabled by Browser Extensions", in: Proceedings of the ACM Web Conference. (DOI)

[12]

Starov, Oleksii; Nikiforakis, Nick (2017): "XHOUND: Quantifying the Fingerprintability of Browser Extensions", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)

[13]

Chen, Quan; Kapravelos, Alexandros (2018): "Mystique: Uncovering Information Leakage from Browser Extensions", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)

[14]

Trickel, Erik; Starov, Oleksii; Kapravelos, Alexandros; Nikiforakis, Nick; Doupé, Adam (2019): "Everyone is Different: Client-side Diversification for Defending Against Extension Fingerprinting", in: Proceedings of the USENIX Security Symposium. (Link)

[15]

Sjösten, Alexander; Van Acker, Steven; Picazo-Sanchez, Pablo; Sabelfeld, Andrei (2019): "Latex Gloves: Protecting Browser Extensions from Probing and Revelation Attacks", in: Proceedings of the Network and Distributed System Security Symposium. (Link)

[16]

Starov, Oleksii; Laperdrix, Pierre; Kapravelos, Alexandros; Nikiforakis, Nick (2019): "Unnecessarily Identifiable: Quantifying the fingerprintability of browser extensions due to bloat", in: Proceedings of the ACM Web Conference. (DOI)

[17]

Solomos, Konstantinos; Ilia, Panagiotis; Karami, Soroush; Nikiforakis, Nick; Polakis, Jason (2022): "The Dangers of Human Touch: Fingerprinting Browser Extensions through User Actions", in: Proceedings of the USENIX Security Symposium. (Link)

[18]

El Hajj Chehade, Saiid; Stock, Ben; Troncoso, Carmela (2025): "Double-Edged Shield: On the Fingerprintability of Customized Ad Blockers", in: Proceedings of the USENIX Security Symposium. (Link)

[19]

Trampert, Leon; Weber, Daniel; Gerlach, Lukas; Rossow, Christian; Schwarz, Michael (2025): "Cascading Spy Sheets: Exploiting the Complexity of Modern CSS for Email and Browser Fingerprinting", in: Proceedings of the Network and Distributed System Security Symposium. (Link)

[20]

Nguyen, Hoang Dai; Vadrevu, Phani (2025): "Breaking the Shield: Analyzing and Attacking Canvas Fingerprinting Defenses in the Wild", in: Proceedings of the ACM Web Conference. (DOI)

[21]

Carlini, Nicholas; Felt, Adrienne Porter; Wagner, David (2012): "An Evaluation of the Google Chrome Extension Security Architecture", in: Proceedings of the USENIX Security Symposium. (Link)

[22]

Bandhakavi, Sruthi; King, Samuel T.; Madhusudan, P.; Winslett, Marianne (2010): "VEX: Vetting Browser Extensions for Security Vulnerabilities", in: Proceedings of the USENIX Security Symposium. (Link)

[23]

Guha, Arjun; Fredrikson, Matthew; Livshits, Benjamin; Swamy, Nikhil (2011): "Verified Security for Browser Extensions", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)

[24]

Zhao, Rui; Yue, Chuan; Yi, Qing (2015): "Automatic Detection of Information Leakage Vulnerabilities in Browser Extensions", in: Proceedings of the ACM Web Conference. (DOI)

[25]

Somé, Dolière Francis (2019): "EmPoWeb: Empowering Web Applications with Browser Extensions", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)

[26]

Kapravelos, Alexandros; Grier, Chris; Chachra, Neha; Kruegel, Christopher; Vigna, Giovanni; Paxson, Vern (2014): "Hulk: Eliciting Malicious Behavior in Browser Extensions", in: Proceedings of the USENIX Security Symposium. (Link)

[27]

Xing, Xinyu; Meng, Wei; Lee, Byoungyoung; Weinsberg, Udi; Sheth, Anmol; Perdisci, Roberto; Lee, Wenke (2015): "Understanding Malvertising Through Ad-Injecting Browser Extensions", in: Proceedings of the ACM Web Conference. (DOI)

[28]

Pantelaios, Nikolaos; Nikiforakis, Nick; Kapravelos, Alexandros (2020): "You've Changed: Detecting Malicious Browser Extensions through their Update Deltas", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)

[29]

Kim, Kyungtae; Kim, I Luk; Kim, Chung Hwan; Kwon, Yonghwi; Zheng, Yunhui; Zhang, Xiangyu; Xu, Dongyan (2017): "J-Force: Forced Execution on JavaScript", in: Proceedings of the ACM Web Conference. (DOI)

[30]

Pantelaios, Nikolaos; Kapravelos, Alexandros (2024): "FV8: A Forced Execution JavaScript Engine for Detecting Evasive Techniques", in: Proceedings of the USENIX Security Symposium. (Link)

[31]

Bui, Duc; Tang, Brian; Shin, Kang G. (2023): "Detection of Inconsistencies in Privacy Practices of Browser Extensions", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)

[32]

Nayak, Asmit; Khandelwal, Rishabh; Fernandes, Earlence; Fawaz, Kassem (2024): "Experimental Security Analysis of Sensitive Data Access by Browser Extensions", in: Proceedings of the ACM Web Conference. (DOI)

[33]

Wang, Weihong; Dimova, Yana; Vansteenkiste, Victor; Van Goethem, Tom; Van Cutsem, Tom (2026): "The Masks We (Think We) Wear: Privacy Threats of Browser-Extension Wallets in the Web3 Ecosystem", in: Proceedings on Privacy Enhancing Technologies. (DOI)

[34]

Ferreira Torres, Christof; Willi, Fiona; Shinde, Shweta (2023): "Is Your Wallet Snitching On You? An Analysis on the Privacy Implications of Web3", in: 32nd USENIX Security Symposium (USENIX Security 23). (Link)

[35]

Vekaria, Yash; Canino, Aurelio Loris; Levitsky, Jonathan; Ciechonski, Alex; Callejo, Patricia; Mandalari, Anna Maria; Shafiq, Zubair (2025): "Big Help or Big Brother? Auditing Tracking, Profiling, and Personalization in Generative AI Assistants", in: Proceedings of the USENIX Security Symposium. (Link)

[36]

Djeric, Vladan; Goel, Ashvin (2010): "Securing Script-Based Extensibility in Web Browsers", in: Proceedings of the USENIX Security Symposium. (Link)

[37]

Akhawe, Devdatta; Saxena, Prateek; Song, Dawn (2012): "Privilege Separation in HTML5 Applications", in: Proceedings of the USENIX Security Symposium. (Link)

[38]

Kim, Young Min; Lee, Byoungyoung (2023): "Extending a Hand to Attackers: Browser Privilege Escalation Attacks via Extensions", in: Proceedings of the USENIX Security Symposium. (Link)

[39]

Agarwal, Shubham (2022): "Helping or Hindering?: How Browser Extensions Undermine Security", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)

[40]

Anliker, Claudio; Lain, Daniele; Capkun, Srdjan (2025): "Phishing Attacks against Password Manager Browser Extensions", in: Proceedings of the USENIX Security Symposium. (Link)

[41]

Chia, Pern Hui; Yamamoto, Yusuke; Asokan, N. (2012): "Is this app safe?: a large scale study on application permissions and risk signals", in: Proceedings of the ACM Web Conference. (DOI)

[42]

Dong, Xinshu; Chen, Zhaofeng; Siadati, Hossein; Tople, Shruti; Saxena, Prateek; Liang, Zhenkai (2013): "Protecting sensitive web content from client-side vulnerabilities with CRYPTONS", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)

[43]

Shezan, Faysal Hossain; Cheng, Kaiming; Zhang, Zhen; Cao, Yinzhi; Tian, Yuan (2020): "TKPERM: Cross-platform Permission Knowledge Transfer to Detect Overprivileged Third-party Applications", in: Proceedings of the Network and Distributed System Security Symposium. (Link)

[44]

Franken, Gertjan; Van Goethem, Tom; Joosen, Wouter (2018): "Who Left Open the Cookie Jar? A Comprehensive Evaluation of Third-Party Cookie Policies", in: Proceedings of the USENIX Security Symposium. (Link)

[45]

Ukani, Alisha; Haddadi, Hamed; Snoeren, Alex C.; Snyder, Peter (2025): "Local Frames: Exploiting Inherited Origins to Bypass Content Blockers", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security, pp. 1349-1363. (DOI)

[46]

Borgolte, Kevin; Feamster, Nick (2020): "Understanding the Performance Costs and Benefits of Privacy-focused Browser Extensions", in: Proceedings of the ACM Web Conference. (DOI)

[47]

Demir, Nurullah; Urban, Tobias; Pohlmann, Norbert; Wressnegger, Christian (2024): "A Large-Scale Study of Cookie Banner Interaction Tools and their Impact on Users' Privacy", in: Proceedings on Privacy Enhancing Technologies, pp. 5-20. (DOI)

[48]

Nisenoff, Alexandra; Borem, Arthur; Pickering, Madison; Nakanishi, Grant; Thumpasery, Maya; Ur, Blase (2023): "Defining "Broken": User Experiences and Remediation Tactics When Ad-Blocking or Tracking-Protection Tools Break a Website's User Experience", in: Proceedings of the USENIX Security Symposium. (Link)

[49]

Schöni, Lorin; Kubicek, Karel; Zimmermann, Verena (2024): "Block Cookies, Not Websites: Analysing Mental Models and Usability of the Privacy-Preserving Browser Extension CookieBlock", in: Proceedings on Privacy Enhancing Technologies, pp. 192-216. (DOI)