User Tools

Site Tools


provenance:security:authentication

Provenance: Security:Authentication

The working log behind Authentication as Deployed: Login, SSO, MFA and Passkeys: every query with its population, the hand audit that produced the page's 45-paper population, the folds and their residue, the quotes checked against the papers, the external sources and the ones rejected, what could not be established, and the review findings. Corpus-wide caveats — the retrieval funnel, the extraction's stability, the provisional 2025–2026 venue-years — are on corpus and are not restated here.

This page carries no ~~DISCUSSION~~ block: comments belong on the content page. It adds no bibliography entries of its own and cites the same shared bibliography with the same keys as the content page.

The Run

Item Value
Date 2026-09-11
Corpus at the time data/extract/run1/extractions.jsonl, 5,859 extracted papers, 7 venues, 2010–2026
Page status New page. Nothing on this wiki covered authentication deployment; the closest neighbour, Registration, covers login as an instrument and explicitly hands the “SSO as the subject” question over to a page that did not exist
Scripts written scripts/auth_pop.mjs (probes, inclusion rule, hand verdicts, citekeys, assertions), scripts/auth_audit.mjs (audit report), scripts/auth_report.mjs (the page's figures), scripts/auth_recall.py (full-text recall probe), scripts/auth_quotecheck.mjs (84 quote and figure checks)
Models Page and analysis: Claude Opus 5 (the session model). Two research sub-agents on sonnet (standards currency; tools and adoption data), both instructed to fetch rather than recall and to mark anything unverified. Four review passes: three on sonnet, one on fable
Bibliography 27 entries added, generated by scripts/bibgen.mjs from the corpus index; no entry written by hand from memory

The Gate This Page Had to Pass

roadmap listed this page under Assessed, and not written with the disposition: “46 papers unaudited, and the probe catches attacks on OAuth as well as deployment measurement. Gated on that audit; dropped if the deployment slice is under ~20.” The 46 came from one title-and-summary probe, auth_tight in scripts/gap_probe2.mjs.

The audit resolved the gate as follows:

Question Answer
Does the auth_tight probe still return 46? Yes — 46 papers, 37 on the web platform, unchanged against the current run
How many of those 46 measure deployment? 22. The other 24 are attacks, SDK and protocol analysis, mobile-app studies, user studies, abuse-ecosystem work, and three homonyms
So is it under the ~20 gate? Only if the candidate set stays at one probe. Four further probes and a full-text recall pass bring the candidate pool to 184, of which 45 are deployment measurements — and the branded-mechanism slice alone (SSO + MFA + passkeys, which is what the roadmap row described) is 25
Is the branded slice itself bigger than the probe saw? Yes: 25 papers measure SSO, MFA or passkey deployment, and four of them are invisible to the tight probe — it is the probe's recall, not its precision, that decided this gate
Decision Write the page, and broaden it from “SSO/WebAuthn/MFA” to the login surface as a whole, because the same instruments produce all of it and the login-page and login-policy papers are where the denominators come from

The Inclusion Rule

Fixed before any figure was written, and reproduced verbatim from the header of scripts/auth_pop.mjs. A paper is IN the population if and only if all three hold:

  1. Object — it measures authentication as deployed by services the authors do not control: login pages, login/password policies, SSO/OAuth/OIDC/SAML, MFA/2FA/RBA, passkeys/WebAuthn, account recovery, security notifications, or the session state a login establishes.
  2. Unit — the measured unit is a population of at least ten such services, or an operator's own production login telemetry. Not the authors' own testbed, not a library, not a protocol model, not human participants.
  3. Question — it asks what is deployed, available or configured, and reports per-service incidence. A paper that exploits a flaw in a handful of systems, analyses source code, or asks what users think is OUT even when it is about SSO.

A posture audit counts under (3) when it reports incidence across a sampled population: “n of N relying parties were vulnerable” is a deployment figure. That clause is what admits [1Sun, San-Tsai; Beznosov, Konstantin (2012): "The devil is in the (implementation) details: an empirical analysis of OAuth SSO systems", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)], [2Jannett, Louis; Mladenov, Vladislav; Mainka, Christian; Schwenk, Jörg (2022): "DISTINCT: Identity Theft using In-Browser Communications in Dual-Window Single Sign-On", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)], [3Ghasemisharif, Mohammad; Kanich, Chris; Polakis, Jason (2022): "Towards Automated Auditing for Account and Session Management Flaws in Single Sign-On Deployments", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)] and [4Luo, Kaixuan; Wang, Xianbo; Fung, Pui Ho Adonis; Lau, Wing Cheong; Lecomte, Julien (2025): "Universal Cross-app Attacks: Exploiting and Securing OAuth 2.0 in Integration Platforms", in: Proceedings of the USENIX Security Symposium. (Link)], and it is the clause a reasonable person would most plausibly draw differently — see Judgement calls below.

Probes: the Candidate Pool

Five probes over title + summary (the first is the roadmap's), unioned. None of these is a population; they are candidate generators, and every candidate was judged by hand.

Probe What it matches Candidates Web-platform Added
tight single sign-on, SSO, OAuth, OpenID, SAML, WebAuthn, passkey, FIDO, multi-factor, two-factor, 2FA, MFA 46 37 the roadmap's own probe
mechanism login/sign-in/sign-up words, identity provider, relying party, OTP/TOTP/U2F, security key, passwordless, magic link, account recovery, password reset, account takeover, credential stuffing, session management/cookie/hijack/fixation/integrity/token, password manager 68 42 2026-09-11, because the branded names miss the login-policy and session literature entirely
authnweb authenticat* anywhere, restricted to web-platform papers 50 50 2026-09-11, recall check on the word the field uses when it names no mechanism
accountweb account(s) anywhere, restricted to web-platform papers 57 57 2026-09-11, same reason; very noisy by design
recall a closed list of 11 slugs surfaced by the full-text probe below 11 7 2026-09-11, after the full-text pass
UNION 184 147

Reproduce with:

node scripts/auth_audit.mjs            # the audit: probes, verdicts, assertions
node scripts/auth_report.mjs           # the page's figures
node scripts/auth_report.mjs --prevalence --wikitable   # every prevalence tuple, and the 45-paper table
python3 scripts/auth_recall.py --threshold 8            # the full-text recall pass (~7 min)
node scripts/auth_quotecheck.mjs       # 84 quote and figure checks

The Audit

scripts/auth_audit.mjs refuses to print a population unless every candidate has a verdict, every verdict reason is distinct (a repeated reason is a canned reason, not evidence), every IN paper has a subgroup and a citekey, and no citekey is used twice. Its unedited output is embedded at the foot of this page; the summary:

Verdict Papers Share of 184 What it means
IN 45 24.5% in the population
ABUSE 26 14.1% abuse, fraud, spam and account-market ecosystems
ATTACK 20 10.9% an attack or flaw hunt without population incidence
ADJACENT 18 9.8% another page on this wiki owns it
USER 16 8.7% the object is what people think or do
PASSWORD 15 8.2% passwords as secrets
PWMANAGER 13 7.1% password managers
SYSTEM 12 6.5% a system or defence the authors built
HOMONYM 11 6.0% the probe matched a different sense of the word
LIB 8 4.3% libraries, SDKs, frameworks, protocol models

Three quarters of the candidate pool is off topic, which is the fact the roadmap's gate existed to discover. The homonyms are worth recording because they will recur: MFA is the paper's own abbreviation for “Made for AdSense” in a 2011 search-spam study (verified in its full text); OpenID matches “OpenIDEO”, the design-idea platform; multi-factor is a sequence-fusion architecture in an NLP paper; and an RPKI relying party is a route-origin validator, which alone accounts for five candidates.

Subgroups of the 45, which are the page's section structure:

Subgroup Papers Span
SSO / OAuth / OIDC / SAML 12 2012–2026
MFA, 2FA, risk-based authentication 7 2021–2025
Passkeys and WebAuthn 6 2022–2026
The login surface 12 2017–2026
Post-login session state 4 2015–2024
Operator telemetry 4 2015–2022

The Recall Pass, and Its Weak Step

A title-and-summary candidate set is a recall claim, so it was tested. scripts/auth_recall.py streams every paper.cols.txt in the corpus (5,855 of the 5,859 records have one; the 4 without are counted as negatives), collapses whitespace — a PDF line break inside “single sign-on” otherwise hides it — and counts hits for four families: SSO, passkey/WebAuthn, MFA, and login surface.

Step Result
Papers scanned 5,855 (+4 with no full text, counted as negatives; the script prints both, and they sum to the corpus's 5,859)
Threshold for hand review ≥ 8 full-text hits and not already a title/summary candidate
Papers over threshold 155
Positive control 43 of the 45 population papers also score ≥8. Four of those 45 are papers this probe itself contributed, so the non-circular reading is 39 of the 41 it did not supply. A recall probe that cannot see the population it is testing measures nothing
Control's two misses cookie-crumbles scores 1 and secrets-lies-and-account-recovery scores 2 — the session-prefix and secret-question vocabularies are invisible to a mechanism-name probe. The probe's own blind spot, printed by the script
Read in full or by summary 11 of the 155, chosen because their titles left open that the object was web authentication deployment
Added to the population 4 — [5Khodayari, Soheil; Pellegrino, Giancarlo (2022): "The State of the SameSite: Studying the Usage, Effectiveness, and Adequacy of SameSite Cookies", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)], [6Zheng, Xiaofeng; Jiang, Jian; Liang, Jinjin; Duan, Haixin; Chen, Shuo; Wan, Tao; Weaver, Nicholas (2015): "Cookies Lack Integrity: Real-World Implications", in: Proceedings of the USENIX Security Symposium. (Link)], [7Hu, Yuqi; Alroomi, Suood; Sahin, Sena; Li, Frank (2024): "Unmasking the Security and Usability of Password Masking", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)], [8Wu, Mengying; Hong, Geng; Chen, Jiatao; Liu, Baojun; Liu, Mingxuan; Yang, Min (2026): "One Email, Many Faces: A Deep Dive into Identity Confusion in Email Aliases", in: Proceedings of the Network and Distributed System Security Symposium. (Link)]
Rejected after reading 7, each with its own recorded reason (a password-policy administrator interview study, a brokered-identity redesign with no measured population, CAPTCHA prevalence, OAuth in IFTTT rules, OAuth apps in Slack and Teams, IoT cloud delegation, academic VPN authentication)

The weak step, stated plainly: 144 of the 155 were dismissed on their titles alone. That is weaker than every other step in this audit. The full ranked list with per-family hit counts is embedded below, so the next run can second-guess any of them without re-running the seven-minute scan. Two kinds of paper are the likely misses: work whose title names a phenomenon rather than a mechanism, and work in the 2025–2026 slice where my own reading was thinnest.

Every Figure on the Page, and Where It Comes From

Page section Figure Source
Intro 45 papers; 42 of them web-platform (2.6% of 1,622); 25 of them ran a crawl (2.2% of 1,120) auth_report.mjs header. The first draft divided 45 by both denominators, which put three operator-telemetry papers over a web-platform base and twenty non-crawling papers over a crawl base; the generic review caught it and the script now prints the subsetted numerators
The denominator is the whole argument 9.3% / 6.30% / 7.23% / 27% / 57.8% and their denominators each paper's own text, all five verified by auth_quotecheck.mjs; the 85.9K reachable denominator is derived from the paper's own 14,104-failure figure, not back-calculated from the percentage
Five questions every prevalence figure quoted auth_report.mjs –prevalence, which prints all 258 prevalence strings with the extraction's evidence quote and section, for all 45 papers
Methods and which are current median site-unit n = 872; 39 of 85 site-unit entries under 500 auth_report.mjs §5
classification.method == llm: 0 of 45, 177 corpus-wide (2023:2, 2024:27, 2025:77, 2026:71) auth_report.mjs §8
What changed under you every row fetched 2026-09-11, see External sources below
Tools entry counts, commit dates, HTTP statuses fetched 2026-09-11, see External sources below
Ethics 45.5% / 68.2% / 68.3% with web and corpus base rates auth_report.mjs §6
Use in publications population, window, venue, instrument, frame and quiet-field tables auth_report.mjs §§1, 3, 4, 6, 7
The 45 papers the whole table auth_report.mjs –wikitable, generated rather than typed

Population definitions used, each naming its own denominator:

  • the population = the 45 IN papers. Never “of 5,859”.
  • web-platform papers = 1,622 papers whose platforms includes web. 42 of the 45 are in it; the three that are not are the operator-telemetry studies of Google and two universities.
  • crawled = 1,120 papers with a crawlConfig object or the automated-web-crawl study type. 25 of the 45 are in it.
  • papers with a crawl configuration inside the population = 23 of 45. Every crawlConfig share on the page divides by 23, not by 45 — more than half of this literature is manual audit or operator telemetry and has no crawl to configure.
  • papers with an ethics object = 44 of 45; with an artifacts object = 41 of 45. Those are the denominators for the ethics and artifact rows, and they are not 45.

Folds and Their Residue

Two free-text fields are aggregated on the page, and both are folded by rules written into scripts/auth_report.mjs rather than by name_fold.mjs, because the shared fold canonicalises case and punctuation but does not merge synonyms.

Instruments (tools[].name), counted by paper. Rules: all Chrome/Chromium/Google Chrome spellings to one family; Firefox and GeckoFX together; Selenium; Puppeteer including puppeteer-extra; Playwright including “Microsoft Playwright”; CDP as its own row; mitmproxy and “MitM proxy”; Faker and RandExp as “synthetic-identity generator”; Twilio, Wit.ai, the Gmail API and G Suite as “registration plumbing”; Prolific and Mechanical Turk as “participant panel”; OpenWPM and Tracker Radar Collector each as their own row.

A widened absence check changed a claim before it was published. The draft read “nobody uses an off-the-shelf measurement framework: OpenWPM appears zero times”. OpenWPM really is zero, in tools[] and otherToolsMentioned[] alike — but widening the same check to Tracker Radar Collector, webXray and crawl4ai returned one paper, [9Senol, Asuman; Ukani, Alisha; Cutler, Dylan; Bilogrevic, Igor (2024): "The Double Edged Sword: Identifying Authentication Pages and their Fingerprinting Behavior", in: Proceedings of the ACM Web Conference 2024. (DOI)], which builds on DuckDuckGo's collector. The page now says “almost nobody”, names the exception, and the widened check is printed by auth_report.mjs §6a so the claim is script-backed rather than asserted. An absence claim that rests on one spelling of one tool is a probe result wearing a conclusion's clothes.

Residue: 203 distinct tool strings, 218 mentions, unmapped and printed in full in the embedded report output. It is not noise — it is the most informative part of the fold, because it is almost entirely one-off crawlers named after their own paper (SSOScan, Distinct, SAAT, Web3AuthChecker, QRLChecker, IDB-DETECTOR, FP-Extractor, PASSKEYS-RADAR, PASSKEYS-ATTACKER, Account Framework, Live-Monitor, Communication-Inspector). That is the finding the page states: this subfield builds bespoke instruments and reuses almost nothing, and OpenWPM appears zero times.

Sampling frames (population[].sourceList), counted by paper. Rules: Tranco; CrUX including “Chrome UX Report” and “Chrome User Experience Report”; Alexa; Majestic; Quantcast; Cisco Umbrella; 2fa.directory; Similarweb; HTTP Archive; Fortune 1000; “custom / not stated” for custom seed lists and not-stated; participant panels. Residue: 44 distinct strings, printed in full below — mostly per-paper artefacts (Google login traces, partner RP authentication logs, the FIDO Metadata Service, PASSKEYS-RADAR merged sources, DappRadar, npm and GitHub APIs) rather than spelling variants of a ranking list.

Quotes and Figures Checked Against the Papers

scripts/auth_quotecheck.mjs: 95 needles, 95 PASS, 0 FAIL (unedited output embedded below). Needles are sentence fragments rather than bare numbers — a bare “42.3%” is a true string in the wrong paper. Two exceptions, both in the block labelled “figures re-read from the paper”: 6,211 and 18.53 are checked as bare strings against one named paper each, because what they had to establish was that paper's denominator, and the sentences around them are checked separately.

The method needed three tiers, and the reason is worth recording because it will bite the next run:

  1. Exact match in one of three renderings (paper.cols.txt, paper.txt, paper.norm.txt), after collapsing whitespace, joining hyphenation across line breaks, normalising ligatures and curly quotes, and folding case.
  2. Token match with punctuation and hyphen tolerance. The rendering writes “sessions.” where the needle has “sessions”, and “pre- hijacking” where the paper's prose has “pre-hijacking”. Exact matching called 15 of 84 verbatim quotes a FAIL before this tier existed.
  3. Column-splice tolerance. A two-column PDF drops the other column's words into the middle of a sentence: the paper really says “89.5% of 2.1 the RPs we evaluate do not offer options for invalidating active sessions”. The matcher walks the needle's tokens in order and accepts at most 8 injected words, printing the count. 8 needles matched only this way; the largest injections were 8 words (the SoK's passkey-support sentence, and the Google recovery-rate comparison).

Three needles were shortened or dropped rather than matched with a tolerance that would accept anything: SAAT's revocation sentence was split into two contiguous halves; the identity-account abstract's “80 out of 100 websites are vulnerable to the inconsistency threat” is spliced inside the hyphenated word “web-sites” and was replaced with the results-section fragment “sites are vulnerable to the inconsistency threat”; and its per-case sentence was dropped. Anything that could not be verified this way is not on the page.

One extraction quote turned out to be a near-paraphrase: the detection[] tuple for [10Kepkowski, Michal; Hanzlik, Lucjan; Wood, Ian; Kaafar, Mohamed Ali (2022): "How Not to Handle Keys: Timing Attacks on FIDO Authenticator Privacy", in: Proceedings on Privacy Enhancing Technologies. (DOI)] records “We gathered 684 records of WebAuthn executions”, which is in the paper, but the sentence the page quotes instead is the clearer “we surveyed 1 million high traffic web sites and found 684 FIDO authentication deployments”. Both are verbatim; the second is the one a reader can act on.

External Sources

Everything not in the corpus was fetched on 2026-09-11, never recalled. Two sub-agents did the first pass; every load-bearing claim below was then re-fetched independently by me, because a sub-agent's industry notes have previously come back leaning on listicles.

Claim on the page Source How verified
WebAuthn Level 3 is a W3C Recommendation, 25 August 2026 w3.org/TR/webauthn-3/ Fetched 2.7 MB of spec HTML and grepped it: “Level 3 W3C Recommendation , 25 August 2026”, and the presence of getClientCapabilities(), isConditionalMediationAvailable(), Related Origin Requests and the /.well-known/webauthn fetch step
CTAP 2.3, Proposed Standard, 26 February 2026, and 2.3.1 in Working Draft since 29 May 2026 fidoalliance.org/specs/ Sub-agent fetched the spec header; the currency review then read the specs directory and found the 2.3.1 working draft the first pass had missed, which is now on the page. Used as dates, not as figures
FedCM: spec is a First Public Working Draft (2024-08-20) w3.org/TR/fedcm-1/ and w3.org/standards/history/fedcm-1 Sub-agent fetch; the history page lists only the FPWD
FedCM shipping: IdentityCredential Chrome 108+, absent in Firefox and Safari; navigator.login Chrome 120+ and Firefox 138+ MDN browser-compat-data, api/IdentityCredential.json and api/NavigatorLogin.json Re-fetched by me from the raw JSON on main and read directly, because the sub-agent could only reach prose around the compatibility table. The Firefox-138 Login-Status-API detail contradicts the looser “Firefox paused FedCM” summary and is the reason the page states the two APIs separately
RFC 9700, Best Current Practice for OAuth 2.0 Security, January 2025; OAuth 2.1 still a draft (-16, 2026-09-03) datatracker.ietf.org Sub-agent fetch of both tracker pages, status lines quoted
OpenID Federation 1.0 Final, 17 February 2026 openid.net/specs/openid-federation-1_0.html Sub-agent fetch
SAML 2.0 unchanged since 2005 and not deprecated; Entra “fully supports each one” OASIS standard index; Microsoft Learn SAML-vs-OIDC guide Sub-agent fetch, quoted verbatim. The currency review corrected the date: the page displays “Last updated on 2026-06-23” (ms.date 2026-06-22), and the 2026-08-26 the first pass recorded is an updated_at metadata value whose matching commit edits a shared include, not this content
Chrome is not deprecating third-party cookies privacysandbox.google.com/blog/update-on-plans-for-privacy-sandbox-technologies, 17 October 2025 Sub-agent fetch, quoted verbatim
RFC 6265bis still an Internet-Draft (v22), IESG-approved and in the RFC Editor's queue datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/ Sub-agent fetch of the status line; the currency review queried the datatracker state API and found the IESG state is rfcqueue — past IESG review, awaiting publication — so the draft's “in final review” wording was corrected
2fa.directory has 2,570 entries api.2fa.directory/v3/all.json Re-fetched by me: HTTP 200, 514,927 bytes, JSON array length counted = 2,570, agreeing with the repository's entries/ tree
twofactorauth.org now redirects to a commercial bootcamp twofactorauth.org Re-fetched by me: HTTP 301 with redirect_url = brainstation.io/cybersecurity/two-factor-auth; following it gives HTTP 200 on that page. The status code and redirect target were printed rather than inferred from a byte count
2factorauth/passkeys has 270 entries GitHub trees API Re-fetched by me: 270 entries/**.json blobs, response not truncated
Repository liveness and last-commit dates GitHub commits API Re-fetched by me for all six repositories. Dates used: twofactorauth 2026-09-07, 2factorauth/passkeys 2026-09-03, state-of-passkeys-artifacts 2026-04-21, passkeys.tools 2026-03-31, login-security-landscape 2025-12-19, double_edged_sword_data 2024-02-12. pushed_at was not used: it reads 2026-07-16 for login-security-landscape, six months after the last commit
passkeys.directory is alive, 1Password-provided, community-driven index passkeys.directory Re-fetched by me: HTTP 200, and both phrases read out of the page's own metadata. No entry count, no export and no visible last-updated date — recorded as unverifiable rather than estimated
FIDO MDS is rate-limited today mds3.fidoalliance.org Re-fetched by me: 301 to mds.fidoalliance.org, then HTTP 429 with a 35-byte body. The sub-agent saw the same from a different egress over ~11 attempts. No authenticator count is published on the page, because neither of us could fetch the blob
FIDO Alliance: “an estimated 5 billion passkeys are now in use worldwide”, 7 May 2026, with survey methodology fidoalliance.org/fido-alliance-reports-accelerating-global-passkey-adoption-on-world-passkey-day-2026/ Re-fetched by me and grepped: the 5-billion sentence, the 75% and 68% figures, and the Sapio Research methodology note (11,000 consumers, ±0.9pp at 95%; 1,400 workforce decision-makers; ten countries)
Microsoft: “nearly a million passkeys registered every day”; “about 98% versus 32%” microsoft.com/en-us/security/blog/2025/05/01/… Re-fetched by me and grepped both sentences verbatim. The post's “15 billion user accounts” figure is Microsoft citing the FIDO Alliance and the page says so
Web Almanac has no identity chapter; its 2025 Security chapter never mentions WebAuthn or passkeys almanac.httparchive.org/en/2025/ and /en/2025/security Re-fetched by me: 16 content chapters enumerated from the index; the Security chapter's text contains webauthn 0 times, passkey 0 times, “login form” 0 times
ssoscan.org still answers ssoscan.org Re-fetched by me: HTTP 200 after redirect

Rejected external sources

Rejected Why
Corbado “Passkey Benchmark”, state-of-passkeys.io, Descope, MojoAuth and similar vendor adoption dashboards Adoption percentages with no stated population or methodology, presented as industry data. Exactly the material the page would be re-adding next year if this row were not here
Google's “800 million accounts / 2.5 billion sign-ins” passkey pair Traces to a May 2024 post. It cannot support a 2026 currency claim, and no dated 2025–2026 Google primary post with a hard adoption number could be found — the Workspace post of 2025-07-30 gives only “40% faster” and a customer count
Every Apple-attributed passkey adoption percentage found None came from Apple. Apple's own pages announce features without figures
Cloudflare Radar as a passkey data source radar.cloudflare.com/adoption-and-usage returned 403 to both curl and a fetch tool, and no Cloudflare passkey report exists. Note the name collision that caused this dead end: the “Passkey Radar” in search results is radar.passkeys.tools, the academic tool from [11Jannett, Louis; Mayer, Andreas; Westers, Maximilian; Mladenov, Vladislav; Mainka, Christian; Schwenk, Jörg (2026): "The State of Passkeys: Studying the Adoption and Security of Passkeys on the Web", in: Proceedings of the USENIX Security Symposium. (Link)], not a Cloudflare product
github.com/yashpatil582/auth-component-detector as a login-detection tool Matches the description, but: 0 stars, months old, and its own commit log shows it was written by an AI assistant. Not a research instrument, and naming it as one would be the listicle failure in a new costume
github.com/CyberDrain/Check as a login-detection tool Real and actively maintained, but it is an end-user phishing-protection extension, not a measurement instrument
github.com/ScottHelme/passkeys-directory as the data behind passkeys.directory A different project (it backs whynopasskeys.com), and its README states that 1Password's and Bitwarden's directories are not ingested because neither publishes a reusable licence. Conflating the two would have attributed a licence and a count to the wrong dataset
Shepherd as a maintained, reusable tool A project page exists; no maintained public repository could be located. The page cites the paper for the method and says the code could not be verified

Bibliography Additions

27 entries, all generated by node scripts/bibgen.mjs <venue>/<year>/<slug> from data/corpus2/.meta — publisher metadata, not recalled strings. 23 are population papers; the other four are cited in prose only: [12Lassak, Leona; Pan, Elleen; Ur, Blase; Golla, Maximilian (2024): "Why Aren't We Using Passkeys? Obstacles Companies Face Deploying FIDO2 Passwordless Authentication", in: Proceedings of the USENIX Security Symposium. (Link)] (why passkey deployment stalls), [13Wang, Rui; Chen, Shuo; Wang, XiaoFeng (2012): "Signing Me onto Your Accounts through Facebook and Google: A Traffic-Guided Security Study of Commercially Deployed Single-Sign-On Web Services", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)] (the founding web-SSO security study), [14Sahin, Sena; Al-Roomi, Suood Abdulaziz; Poteat, Tara; Li, Frank (2023): "Investigating the Password Policy Practices of Website Administrators", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)] (the administrators' side of password policy) and [15Brandão, Luís T. A. N.; Christin, Nicolas; Danezis, George; Anonymous, (2015): "Toward Mending Two Nation-Scale Brokered Identification Systems", in: Proceedings on Privacy Enhancing Technologies. (DOI)] (brokered-identity history). The population's other 22 citekeys were already in the bibliography. Checks run before appending:

  • scripts/bib_dedup_scan.py –bib on the merged file: 977 entries, 977 distinct citekeys, no same-DOI and no same-title pair. The scan's [D] candidate class (same year, same folded surname) printed 85 pairs, all previously judged and none of them mine except surname coincidences (wu2026_email against wu2026_tracking, zhang2025_qrcode against zhang2025_abusability, yan2024_stealing against yan2024_quality).
  • Every {[key]} on both pages resolves against the merged bibliography: 51 distinct keys used across the two pages, 0 missing, and every one of the 27 new entries is cited. (The generic review caught that this very sentence had been counting itself: an unescaped citekey inside inline code still resolves, because monospace markup does not escape the plugin's syntax.)
  • Author lists for PETS and USENIX are absent from the corpus index by construction. scripts/fetch_authors.py recovered nine from the venue landing pages; three PETS records failed to parse and were filled by hand from the paper's own first page — [16Corre, Kevin; Barais, Olivier; Sunyé, Gerson; Frey, Vincent; Crom, Jean-Michel (2017): "Why can't users choose their identity providers on the web?", in: Proceedings on Privacy Enhancing Technologies. (DOI)], [10Kepkowski, Michal; Hanzlik, Lucjan; Wood, Ian; Kaafar, Mohamed Ali (2022): "How Not to Handle Keys: Timing Attacks on FIDO Authenticator Privacy", in: Proceedings on Privacy Enhancing Technologies. (DOI)] and [15Brandão, Luís T. A. N.; Christin, Nicolas; Danezis, George; Anonymous, (2015): "Toward Mending Two Nation-Scale Brokered Identification Systems", in: Proceedings on Privacy Enhancing Technologies. (DOI)] — then cross-checked against Crossref, which agreed on names and order in all three. The 2015 brokered-identity paper genuinely has a fourth author listed as “Anonymous”, on the PDF and in Crossref alike; the entry keeps it.
  • Crossref caught a surname error. bibgen derived “Tchokodeu, Kevin Nsieyanji” for the CCS 2024 poster; Crossref gives family name “Nsieyanji Tchokodeu”, given name “Kevin”. Fixed before appending. Six DOIs were spot-checked against Crossref (titles, author order, year, venue) and the other five matched exactly.
  • Two DBLP title artefacts fixed: “as aDefense” → “as a Defense” in [17Doerfler, Periwinkle; Thomas, Kurt; Marincenko, Maija; Ranieri, Juri; Jiang, Yu; Moscicki, Angelika; McCoy, Damon (2019): "Evaluating Login Challenges as a Defense Against Account Takeover", in: Proceedings of the ACM Web Conference. (DOI)], and the stray curly quotation marks in the title of [18Wei, Tongxin; Wang, Ding; Li, Yutong; Wang, Yuehuan (2025): ""Who is Trying to Access My Account?" Exploring User Perceptions and Reactions to Risk-based Authentication Notifications", in: Proceedings of the Network and Distributed System Security Symposium. (Link)] normalised to ASCII.

What Could Not Be Established

  • How many authenticators are in the FIDO Metadata Service today. The endpoint returned HTTP 429 to every attempt from two networks. No count is published on the page; the 2023 paper's 160-authenticator figure is cited as that paper's, with its date.
  • Whether passkey deployment has grown, and by how much. Four measurements exist and no two share a frame, a detection method, or a definition of “supports passkeys”. The page states the four and declines to draw a trend line. The 2026 census's own longitudinal figure is a directory-archive reconstruction, not a repeat of its own instrument.
  • Anything about enterprise SSO. 39 papers in the corpus mention Entra, Okta, Azure AD, ADFS or Workspace; judged from their titles none has enterprise identity as its object, and I did not read all 39. No sampling frame for enterprise tenants was found either — the nearest thing in the population is a poster whose frame is 100 named companies [19Nsieyanji Tchokodeu, Kevin; Schulmann, Haya; Sobol, Gil; Waidner, Michael (2024): "Poster: Security of Login Interfaces in Modern Organizations", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)]. Both halves of that are weaker than the FedCM claim, which rests on a full-text count of one.
  • FedCM's deployed footprint. Zero papers, and no public dataset. The page says so rather than guessing from the spec's existence.
  • Whether the classification.method == llm absence is real or a publication lag. It is a true statement about this corpus (0 of 45, against 177 corpus-wide), but 2025–2026 is the thinnest slice of the corpus and the page says so in the same paragraph.
  • The recall of the 144 title-only dismissals in the recall pass. See the box above; this is the audit's weakest step.
  • Whether a public HTTP Archive query exists for navigator.credentials usage. The Web Almanac has no such chapter; a BigQuery check of HTTP Archive's JS-API tables was out of reach from this environment and is recorded as unchecked rather than absent.
  • SOUPS. Much of the usability-adjacent deployment work is published there and the corpus does not include it. This is the single most consequential venue gap for this page, and it is named on the content page.

Judgement Calls

Call What I decided What a reasonable person might have decided
Scope: narrow or broad Broadened from the roadmap's “SSO/WebAuthn/MFA deployment” to the whole login surface, including login-page discovery, login and password policies, account creation, and post-login session state. The instruments are shared, and the login-page papers are where the denominators come from Keep it to the branded mechanisms. That population is 25 papers, still above the gate, and would have made a shorter page — at the cost of publishing SSO percentages without the “sites that have a login” denominator that only the login-surface papers supply
Posture audits as deployment measurement IN when they report per-site incidence over a sampled frame ([1Sun, San-Tsai; Beznosov, Konstantin (2012): "The devil is in the (implementation) details: an empirical analysis of OAuth SSO systems", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)] at 96 relying parties, [4Luo, Kaixuan; Wang, Xianbo; Fung, Pui Ho Adonis; Lau, Wing Cheong; Lecomte, Julien (2025): "Universal Cross-app Attacks: Exploiting and Securing OAuth 2.0 in Integration Platforms", in: Proceedings of the USENIX Security Symposium. (Link)] at 18 integration platforms) OUT as “attack papers”. The line I drew is incidence-over-a-frame; without it, [2Jannett, Louis; Mladenov, Vladislav; Mainka, Christian; Schwenk, Jörg (2022): "DISTINCT: Identity Theft using In-Browser Communications in Dual-Window Single Sign-On", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)] and [3Ghasemisharif, Mohammad; Kanich, Chris; Polakis, Jason (2022): "Towards Automated Auditing for Account and Session Management Flaws in Single Sign-On Deployments", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)] would also leave, and they are two of the best deployment audits in the corpus
Session-cookie hardening IN as a subgroup of four papers, because a session cookie is what a login produces OUT to Cookies or Headers. Checked first: privacy:cookies mentions SameSite once, in a row about the security role of cookies (5 papers, 9.4%), and does not cover prefix or SameSite adoption; privacy:browser_storage mentions it once in a code sample. No page owned this
CAPTCHA prevalence OUT of the population, cited in prose, pointed at Registration — a bot challenge guards many flows and is not a claim about an identity IN. It is a 200-site prevalence measurement of a control that sits on the login form, and excluding it while including password masking is a fine line
wang2012_signing (the founding web-SSO security paper) OUT of the population — eight flaws in a handful of named systems, no measured frame — but cited in the historical section IN as a landmark. The rule would then have to admit every small-n flaw hunt
Operator telemetry as a subgroup IN (4 papers). It answers what no crawl can, and a page that omitted it would tell a student that crawling is the only instrument OUT as “not a deployment measurement of the web”. Their unit is one operator, not a population of services, which is a real objection; the inclusion rule names them explicitly as the single exception
[8Wu, Mengying; Hong, Geng; Chen, Jiatao; Liu, Baojun; Liu, Mingxuan; Yang, Min (2026): "One Email, Many Faces: A Deep Dive into Identity Confusion in Email Aliases", in: Proceedings of the Network and Distributed System Security Symposium. (Link)] (email aliases) IN. Its object is how 18 platforms and 28 mail providers resolve identifiers at signup, login and recovery — identifier handling as deployed OUT as an email paper. It is the most arguable inclusion in the population
kang2026_connecting filed under SSO IN, SSO subgroup: it built 85,053 authentication pages and measured account-linking integration and OAuth token exposure OUT as a messaging-app privacy paper. Most of its contribution is cross-platform identity linking; the login-page census is a means
The poster paper [19Nsieyanji Tchokodeu, Kevin; Schulmann, Haya; Sobol, Gil; Waidner, Michael (2024): "Poster: Security of Login Interfaces in Modern Organizations", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)] IN, flagged in its verdict reason as a poster whose figures are preliminary OUT for being two pages. It is the only paper here whose frame is organisations rather than a ranking list, which is worth showing
Publishing “nobody uses an LLM” Published, with the year-by-year corpus counts and the thin-slice caveat in the same paragraph Withhold it. The claim rests on an enum over a provisional slice, and “nobody” is the kind of word a probe should not be allowed to produce — which is why it is stated as an enum count over the population, not as a probe result

After Publishing: What the Rendered Page Showed

Source-level checks pass on a page that renders wrong, so both pages were verified against the rendered DOM after saving, not against their wikitext.

Check Result
The bibliography was stale, silently. The content page first rendered 24 reference entries for 51 distinct citekeys, numbered up to [51] with gaps — every inline marker resolved, so nothing looked broken. bibtex4dw had served a cached parse of literature:bibliography that predated the 27 new entries Fixed by requesting ?purge=true on the bibliography and then on each citing page. The content page now renders 51 of 51 with no gaps, and security renders its four new keys
Content page structure 11 h2, 21 h3, 12 tables, 131 table rows, both boxes as divs, 0 red links, no leftover literal markup
Provenance page structure 16 h2, 22 h3, 15 tables (this one included), 13 pre blocks — 12 file blocks and one code block — 23 reference entries, 0 red links after fixing one namespace-relative [[artifacts]]
The escaped citekey {[key]} renders as literal text rather than resolving, which is the point of the escape
Site-wide red-link gate node scripts/sitemap.mjs — 174 pages, 4 promised-but-missing, all 4 declared on roadmap, 0 undeclared, exit 0

Review Passes

Four passes, all told explicitly that my context might not be exhaustive, and all handed the page text, the scripts, the unedited outputs and these notes. The three focused passes ran in parallel first; the generic pass ran after their findings were applied. Rejections are recorded as carefully as fixes: they are the only evidence of whether a reviewer earned its slot.

Pass 1 — figures against the script (sonnet)

Re-ran every script, diffed against the committed outputs, mutation-tested the assertions, and re-derived the arithmetic.

# Finding Disposition
1 The exclusion tally in Use in Publications summed to 109, not the 139 it claimed: the sentence listed seven verdict classes and silently dropped ADJACENT (18) and SYSTEM (12) Accepted and fixed. Both classes added; 26+20+18+16+15+13+12+11+8 = 139
2 artifacts.availability was given as “28 of the 45” in prose while the field's own table row says 28 of 41 — four papers have no artifacts object at all, so stated + sentinel ≠ 45 Accepted and fixed. The prose now divides by 41 and says why
3 The LISTFOLD bucket for 2fa.directory was /2fa/i, which also matches “UCB anonymized 2FA log events” and “UIUC 2FA-related support tickets” — so an operator-telemetry paper was counted as sampling from the directory, and the paper the prose named ([20Gavazzi, Anthony; Williams, Ryan; Kirda, Engin; Lu, Long; King, Andre; Davis, Andy; Leek, Tim (2023): "A Study of Multi-Factor and Risk-Based Authentication Availability", in: Proceedings of the USENIX Security Symposium. (Link)]) was not in the bucket at all because it sampled from Tranco Accepted and fixed. Regex tightened to /2fa\.?\s?directory/i; the table row moved from “3 papers, 2023–2025” to “2 papers, 2023”; the prose now names the two that sample from it and reports what the third actually did with it
4 “two independent studies four years apart” compared a 2022 and a 2023 paper, and the 27.4% being compared is not printed by either paper — it is my arithmetic on the IMC study's two figures Accepted and fixed. The years are now named, and the derived figure is labelled as derived in the sentence that uses it
Setup checks No finding. All four scripts exit 0 and reproduce their committed outputs byte-for-byte; the 45-row table on the page matches –wikitable byte-for-byte
Mutation test of the published assertions No finding, and this is the result I wanted. A bogus subgroup, a deleted citekey, a duplicated verdict reason and an ambiguated hand-map key each made audit() exit non-zero with a message naming the broken paper, and auth_report.mjs fails identically because it imports the same function. None of the four assertions is vacuous

Pass 2 — citations and quotes (sonnet)

Re-verified all 27 new BibTeX entries against Crossref or the venue landing page (titles, full author lists, author order, year, venue), re-checked ~40 numeric claims the quote checker does not cover, and tested the page's structural claims against competing papers.

# Finding Disposition
1 The passkey table credited [21Kuchhal, Dhruv; Saad, Muhammad; Oest, Adam; Li, Frank (2023): "Evaluating the Security Posture of Real-World FIDO2 Deployments", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)] with “Tranco top 1K (from a 100K crawl)”. The 100K crawl is a pilot the authors abandoned: the string pair appeared on 135 sites, 82 of them enterprise IAM SDKs, and known FIDO2 deployments like Google and PayPal were missed entirely Accepted, fixed and promoted. The row now shows the paper's real funnel (1,000 → 841 → 585 → 85 → 40 → 29) and the abandoned pilot became a method point in its own right, because “grep for navigator.credentials” is the obvious wrong instrument
2 “The only mechanism in this population whose deployment can be detected from the outside without an account” (of passkeys) contradicts the page's own section 2, where identity-provider acceptance is detected without an account Accepted and fixed. Narrowed to the only second factor readable from outside, with a pointer to the other account-free signal
3 The tools table called 2fa.directory “the sampling frame three MFA papers used”, including [20Gavazzi, Anthony; Williams, Ryan; Kirda, Engin; Lu, Long; King, Andre; Davis, Andy; Leek, Tim (2023): "A Study of Multi-Factor and Risk-Based Authentication Availability", in: Proceedings of the USENIX Security Symposium. (Link)], which sampled from Tranco and only cross-checked against the directory — finding that 114 of its 208 sites were absent from it Accepted and fixed, independently of Pass 1's finding 3, which caught the same error from the script side. The 114-of-208 figure is now published: it is the only measurement of that directory's coverage in the corpus
4 amft2023_disabled's first author is Klivan, Sabrina in Crossref, in ORCID and on the paper's own current PDF — the corpus index still carries the pre-rename “Amft” Accepted. Verified independently: Crossref and the corpus's own paper.cols.txt first page both read “Sabrina Klivan”. The entry, the citekey (klivan2023_disabled) and the page's prose all use the current name. A bibliography whose author names come from an index inherits that index's staleness, including post-publication name changes
Bibliography mechanics No finding. 51 keys used, all resolve; 27 new keys, none colliding with the existing 954; no duplicate DOIs; no fuzzy title collisions; every new entry cited
Industry quotes No finding. FIDO Alliance, Microsoft, Microsoft Entra and Privacy Sandbox quotes all verbatim against the live pages

Pass 3 — external currency (sonnet)

Told to fetch rather than recall, and to verify this log's own External sources table rather than trust it.

# Finding Disposition
1 RFC 6265bis was described as “in final review”. The datatracker's state API gives the IESG state as rfcqueue — past IESG review, waiting on the RFC Editor Accepted and fixed in both the table and the footnote
2 The CTAP row named 2.3 (Proposed Standard, 2026-02-26) and missed that CTAP 2.3.1 has been in Working Draft since 2026-05-29, published to the specs directory in August Accepted and fixed. The row now carries both
3 The Microsoft Entra citation was dated 2026-08-26, which is an updated_at metadata value whose matching commit edits a shared include; the page itself displays “Last updated on 2026-06-23” Accepted and fixed. The footnote now gives the displayed date and explains the discrepancy — which Pass 2 read the other way round, so the footnote records both readings
4 Six URLs inside the reproduced script output are dead (a 401 anonymous-review link, three 404s, a 502, a 403) Accepted as informational, not fixed. They are artifact links the papers themselves declared, reproduced verbatim inside a <file> block. Rewriting them would falsify the audit trail; the rot is the finding, and artifacts is the page about it
Tally 31 of 34 external claims verified correct, including every GitHub date via the commits API rather than pushed_at, the FIDO MDS 429 reproduced on three retries, and the Web Almanac's zero WebAuthn mentions

Pass 4 — generic, no checklist (fable)

No checklist, and it found the most. Thirteen findings; twelve accepted, one accepted as informational, none rejected outright — though two were accepted with a different fix than the one proposed.

# Finding Disposition
1 The headline denominators put the wrong numerator over the base. The page divided all 45 papers by the 1,622 web-platform papers and by the 1,120 that crawled. Only 42 carry the web platform label (the three operator-telemetry studies do not) and only 25 ran a crawl Accepted and fixed in the page, this log, and the namespace-page row. auth_report.mjs now prints the subsetted numerators, so the shares are 42/1,622 = 2.6% and 25/1,120 = 2.2%
2 “Only two papers publish the sites-with-a-login denominator” was contradicted by the page's own data, three times — Kuchhal's funnel (585 of 841) and Al Roomi's 358.9K login pages found in the CrUX 1M both publish a version of it, and “a small minority at 1M depth” is about a third Accepted and fixed. The bullet now names four papers and reads “about half the top 10K, about a third at 1M”. Also dropped “login availability correlates strongly with rank”, which the IMC study's own 51%-at-1K-and-51%-at-10K refutes
3 “At 1M depth the same phenomenon is 6–7%” — the 7.23% is at 100K, not 1M Accepted and fixed to “at 100K and 1M depth”
4 The intro promised login and password policy and the page had no section for it, despite that subgroup being the joint largest (12 papers) and the second read-first paper being a login-policy crawl whose figures appeared nowhere Accepted; the page gained a sixth question. Section 5 now carries the password-policy and login-policy crawls, password masking, login-page fingerprinting and alias handling. This was the largest single gap in the draft and no focused pass was looking for it
5 Account-creation scale overstated twice: “created accounts across 1,585,964 domains” when the paper crawled 1.5M, found 200K+ with signup and audited ~25K; and “at six figures” when the audited counts are five Accepted and fixed. The Cookie Hunter funnel is now stated in full, which makes the point better than the wrong version did: four denominators in one paper, all stated
6 Two scripts keyed a dict on slug alone. Two slugs occur twice in the corpus, so 5,859 records became 5,857 keys and two papers were silently dropped from the recall and absence sweeps Accepted and fixed. Both probes now key on (year, venue, slug) and assert that the key count equals the line count; the counts they print are 5,855 scanned + 4 without text = 5,859. Neither dropped paper was authentication-related, but the denominator was wrong and nothing would have caught it
7 This log overstated its own rigour in four places: a needle count that had moved from 84, a “never bare numbers” claim its own output contradicts, citation arithmetic that summed to 28 of 27, and a key count that was counting its own example Accepted and all four fixed. The last one is the most instructive: a citekey inside monospace markup is still a live citation, so the sentence claiming 51 distinct keys was itself the 52nd
8 “Every mention is incidental” had not been read — the absence probe prints titles and hit counts, not contexts Accepted and softened on both pages to “judged from their titles”, with the nearest exception named. The log's What could not be established now says plainly that I did not read all 39
9 Namespace-relative links. [[roadmap]] from provenance:security:authentication resolves to provenance:security:roadmap Accepted and fixed to [[:roadmap]] here and [[:security]] in the roadmap log. This is a recurring defect on this wiki and the reason scripts/sitemap.mjs checks red links site-wide
10 Three DokuWiki syntax risks: __Host- opening an underline inside monospace, the live citekey from finding 7, and angle-bracket pseudo-tags in inline code Accepted and all three escaped with .... Verified after saving by counting the rendered DOM's headings, tables and reference list rather than by reading the source
11 Six self-contradictions a reader would trip on, including “every instrument requires an account” against a section that says the opposite, “three method points” above five bullets, and “every paper creates an account” against a paper that read published documentation Accepted and all six fixed
12 The what-to-report checklist omitted the page's own most damning finding — that only 7 of 23 crawls say whether the profile kept state Accepted and fixed, along with adding list depth to the “date and list version” item
13 Small items: a stale placeholder, “two thirds” for 33/45, “roughly doubled” for 0.4%→1.1%, a four-figure list described as five, an extractor-default value quoted without a hedge, and an intro sentence that disowned attack papers while the population admits eight Accepted and fixed. The no-interaction hedge matters most: this wiki has already established that value is what the extractor reaches for when a paper is silent
“What works — do not touch”: the denominator table, the four-instrument passkey table, the tools table with observed HTTP states, the ethics section's three-defensible-answers framing, and this log's judgement-call table Left alone

What I caught myself, before the reviewers

Recorded because a page that only lists what reviewers found implies the author checked nothing:

  • “Nobody uses an off-the-shelf measurement framework.” OpenWPM really is zero; widening the check to Tracker Radar Collector, webXray and crawl4ai returned one paper. See Folds above. The claim now names its exception and is printed by the script.
  • Four absolute claims (“the only paper that…”, “only one paper publishes it”) were contradicted by the page's own citations two paragraphs later. Fixed before review; one of them ([22Ardi, Calvin; Calder, Matt (2023): "The Prevalence of Single Sign-On on the Web: Towards the Next Generation of Web Content Measurement", in: Proceedings of the ACM Internet Measurement Conference. (DOI)] and [23Chang, Li; Hsiao, Hsu-Chun; Jeng, Wei; Kim, Tiffany Hyun-Jin; Lin, Wei-Hsi (2017): "Security Implications of Redirection Trail in Popular Websites Worldwide", in: Proceedings of the ACM Web Conference. (DOI)] both publishing a sites-with-login denominator) had already been written into the same bullet that denied it.
  • Two corpus-wide absence claims — FedCM and enterprise SSO — were originally written as population-level statements and then stated as corpus-level facts. They now rest on scripts/auth_absence_probe.py, a full-text sweep of all 5,853 papers with extracted text: FedCM appears in one paper, three times, all of them a bibliography entry; enterprise identity products appear in 39, all incidentally. Without the sweep, “no paper measures FedCM” would have been a claim about 45 papers dressed as a claim about 5,859.

The Scripts, and Their Unedited Output

Committed under scripts/ in the working repository and reproduced here so the audit trail is readable without repository access. auth_pop.mjs is the one to read: it holds the inclusion rule, all 184 hand verdicts with their per-paper reasons, the citekey map, and the assertions that make every other script refuse to run if any of that drifts.

Six URLs inside the raw output below are dead (a 401, three 404s, a 502, a 403). They are artifact links the papers themselves declared, reproduced verbatim; the rot is the finding, and rewriting them would falsify the trail. artifacts is the page about that.

auth_pop.mjs

Probes, the inclusion rule, the 184 hand verdicts, the citekey map, and the assertions.

auth_pop.mjs
// security:authentication — candidate probes and the hand audit behind the page's population.
//
// The roadmap queued this page with "46 papers unaudited" from one title+summary probe
// (auth_tight in scripts/gap_probe2.mjs) and gated it on this audit. This script is that
// audit. It is deliberately one file: the probes, the hand verdicts and the assertions live
// together so a verdict cannot drift away from the candidate it judges.
//
// INCLUSION RULE, fixed before any figure was written (2026-09-11). A paper is IN the
// population iff all three hold:
//   1. object — it measures authentication AS DEPLOYED by services the authors do not
//      control: login pages, login/password policies, SSO/OAuth/OIDC/SAML, MFA/2FA/RBA,
//      passkeys/WebAuthn, account recovery, security notifications, or the session state a
//      login establishes;
//   2. unit — the measured unit is a population of >=10 such services, or an operator's own
//      production login telemetry. Not the authors' own testbed, not a library, not a
//      protocol model, not human participants;
//   3. question — it asks what is deployed / available / configured / how exposed, and
//      reports per-service incidence. A paper that exploits a flaw in a handful of systems,
//      analyses source code, or asks what users think is OUT even when it is about SSO.
// Posture audits count under (3) when they report incidence across a sampled population:
// "n of N relying parties were vulnerable" is a deployment figure.
//
// Every OUT verdict carries its own reason. There is no default reason string.
//
// This module owns the probes, the hand map and the assertions. scripts/auth_audit.mjs
// prints the audit; scripts/auth_report.mjs computes the page's figures. Both import
// audit() from here, so a verdict cannot be true for one script and false for the other.
 
import { loadExtractions } from './lib.mjs';
 
const rows = loadExtractions();
const T = (p) => `${p.title ?? ''} • ${p.summary ?? ''}`;
 
// ---------------------------------------------------------------------------
// Probes over title+summary. Each is a CANDIDATE generator, never a population.
// ---------------------------------------------------------------------------
const PROBES = {
  // as queued on the roadmap, verbatim from scripts/gap_probe2.mjs
  tight: (p) =>
    /(single sign-?on|\bSSO\b|OAuth|OpenID|SAML|WebAuthn|passkey|\bFIDO\b|multi-?factor|two-?factor|\b2FA\b|\bMFA\b)/i.test(T(p)),
  // added 2026-09-11: the tight probe names only the branded mechanisms. The literature that
  // measures login deployment without naming one of them (login policies, password policies,
  // login-page discovery, recovery, session cookies) is invisible to it.
  mechanism: (p) =>
    /\blog ?-?in\b|\blogins?\b|\bsign-?in\b|\bsign ?up\b|\bsigning in\b|identity provider|relying part|\bOTP\b|\bTOTP\b|one-?time (password|code|pin)|\bU2F\b|security key|passwordless|magic link|account recovery|password reset|forgot password|account takeover|credential stuffing|session (management|cookie|hijack|fixation|integrity|token)|password manager/i.test(T(p)),
  // added 2026-09-11 as a recall check on the two words the field uses when it does not name
  // a mechanism. Both are far too broad to be a population; restricted to the web platform so
  // the hand audit stays finite, and the residue is reported rather than hidden.
  authnweb: (p) => /\bauthenticat/i.test(T(p)) && p.platforms.includes('web'),
  accountweb: (p) => /\baccounts?\b/i.test(T(p)) && p.platforms.includes('web'),
  // added 2026-09-11 after scripts/auth_recall.py streamed every paper.cols.txt in the corpus
  // (whitespace collapsed) for the four mechanism families. 155 papers scored >= 8 full-text
  // hits without being a title+summary candidate; positive control: 39 of the 41 papers the
  // audit had already put in the population also score >= 8, so the probe can see what it is
  // testing. The 155 are in scripts/auth_recall-output.txt. Eleven whose titles left open the
  // possibility that the object was web authentication deployment were read; they are listed
  // here so the candidate pool equals the set actually judged. The other 144 were dismissed on
  // their titles alone — that is a weaker step than the rest of this audit and is recorded as
  // such on provenance:security:authentication.
  recall: (p) => RECALL_READ.includes(p.slug),
};
 
const RECALL_READ = [
  'investigating-the-password-policy-practices-of-website-administrators',
  'the-state-of-the-samesite-studying-the-usage-effectiveness-and-adequacy-of-sames',
  'cookies-lack-integrity-real-world-implications',
  'toward-mending-two-nation-scale-brokered-identification-systems',
  'unmasking-the-security-and-usability-of-password-masking',
  'an-empirical-study-evaluation-of-modern-captchas',
  'one-email-many-faces-a-deep-dive-into-identity-confusion-in-email-aliases',
  'practical-data-access-minimization-in-trigger-action-platforms',
  'experimental-security-analysis-of-the-app-model-in-business-collaboration-platfo',
  'shattered-chain-of-trust-understanding-security-risks-in-cross-cloud-iot-access',
  'back-to-school-on-the-in-security-of-academic-vpns',
];
 
// ---------------------------------------------------------------------------
// Hand verdicts. Key = a substring of the title that matches exactly one candidate.
// [code, subgroup, reason]. subgroup is '' for every OUT verdict.
// Subgroups: SSO, MFA (incl. RBA and security notifications), PASSKEY, LOGINSURF
// (login-page discovery, login/password policy, account creation), POSTLOGIN, OPERATOR.
// ---------------------------------------------------------------------------
const V = {
  // ---------------- IN: SSO / OAuth / OIDC / SAML deployment ----------------
  'devil is in the (implementation) details': ['IN', 'SSO', 'black-box tested 96 Facebook-login relying parties from Google’s top-1,000 list and reports per-RP flaw incidence'],
  'SSOScan': ['IN', 'SSO', 'crawled 20,000 Quantcast sites for Facebook SSO integration and five flaw classes; reports SSO prevalence and enrolment success rates'],
  'Why can’t users choose their identity providers': ['IN', 'SSO', 'manual audit of Alexa top 500 classifying which identity providers each relying party accepts'],
  'O Single Sign-Off': ['IN', 'SSO', 'Alexa 1M crawl for SSO adoption per identity provider, plus session-management audit of relying parties'],
  'Identity-Account Inconsistency': ['IN', 'SSO', 'tested SSO account binding on 100 of the Alexa top 1,000 plus Fortune-1000 and university identity policies'],
  'DISTINCT': ['IN', 'SSO', 'instrumented crawl of Tranco top 1,000 measuring dual-window SSO flows and in-browser message handling per site'],
  'Everybody\'s Looking for SSOmething': ['IN', 'SSO', 'CrUX 100k crawl measuring OAuth adoption and requested scopes per site'],
  'Towards Automated Auditing for Account and Session Management': ['IN', 'SSO', 'automated audit of Facebook-SSO relying parties drawn from Majestic 100k for registration, revocation and session practices'],
  'Prevalence of Single Sign-On on the Web': ['IN', 'SSO', 'live crawls of CrUX top 1k/10k measuring login and third-party SSO prevalence with DOM and logo detection'],
  'Only as Strong as the Weakest Link': ['IN', 'SSO', 'measures brokered-SSO prevalence from a Tranco-derived SSO traffic dataset and audits the brokers found'],
  'Universal Cross-app Attacks': ['IN', 'SSO', 'black-box tested OAuth 2.0 configuration across 18 integration platforms and reports per-platform incidence; population is platforms, not websites'],
  'Connecting the Dots: An Investigative Study': ['IN', 'SSO', 'built 85,053 authentication webpages from Korean login-path keywords and measured KakaoTalk account-linking integration on 14,102 of them'],
 
  // ---------------- IN: MFA / 2FA / risk-based authentication ----------------
  'Is Real-time Phishing Eliminated with FIDO': ['IN', 'MFA', 'audited which second factors and fallbacks Alexa top-100 sites offer alongside FIDO'],
  'Consistency of Two-Factor Authentication User Journeys': ['IN', 'MFA', 'two coders walked the full 2FA journey on 85 popular websites and coded factor consistency per site'],
  'We\'ve Disabled MFA for You': ['IN', 'MFA', 'audited MFA recovery documentation for 1,303 sites from 2fa.directory and tested recovery on 71'],
  'Multi-Factor and Risk-Based Authentication Availability': ['IN', 'MFA', 'created accounts and audited MFA, RBA and suspicious-login response on popular websites'],
  'Phish in Sheep\'s Clothing': ['IN', 'MFA', 'audited which login pages fingerprint the browser as a risk signal, across an Alexa-ranked population and 300 services'],
  'Who is Trying to Access My Account': ['IN', 'MFA', 'triggered risk-based-authentication paths on 251 websites and coded the 161 notifications they produced'],
  'Was This You?': ['IN', 'MFA', 'created accounts on Tranco top-100 sites, executed a suspicious login, and coded the 21 notification emails that arrived'],
 
  // ---------------- IN: passkeys / WebAuthn ----------------
  'Security Posture of Real-World FIDO2 Deployments': ['IN', 'PASSKEY', 'audited FIDO2 configuration at Tranco top-1k relying parties and tracked the FIDO metadata service longitudinally'],
  'The State of Passkeys': ['IN', 'PASSKEY', 'continuous passkey discovery over Tranco 1M and CrUX 18M, 208 confirmed implementations hand-audited, 103 security-tested'],
  'SoK: Web Authentication and Recovery': ['IN', 'PASSKEY', 'hand-audited passkey support across an Alexa top-300 sample alongside the recovery mechanisms of 22 end-to-end-encrypted providers'],
  'Framework for Abusability Analysis': ['IN', 'PASSKEY', 'stepped through passkey registration, portability, deletion and revocation on a Tranco 200 sample'],
  'How Not to Handle Keys': ['IN', 'PASSKEY', 'crawled the Cisco Umbrella 1M for navigator.credentials WebAuthn use and found 684 records; the earliest WebAuthn census in this corpus'],
  'Anchors of Trust': ['IN', 'PASSKEY', 'manually evaluated cross-device authentication as deployed by 27 services before the user half of the study'],
 
  // ---------------- IN: the login surface (pages, policies, account creation) ----------------
  'Redirection Trail': ['IN', 'LOGINSURF', 'located login pages across Alexa top-10k and top-1M and measured HTTPS posture of the login POST; reports how many sites offer login at all'],
  'Cookie Hunter': ['IN', 'LOGINSURF', 'automated account creation across 1.58M Alexa domains, then audited authentication-cookie and HSTS flaws per site'],
  'Pre-hijacked accounts': ['IN', 'LOGINSURF', 'manually tested account-creation and authentication workflows on 75 popular services for five pre-hijacking classes'],
  'Large-Scale Measurement of Website Login Policies': ['IN', 'LOGINSURF', 'automated account creation and login on CrUX top 1M to measure login policy per site'],
  'Measuring Website Password Creation Policies': ['IN', 'LOGINSURF', 'automated signups across Tranco-ranked domains, varying passwords to infer each site’s policy'],
  'Double Edged Sword': ['IN', 'LOGINSURF', 'crawled CrUX-ranked sites to identify authentication pages and then measured fingerprinting on them'],
  'Poster: Security of Login Interfaces': ['IN', 'LOGINSURF', 'scanned 73,431 login-page URLs belonging to 100 European companies; a poster, so treat the figures as preliminary'],
  'QR Code-based Login': ['IN', 'LOGINSURF', 'measured QR-login prevalence and workflow security across ranked websites'],
  'Stealing Trust': ['IN', 'LOGINSURF', 'probed wallet-based Web3 login APIs at 27 sites across 29 cases; the newest login mechanism anyone in this corpus measured'],
  'Survey of Account Security Interfaces': ['IN', 'LOGINSURF', 'scripted login sessions on 100 popular services and hand-coded what each account-security interface exposes'],
 
  // ---------------- IN: what a login leaves behind ----------------
  'To Auth or Not To Auth': ['IN', 'POSTLOGIN', 'paired authenticated and unauthenticated crawls of 200 popular sites, comparing XSS, headers, JavaScript and postMessage behind the login'],
  'Cookie Crumbles': ['IN', 'POSTLOGIN', 'measured cookie-prefix (__Host-/__Secure-) adoption in HTTP Archive data alongside a framework audit'],
 
  // ---------------- IN: operator-side login telemetry ----------------
  'Secrets, Lies, and Account Recovery': ['IN', 'OPERATOR', 'Google’s own secret-answer and recovery telemetry: recovery as deployed, measured from inside'],
  'Evaluating Login Challenges': ['IN', 'OPERATOR', 'Google login and recovery traces measuring how often challenges stop hijacking and how often they stop legitimate users'],
  'Empirical Measurement of Systemic 2FA Usability': ['IN', 'OPERATOR', '32M + 6M Duo 2FA log events and 17,085 support tickets from two mandatory university deployments'],
  'Gossamer': ['IN', 'OPERATOR', 'instrumented the production login systems of two universities for 3-7 months, 34M requests'],
 
  // ---------------- IN: added by the full-text recall probe ----------------
  'Unmasking the Security and Usability of Password Masking': ['IN', 'LOGINSURF', 'audited password-field masking as deployed on 100 CrUX top-1K domains before the participant studies'],
  'One Email, Many Faces': ['IN', 'LOGINSURF', 'tested how 18 platforms and 28 mail providers resolve alias addresses at signup, login and recovery — identifier handling as deployed'],
  'The State of the SameSite': ['IN', 'POSTLOGIN', 'longitudinal SameSite adoption across Alexa 500K plus breakage tests; the session-cookie hardening half of the post-login surface'],
  'Cookies Lack Integrity': ['IN', 'POSTLOGIN', 'Alexa 1M crawl for the shared-domain and HSTS conditions that let an attacker inject a session cookie'],
 
  // ---------------- OUT: read because of the recall probe, and rejected ----------------
  'Password Policy Practices of Website Administrators': ['USER', '', 'surveys and interviews 11 administrators about the policies they chose; the deployed policy itself is measured by the two Al Roomi crawls'],
  'Nation-Scale Brokered Identification': ['SYSTEM', '', 'privacy analysis and redesign of the GOV.UK Verify and Connect.gov hub designs; the extraction labels it simulation-or-theory-only with no measured population'],
  'Modern CAPTCHAs': ['ADJACENT', '', 'inspects CAPTCHA prevalence on 200 popular sites, but a bot challenge guards many flows and is not a claim about an identity; programming:registration owns CAPTCHA and this page points there'],
  'Data Access Minimization in Trigger-Action Platforms': ['ADJACENT', '', 'OAuth scopes inside IFTTT rules; the unit is a trigger-action rule, not a login'],
  'App Model in Business Collaboration Platforms': ['ADJACENT', '', 'OAuth app permissions in Slack and Teams directories; delegated authorization between apps rather than a user logging in'],
  'Shattered Chain of Trust': ['ADJACENT', '', 'OAuth-style access delegation between ten IoT clouds; the device-cloud population belongs with IoT, not web login'],
  'Academic VPNs': ['ADJACENT', '', 'VPN gateway and client authentication at universities; not a browser login surface'],
 
  // ---------------- OUT: the probe matched a different sense of the word ----------------
  'Fashion crimes': ['HOMONYM', '', 'MFA here is "Made for AdSense", the paper’s own expansion; it is a search-spam measurement'],
  'HybridEval': ['HOMONYM', '', 'the OpenID match is inside "OpenIDEO", the design-idea platform the paper samples from'],
  'EmpMFF': ['HOMONYM', '', '"multi-factor" is a sequence-fusion architecture for empathetic response generation'],
  'On Measuring RPKI Relying Parties': ['HOMONYM', '', 'a relying party in RPKI is a route-origin validator, not an SSO relying party'],
  'Behind the Scenes of RPKI': ['HOMONYM', '', 'measures RPKI relying-party software deployment among network operators, a different relying party entirely'],
  'Poster: RPKI Kill Switch': ['HOMONYM', '', 'poster on RPKI validator failure modes; the relying party is a route validator'],
  'Landscape of RPKI Relying Parties': ['HOMONYM', '', 'surveys which RPKI validator implementations operators run; nothing to do with web login'],
  'Stalloris': ['HOMONYM', '', 'RPKI relying-party downgrade attack, not web login'],
  'Signing in Four Public Software Package Registries': ['HOMONYM', '', '"signing" is package signing in PyPI/Maven/Docker Hub/Hugging Face, not signing in'],
  'Watching TV with the Second-Party': ['HOMONYM', '', 'matched on an incidental "sign-in" in a smart-TV ACR tracking study; Connected TV is its own roadmap item'],
  'Sheep\'s clothing, wolfish intent': ['HOMONYM', '', 'matched on "authenticat" inside an ad-review study; the object is problematic advertisements'],
 
  // ---------------- OUT: passwords as secrets, and password managers ----------------
  'Measuring password guessability for an entire university': ['PASSWORD', '', 'the university SSO system is only where the 42,563 passwords came from; the object is guessability'],
  'Science of Guessing': ['PASSWORD', '', '70M-password corpus analysis; no deployment measured'],
  'Passwords Are Not Always Stronger': ['PASSWORD', '', 'password strength across sites of different value, not what those sites deploy'],
  'Towards Reliable Storage of 56-bit Secrets': ['PASSWORD', '', 'human memory for secrets; a lab study'],
  'password discretization for click-based graphical passwords': ['PASSWORD', '', 'graphical-password scheme analysis'],
  'Multiple-Password Interference': ['PASSWORD', '', 'lab study of a geographic password scheme'],
  'Forgetting of Passwords': ['PASSWORD', '', 'memory model of password recall'],
  'Beyond Credential Stuffing': ['PASSWORD', '', 'password-similarity models; the population is leaked credentials'],
  'Don\'t Forget the Stuffing': ['PASSWORD', '', 'security impact of typo-tolerant checking, evaluated on leaked password sets'],
  'Araña': ['PASSWORD', '', 'characterises guessing attacks seen by two universities; the object is the attack traffic, not the deployment'],
  'Protecting accounts from credential stuffing': ['PASSWORD', '', 'a breach-alerting protocol and its Chrome deployment, not a measurement of others’ deployments'],
  'PassREfinder': ['PASSWORD', '', 'predicts credential-stuffing risk from password reuse; no authentication deployment measured'],
  'Neuroscience Meets Cryptography': ['PASSWORD', '', 'implicit-learning authentication primitive, lab only'],
  'Picture Gesture Authentication': ['PASSWORD', '', 'Windows 8 picture-password scheme security'],
  'Gesture Authentication for Smartphones': ['PASSWORD', '', 'gesture-password selection policies on phones'],
  'Emperor’s New Password Manager': ['PWMANAGER', '', 'security analysis of five web password managers; the object is the manager'],
  'Password Managers: Attacks and Defenses': ['PWMANAGER', '', 'browser password-manager autofill attacks'],
  'That Was Then, This Is Now': ['PWMANAGER', '', 'password-manager generation/storage/autofill evaluation'],
  'Analyzing the Usability of Popular Smartphone Password Managers': ['PWMANAGER', '', 'usability of mobile password managers'],
  'Why Older Adults (Don\'t) Use Password Managers': ['PWMANAGER', '', 'interview study of adoption'],
  'Why Users (Don\'t) Use Password Managers at a Large Educational Institution': ['PWMANAGER', '', 'survey of adoption inside one institution'],
  'started using the other': ['PWMANAGER', '', 'interview study of switching managers'],
  'Exploiting Leakage in Password Managers': ['PWMANAGER', '', 'injection attacks against managers'],
  'Master-Password-Protected Password Management': ['PWMANAGER', '', 'protocol analysis of manager sync'],
  'Zero Knowledge (About) Encryption': ['PWMANAGER', '', 'cryptographic analysis of three cloud password managers'],
  'Vault Raider': ['PWMANAGER', '', 'desktop UI attacks against managers'],
  'Phishing Attacks against Password Manager Browser Extensions': ['PWMANAGER', '', 'attacks on manager extensions; extension measurement is privacy:browser_extensions'],
  'They Would do Better if They Worked Together': ['PWMANAGER', '', 'tests 15 manager extensions against 39 minimal examples; the unit is the manager, not a site population'],
 
  // ---------------- OUT: libraries, SDKs, frameworks, protocol models ----------------
  'On Breaking SAML': ['LIB', '', 'XML-signature-wrapping attacks against 14 SAML frameworks; the unit is the framework'],
  'Explicating SDKs': ['LIB', '', 'formal models of three authentication SDKs plus applications the authors picked'],
  'Vetting Single Sign-On SDK Implementations': ['LIB', '', 'symbolic execution of ten SSO SDKs'],
  'Cerberus': ['LIB', '', 'static analysis of 22 open-source OAuth server libraries'],
  'AuthSaber': ['LIB', '', 'program verification of 15 OpenID Connect libraries'],
  'A Formal Analysis of the FIDO UAF Protocol': ['LIB', '', 'ProVerif model plus Android app analysis; the unit is the protocol and the app'],
  'URL-based Authentication Bypass': ['LIB', '', 'static scan of 529 Java web applications; source code, not deployments'],
  'AUTHSCOPE': ['LIB', '', 'mutates authorization fields in 4,838 Android apps’ backends; mobile app-server pairs'],
 
  // ---------------- OUT: an attack, or a flaw hunt without population incidence ----------------
  'Signing Me onto Your Accounts': ['ATTACK', '', 'eight logic flaws found in a handful of high-profile IdPs and RPs; foundational, but no measured population'],
  'Clickjacking: Attacks and Defenses': ['ATTACK', '', 'OAuth appears as one attack scenario in Mechanical Turk experiments'],
  'OAuth Demystified': ['ATTACK', '', 'OAuth flaws in 600 Android apps; mobile, and the unit is the app'],
  'oauth access token abuse by collusion networks': ['ATTACK', '', 'measures an abuse ecosystem that consumes OAuth tokens, not the deployment of OAuth'],
  'Breaching Security Keys without Root': ['ATTACK', '', 'overlay deception against FIDO2 authenticators on Android'],
  'Password Reset MitM': ['ATTACK', '', 'an attack on reset flows, with a small hand-picked set of services and a participant study'],
  'missing authentication vulnerabilities in the wild': ['ATTACK', '', 'IPv4-wide scan for services with no authentication at all; network services, not web login (security:web_vulnerabilities territory)'],
  '403 Forbidden?': ['ATTACK', '', 'broken access control after login on 100 sites; authorization rather than authentication'],
  'Cross-Origin State Inference': ['ATTACK', '', 'XS-Leaks that reveal login state; the deployment measured is the leak, not the login'],
  'ALPACA': ['ATTACK', '', 'TLS application-layer protocol confusion'],
  'STEK Sharing is Not Caring': ['ATTACK', '', 'TLS session-ticket key sharing; transport, not web login'],
  'Breaking Authentication in DTLS-SRTP': ['ATTACK', '', 'WebRTC media-path authentication'],
  'When HTTPS Meets CDN': ['ATTACK', '', 'certificate delegation between site and CDN; security:tls_certificates territory'],
  'Automated detection of session fixation': ['ATTACK', '', 'a detection technique evaluated on applications the authors chose'],
  'SessionJuggler': ['SYSTEM', '', 'a login-from-untrusted-terminal system, not a measurement'],
  'Unexpected Dangers of Dynamic JavaScript': ['ATTACK', '', 'script-based data exfiltration; privacy:javascript territory'],
  'Malicious CAPTCHA Attack': ['ATTACK', '', 'a CAPTCHA-based attack, not authentication deployment'],
  'Messy States of Wiring': ['ATTACK', '', 'payment-system integration flaws'],
  'Hijackers Guide To The Galaxy': ['ATTACK', '', 'off-path resource hijacking; network layer'],
  'Fashion Faux Pas': ['ATTACK', '', 'fingerprinting evasion; privacy:fingerprinting territory'],
  'Cached and Confused': ['ATTACK', '', 'web cache deception; the auth match is incidental'],
 
  // ---------------- OUT: a system or defence the authors built ----------------
  'Sound-Proof': ['SYSTEM', '', 'a proposed second factor, evaluated in the lab'],
  'SWAT': ['SYSTEM', '', 'a proposed canvas-based authentication scheme'],
  'Let’s Authenticate': ['SYSTEM', '', 'a proposed certificate-based user authentication system'],
  'WPSE': ['SYSTEM', '', 'a browser-side defence; the authors state their Alexa 100k crawl "is not meant to provide a comprehensive coverage of the deployment of OAuth 2.0" — its IdP counts are cited on the page as a by-product, not as a census'],
  'Detecting Compromise of Passkey Storage': ['SYSTEM', '', 'a detection scheme for cloud passkey stores, simulation only'],
  'Passwords and FIDO2 Are Meant To Be Secret': ['SYSTEM', '', 'a proposed secure channel for browsers'],
  'Secondary Authentication Factor Manager': ['SYSTEM', '', 'a prototype manager; the nine-site audit is background for the design'],
  'Quite a mess in my cookie jar': ['SYSTEM', '', 'a classifier for authentication cookies validated on 70 sites; an instrument owned by programming:registration, cited on the page as a method'],
  'Tripwire': ['SYSTEM', '', 'honey accounts registered to detect site compromise; the object is breach detection'],
  'Detecting Structurally Anomalous Logins': ['SYSTEM', '', 'enterprise login-graph anomaly detection on internal logs'],
 
  // ---------------- OUT: the object is what people think or do ----------------
  'horrible key ring thing': ['USER', '', 'interviews with 21 UK banking customers'],
  'If HTTPS Were Secure': ['USER', '', 'mental-model interviews; 2FA appears only in a participant quote'],
  'FIDO2 Biometric WebAuthn': ['USER', '', 'three Prolific studies of misconceptions'],
  'Driving 2FA Adoption at Scale': ['USER', '', 'randomised notification experiments on Facebook users; an intervention study, not a deployment census'],
  'Is FIDO2 the Kingslayer': ['USER', '', 'comparative usability study'],
  'Why Aren\'t We Using Passkeys': ['USER', '', '32 expert interviews about deployment obstacles; cited on the page as the best evidence for why the curves are flat, but it measures no deployment'],
  'Broken Access: On the Challenges of Screen Reader': ['USER', '', 'accessibility evaluation of 12 authentication method types with six screen readers; the unit is the method, not a site population'],
  'Account Security Interfaces: Important, Unintuitive': ['USER', '', 'IPV clinic transcripts plus interface tests on four services; below the 10-service floor'],
  'Authentication Melee': ['USER', '', 'usability comparison of seven authentication schemes on a mock site; the unit is the scheme'],
  'Should I Worry?': ['USER', '', 'cross-cultural survey of incident response'],
  'Make Them Change it Every Week': ['USER', '', 'qualitative analysis of developer advice online'],
  'Third-Party Application Access for Google Accounts': ['USER', '', 'perception study of OAuth third-party access'],
  'Moving Beyond Set-It-And-Forget-It': ['USER', '', 'social-media privacy settings study'],
  'Phishing Susceptibility and the (In-)Effectiveness': ['USER', '', 'phishing-intervention field study in a hospital'],
  'Hidden in Plain Bytes': ['USER', '', 'interpersonal account compromise investigated through data exports'],
 
  // ---------------- OUT: abuse, fraud and account markets ----------------
  'Dissecting one click frauds': ['ABUSE', '', 'one-click fraud sites in Japan'],
  '@spam': ['ABUSE', '', 'Twitter spam accounts'],
  'Re: CAPTCHAs': ['ABUSE', '', 'CAPTCHA-solving services as a market'],
  'Dialing Back Abuse on Phone Verified Accounts': ['ABUSE', '', 'phone-verified account abuse at Google; the object is the abuse market'],
  'EVILCOHORT': ['ABUSE', '', 'malicious account communities'],
  'Towards Detecting Anomalous User Behavior': ['ABUSE', '', 'OSN behaviour anomaly detection'],
  'Man vs. Machine': ['ABUSE', '', 'crowdsourced abuse workers'],
  'An Army of Me': ['ABUSE', '', 'sockpuppets in discussion communities'],
  'Fifteen minutes of unwanted fame': ['ABUSE', '', 'detects and characterises doxing posts; matched on an incidental account mention'],
  'Hack for Hire': ['ABUSE', '', 'the account-hijacking services market'],
  'Stealthy Porn': ['ABUSE', '', 'illicit promotion imagery'],
  'Into the Deep Web': ['ABUSE', '', 'e-commerce fraud interviews with criminals'],
  'Sunrise to Sunset': ['ABUSE', '', 'phishing lifecycle; security:phishing territory'],
  'Behind the Tube': ['ABUSE', '', 'YouTube monetisation abuse'],
  'Ban Evasion': ['ABUSE', '', 'ban evasion on Wikipedia'],
  'TxPhishScope': ['ABUSE', '', 'Ethereum transaction phishing'],
  'Photography-based Multi-Feature Sybil Detection': ['ABUSE', '', 'Sybil detection from photo metadata'],
  'Buy and Sale of Social Media Accounts': ['ABUSE', '', 'account resale markets'],
  'Chameleon Channels': ['ABUSE', '', 'repurposed YouTube channels'],
  'Analyzing the AI Nudification': ['ABUSE', '', 'nudification app ecosystem'],
  'Doppelgänger Finder': ['ABUSE', '', 'stylometry on underground forums'],
  'role of web hosting providers': ['ABUSE', '', 'compromised-site remediation by hosters'],
  'Traveling the silk road': ['ABUSE', '', 'marketplace measurement'],
  'Understanding the Dark Side of Domain Parking': ['ABUSE', '', 'parked-domain monetisation chains; matched on the parking services’ account plumbing'],
  'Automated Detection of Automated Traffic': ['ABUSE', '', 'bot detection at an operator; programming:crawler_detection territory'],
  'Phishing Attacks on Modern Android': ['ABUSE', '', 'mobile UI phishing that harvests credentials; the unit is the Android app, not a web deployment'],
 
  // ---------------- OUT: another page on this wiki owns it ----------------
  'Exploiting TLS Client Authentication': ['ADJACENT', '', 'TLS client certificates as a tracking vector; privacy:fingerprinting and security:tls_certificates'],
  'XRay': ['ADJACENT', '', 'targeting transparency through account inputs; design:platforms'],
  'Checking Websites’ GDPR Consent Compliance for Marketing Emails': ['ADJACENT', '', 'newsletter consent; privacy:email_tracking and privacy:consent'],
  'Leave No Data Behind': ['ADJACENT', '', 'data erasure requests; the queued privacy:data_subject_rights page'],
  'Left or Right': ['ADJACENT', '', 'spam-filter bias; privacy:email_tracking'],
  'Warranted and Unwarranted Emails': ['ADJACENT', '', 'email classification poster'],
  'End-to-End Encrypted Cloud Storage': ['ADJACENT', '', 'cryptographic analysis of storage providers; the SoK covers its authentication angle'],
  'Swipe Left for Identity Theft': ['ADJACENT', '', 'dating-app data exposure; design:mobile_and_app_measurement'],
  'Echoes of Privacy': ['ADJACENT', '', 'voice-assistant profiling'],
  'Scraping Sticky Leftovers': ['ADJACENT', '', 'data left after account deletion; privacy:data_subject_rights'],
  'No Way to Sign Out': ['ADJACENT', '', 'app account-deletion compliance; design:mobile_and_app_measurement'],
  'Security and Privacy Failures in Popular 2FA Apps': ['ADJACENT', '', '22 Android TOTP apps; the unit is the app, so design:mobile_and_app_measurement'],
  'SMS One-Time Password Messages against Local Attackers': ['ADJACENT', '', 'Android OTP interception'],
};
 
 
// Citekeys in literature:bibliography for every paper in the population, hand-keyed by title
// substring exactly like the verdicts above. audit() throws if a population paper has no key,
// so the page cannot cite a paper the bibliography does not carry, and cannot silently drop one.
export const KEYS = {
  'devil is in the (implementation) details': 'sun2012_devil',
  'SSOScan': 'zhou2014_ssoscan',
  'Why can’t users choose their identity providers': 'corre2017_users',
  'O Single Sign-Off': 'ghasemisharif2018_sso',
  'Identity-Account Inconsistency': 'liu2021_investigation',
  'DISTINCT': 'jannett2022_distinct',
  'Everybody\'s Looking for SSOmething': 'dimova2023_ssomething',
  'Towards Automated Auditing for Account and Session Management': 'ghasemisharif2022_saat',
  'Prevalence of Single Sign-On on the Web': 'ardi2023_prevalence',
  'Only as Strong as the Weakest Link': 'innocenti2025_only',
  'Universal Cross-app Attacks': 'luo2025_universal',
  'Connecting the Dots: An Investigative Study': 'kang2026_connecting',
  'Is Real-time Phishing Eliminated with FIDO': 'ulqinaku2021_real',
  'Consistency of Two-Factor Authentication User Journeys': 'lyastani2023_systematic',
  'We\'ve Disabled MFA for You': 'klivan2023_disabled',
  'Multi-Factor and Risk-Based Authentication Availability': 'gavazzi2023_multi',
  'Phish in Sheep\'s Clothing': 'lin2022_sheep',
  'Who is Trying to Access My Account': 'wei2025_trying',
  'Was This You?': 'sahin2025_this',
  'Security Posture of Real-World FIDO2 Deployments': 'kuchhal2023_evaluating',
  'The State of Passkeys': 'jannett2026_passkeys',
  'SoK: Web Authentication and Recovery': 'blessing2025_authentication',
  'Framework for Abusability Analysis': 'daffalla2025_framework',
  'How Not to Handle Keys': 'kepkowski2022_handle',
  'Anchors of Trust': 'zhang2026_anchors',
  'Redirection Trail': 'chang2017_security',
  'Cookie Hunter': 'drakonakis2020_cookie',
  'Pre-hijacked accounts': 'sudhodanan2022_hijacked',
  'Large-Scale Measurement of Website Login Policies': 'alroomi2023_login',
  'Measuring Website Password Creation Policies': 'alroomi2023_password',
  'Double Edged Sword': 'senol2024_double',
  'Poster: Security of Login Interfaces': 'tchokodeu2024_poster',
  'QR Code-based Login': 'zhang2025_qrcode',
  'Stealing Trust': 'yan2024_stealing',
  'Survey of Account Security Interfaces': 'bhattacharya2026_asi',
  'Unmasking the Security and Usability of Password Masking': 'hu2024_unmasking',
  'One Email, Many Faces': 'wu2026_email',
  'To Auth or Not To Auth': 'rautenstrauch2024_auth',
  'Cookie Crumbles': 'squarcina2023_cookie',
  'The State of the SameSite': 'khodayari2022_state',
  'Cookies Lack Integrity': 'zheng2015_cookies',
  'Secrets, Lies, and Account Recovery': 'bonneau2015_secrets',
  'Evaluating Login Challenges': 'doerfler2019_evaluating',
  'Empirical Measurement of Systemic 2FA Usability': 'reynolds2020_systemic',
  'Gossamer': 'bohuk2022_gossamer',
};
 
// ---------------------------------------------------------------------------
// Resolve the hand map against the candidate set, and refuse to return if it drifts.
// ---------------------------------------------------------------------------
export const SUBGROUPS = ['SSO', 'MFA', 'PASSKEY', 'LOGINSURF', 'POSTLOGIN', 'OPERATOR'];
export { rows, T, PROBES, V as VERDICTS };
export const fired = (p) => Object.entries(PROBES).filter(([, f]) => f(p)).map(([k]) => k);
 
export function audit() {
  const candidates = rows.filter((p) => fired(p).length > 0);
  const bySlug = new Map();
  const unmatchedKeys = [];
  const ambiguousKeys = [];
  for (const [key, verdict] of Object.entries(V)) {
    const hits = candidates.filter((p) => (p.title ?? '').includes(key));
    if (hits.length === 0) { unmatchedKeys.push(key); continue; }
    if (hits.length > 1) { ambiguousKeys.push([key, hits.map((h) => h.title)]); continue; }
    const p = hits[0];
    if (bySlug.has(p.slug)) throw new Error(`two hand-map keys match one paper: ${p.slug}`);
    bySlug.set(p.slug, { key, verdict, p });
  }
  const unjudged = candidates.filter((p) => !bySlug.has(p.slug));
  const IN = [...bySlug.values()].filter((x) => x.verdict[0] === 'IN');
  const keyEntries = Object.entries(KEYS);
  const usedKeys = new Set();
  for (const x of IN) {
    const hit = keyEntries.filter(([sub]) => (x.p.title ?? '').includes(sub));
    if (hit.length === 1) { x.citekey = hit[0][1]; usedKeys.add(hit[0][0]); }
    else x.citekey = null;
  }
 
  const problems = [];
  if (unmatchedKeys.length) problems.push(`hand-map keys matching no candidate: ${unmatchedKeys.join(' | ')}`);
  if (ambiguousKeys.length) problems.push(`ambiguous hand-map keys: ${ambiguousKeys.map(([k]) => k).join(' | ')}`);
  if (unjudged.length) problems.push(`candidates without a verdict: ${unjudged.map((p) => p.slug).join(' | ')}`);
  if (bySlug.size !== candidates.length) problems.push(`judged ${bySlug.size} of ${candidates.length} candidates`);
  for (const x of IN) if (!SUBGROUPS.includes(x.verdict[1])) problems.push(`IN paper with no subgroup: ${x.p.slug}`);
  for (const x of IN) if (!x.citekey) problems.push(`population paper with no citekey (or an ambiguous one): ${x.p.slug}`);
  const dupKeys = IN.map((x) => x.citekey).filter((k, i, a) => a.indexOf(k) !== i);
  if (dupKeys.length) problems.push(`one citekey used for two population papers: ${[...new Set(dupKeys)].join(' ')}`);
  for (const [sub] of keyEntries) if (!usedKeys.has(sub)) problems.push(`KEYS entry matching no population paper: ${sub}`);
  for (const x of bySlug.values()) if (x.verdict[0] !== 'IN' && x.verdict[1] !== '') problems.push(`OUT paper carrying a subgroup: ${x.p.slug}`);
  for (const x of bySlug.values()) if (!x.verdict[2] || x.verdict[2].length < 20) problems.push(`verdict reason too short to be a reason: ${x.p.slug}`);
  const reasons = [...bySlug.values()].map((x) => x.verdict[2]);
  if (new Set(reasons).size !== reasons.length) {
    const dup = reasons.filter((r, i) => reasons.indexOf(r) !== i);
    problems.push(`repeated verdict reason (a canned reason is not evidence): ${[...new Set(dup)].join(' / ')}`);
  }
  if (problems.length) {
    for (const p of problems) console.error(`AUDIT ASSERTION FAILED: ${p}`);
    throw new Error(`${problems.length} audit assertion(s) failed; refusing to return a population`);
  }
  return { candidates, bySlug, IN };
}

auth_audit.mjs

The audit report, including the numbers that answer the roadmap gate.

auth_audit.mjs
// security:authentication — prints the candidate audit behind the page's population.
//
// The roadmap queued this page with "46 papers unaudited" from a single title+summary probe
// (auth_tight in scripts/gap_probe2.mjs) and gated writing it on this audit. This script is
// that audit's report; the probes, the inclusion rule, the per-paper verdicts and the
// assertions live in scripts/auth_pop.mjs, which every consumer imports so a verdict cannot
// be true for one script and false for another.
//
// Usage: node scripts/auth_audit.mjs [--csv]
 
import { rows, PROBES, SUBGROUPS, audit } from './auth_pop.mjs';
 
const { candidates, bySlug, IN } = audit();
 
console.log('=== security:authentication — candidate audit ===');
console.log(`corpus: ${rows.length} extracted papers (data/extract/run1)`);
console.log('');
console.log('probe                  candidates  web-platform');
for (const [name, f] of Object.entries(PROBES)) {
  const h = rows.filter(f);
  console.log(`${name.padEnd(22)} ${String(h.length).padStart(10)}  ${String(h.filter((p) => p.platforms.includes('web')).length).padStart(12)}`);
}
console.log(`${'UNION (candidates)'.padEnd(22)} ${String(candidates.length).padStart(10)}  ${String(candidates.filter((p) => p.platforms.includes('web')).length).padStart(12)}`);
console.log('');
 
const byCode = new Map();
for (const { verdict } of bySlug.values()) byCode.set(verdict[0], (byCode.get(verdict[0]) ?? 0) + 1);
console.log('verdict        papers   share of candidates');
[...byCode.entries()].sort((a, b) => b[1] - a[1]).forEach(([c, n]) =>
  console.log(`${c.padEnd(14)} ${String(n).padStart(6)}   ${((n / candidates.length) * 100).toFixed(1)}%`));
 
console.log('');
console.log(`POPULATION: ${IN.length} papers of ${candidates.length} candidates (${((IN.length / candidates.length) * 100).toFixed(1)}%); ${candidates.length - IN.length} excluded`);
console.log('');
console.log('subgroup      papers');
const byGrp = new Map();
for (const x of IN) byGrp.set(x.verdict[1], (byGrp.get(x.verdict[1]) ?? 0) + 1);
for (const g of SUBGROUPS) console.log(`${g.padEnd(13)} ${String(byGrp.get(g) ?? 0).padStart(6)}`);
// The roadmap's gate was stated against the tight probe's own 46 candidates, so the numbers
// that answer it are printed here rather than derived by hand on three different pages.
const branded = IN.filter((x) => ['SSO', 'MFA', 'PASSKEY'].includes(x.verdict[1]));
const tightCands = [...bySlug.values()].filter((x) => PROBES.tight(x.p));
const tightIn = tightCands.filter((x) => x.verdict[0] === 'IN');
console.log(`\nthe roadmap's gate was ~20 papers measuring deployment, counted against the tight probe's 46:`);
console.log(`  tight-probe candidates: ${tightCands.length}; of those IN the population: ${tightIn.length}`);
console.log(`  branded-mechanism slice (SSO + MFA + PASSKEY): ${branded.length}; of those caught by the tight probe: ${branded.filter((x) => PROBES.tight(x.p)).length}`);
console.log(`  whole population as scoped here: ${IN.length}`);
 
console.log('');
console.log('population by year (2025-2026 are provisional venue-years, see literature:corpus)');
const yr = new Map();
for (const x of IN) yr.set(x.p.year, (yr.get(x.p.year) ?? 0) + 1);
[...yr.entries()].sort().forEach(([y, n]) => console.log(`  ${y}  ${'#'.repeat(n)} ${n}`));
console.log('population by venue');
const vn = new Map();
for (const x of IN) vn.set(x.p.venue, (vn.get(x.p.venue) ?? 0) + 1);
[...vn.entries()].sort((a, b) => b[1] - a[1]).forEach(([v, n]) => console.log(`  ${v.padEnd(8)} ${n}`));
console.log('population by platform label');
const pl = new Map();
for (const x of IN) for (const t of x.p.platforms) pl.set(t, (pl.get(t) ?? 0) + 1);
[...pl.entries()].sort((a, b) => b[1] - a[1]).forEach(([v, n]) => console.log(`  ${v.padEnd(22)} ${n}`));
 
console.log('');
console.log('--- the population, by subgroup, with the reason each paper is in it ---');
for (const g of SUBGROUPS) {
  console.log(`\n[${g}]`);
  IN.filter((x) => x.verdict[1] === g).sort((a, b) => a.p.year - b.p.year)
    .forEach((x) => console.log(`  ${x.p.year} ${x.p.venue.padEnd(8)} ${x.p.title}\n      ${x.verdict[2]}`));
}
 
console.log('\n--- excluded, with the reason per paper ---');
for (const code of [...byCode.keys()].filter((c) => c !== 'IN').sort()) {
  console.log(`\n[${code}] ${byCode.get(code)} papers`);
  [...bySlug.values()].filter((x) => x.verdict[0] === code).sort((a, b) => a.p.year - b.p.year)
    .forEach((x) => console.log(`  ${x.p.year} ${x.p.venue.padEnd(8)} ${x.p.title}\n      ${x.verdict[2]}`));
}
 
console.log(`\nASSERTIONS PASSED: ${candidates.length} candidates, all judged; ${IN.length} in population; every verdict reason distinct.`);
 
if (process.argv.includes('--csv')) {
  console.log('\nslug,year,venue,code,subgroup');
  for (const x of bySlug.values()) console.log(`${x.p.slug},${x.p.year},${x.p.venue},${x.verdict[0]},${x.verdict[1]}`);
}

auth_audit-output.txt

Unedited output of the audit, including every verdict with its own reason.

auth_audit-output.txt
=== security:authentication — candidate audit ===
corpus: 5859 extracted papers (data/extract/run1)
 
probe                  candidates  web-platform
tight                          46            37
mechanism                      68            42
authnweb                       50            50
accountweb                     57            57
recall                         11             7
UNION (candidates)            184           147
 
verdict        papers   share of candidates
IN                 45   24.5%
ABUSE              26   14.1%
ATTACK             20   10.9%
ADJACENT           18   9.8%
USER               16   8.7%
PASSWORD           15   8.2%
PWMANAGER          13   7.1%
SYSTEM             12   6.5%
HOMONYM            11   6.0%
LIB                 8   4.3%
 
POPULATION: 45 papers of 184 candidates (24.5%); 139 excluded
 
subgroup      papers
SSO               12
MFA                7
PASSKEY            6
LOGINSURF         12
POSTLOGIN          4
OPERATOR           4
 
the roadmap's gate was ~20 papers measuring deployment, counted against the tight probe's 46:
  tight-probe candidates: 46; of those IN the population: 22
  branded-mechanism slice (SSO + MFA + PASSKEY): 25; of those caught by the tight probe: 21
  whole population as scoped here: 45
 
population by year (2025-2026 are provisional venue-years, see literature:corpus)
  2012  # 1
  2014  # 1
  2015  ## 2
  2017  ## 2
  2018  # 1
  2019  # 1
  2020  ## 2
  2021  ## 2
  2022  ####### 7
  2023  ######### 9
  2024  ##### 5
  2025  ####### 7
  2026  ##### 5
population by venue
  USENIX   16
  CCS      9
  NDSS     6
  WWW      5
  PETS     4
  IEEE-SP  4
  IMC      1
population by platform label
  web                    42
  other-online-service   11
  mobile                 9
  offline                3
  iot                    1
 
--- the population, by subgroup, with the reason each paper is in it ---
 
[SSO]
  2012 CCS      The devil is in the (implementation) details: an empirical analysis of OAuth SSO systems.
      black-box tested 96 Facebook-login relying parties from Google’s top-1,000 list and reports per-RP flaw incidence
  2014 USENIX   SSOScan: Automated Testing of Web Applications for Single Sign-On Vulnerabilities
      crawled 20,000 Quantcast sites for Facebook SSO integration and five flaw classes; reports SSO prevalence and enrolment success rates
  2017 PETS     Why can’t users choose their identity providers on the web?
      manual audit of Alexa top 500 classifying which identity providers each relying party accepts
  2018 USENIX   O Single Sign-Off, Where Art Thou? An Empirical Analysis of Single Sign-On Account Hijacking and Session Management on the Web
      Alexa 1M crawl for SSO adoption per identity provider, plus session-management audit of relying parties
  2021 WWW      An Investigation of Identity-Account Inconsistency in Single Sign-On.
      tested SSO account binding on 100 of the Alexa top 1,000 plus Fortune-1000 and university identity policies
  2022 CCS      DISTINCT: Identity Theft using In-Browser Communications in Dual-Window Single Sign-On.
      instrumented crawl of Tranco top 1,000 measuring dual-window SSO flows and in-browser message handling per site
  2022 IEEE-SP  Towards Automated Auditing for Account and Session Management Flaws in Single Sign-On Deployments.
      automated audit of Facebook-SSO relying parties drawn from Majestic 100k for registration, revocation and session practices
  2023 PETS     Everybody's Looking for SSOmething: A large-scale evaluation on the privacy of OAuth authentication on the web
      CrUX 100k crawl measuring OAuth adoption and requested scopes per site
  2023 IMC      The Prevalence of Single Sign-On on the Web: Towards the Next Generation of Web Content Measurement.
      live crawls of CrUX top 1k/10k measuring login and third-party SSO prevalence with DOM and logo detection
  2025 IEEE-SP  "Only as Strong as the Weakest Link": On the Security of Brokered Single Sign-On on the Web.
      measures brokered-SSO prevalence from a Tranco-derived SSO traffic dataset and audits the brokers found
  2025 USENIX   Universal Cross-app Attacks: Exploiting and Securing OAuth 2.0 in Integration Platforms
      black-box tested OAuth 2.0 configuration across 18 integration platforms and reports per-platform incidence; population is platforms, not websites
  2026 NDSS     Connecting the Dots: An Investigative Study on Linking Private User Data Across Messaging Apps
      built 85,053 authentication webpages from Korean login-path keywords and measured KakaoTalk account-linking integration on 14,102 of them
 
[MFA]
  2021 USENIX   Is Real-time Phishing Eliminated with FIDO? Social Engineering Downgrade Attacks against FIDO Protocols
      audited which second factors and fallbacks Alexa top-100 sites offer alongside FIDO
  2022 USENIX   Phish in Sheep's Clothing: Exploring the Authentication Pitfalls of Browser Fingerprinting
      audited which login pages fingerprint the browser as a risk signal, across an Alexa-ranked population and 300 services
  2023 NDSS     A Systematic Study of the Consistency of Two-Factor Authentication User Journeys on Top-Ranked Websites
      two coders walked the full 2FA journey on 85 popular websites and coded factor consistency per site
  2023 CCS      "We've Disabled MFA for You": An Evaluation of the Security and Usability of Multi-Factor Authentication Recovery Deployments.
      audited MFA recovery documentation for 1,303 sites from 2fa.directory and tested recovery on 71
  2023 USENIX   A Study of Multi-Factor and Risk-Based Authentication Availability
      created accounts and audited MFA, RBA and suspicious-login response on popular websites
  2025 NDSS     ”Who is Trying to Access My Account?” Exploring User Perceptions and Reactions to Risk-based Authentication Notifications
      triggered risk-based-authentication paths on 251 websites and coded the 161 notifications they produced
  2025 NDSS     Was This You? Investigating the Design Considerations for Suspicious Login Notifications
      created accounts on Tranco top-100 sites, executed a suspicious login, and coded the 21 notification emails that arrived
 
[PASSKEY]
  2022 PETS     How Not to Handle Keys: Timing Attacks on FIDO Authenticator Privacy
      crawled the Cisco Umbrella 1M for navigator.credentials WebAuthn use and found 684 records; the earliest WebAuthn census in this corpus
  2023 CCS      Evaluating the Security Posture of Real-World FIDO2 Deployments.
      audited FIDO2 configuration at Tranco top-1k relying parties and tracked the FIDO metadata service longitudinally
  2025 PETS     SoK: Web Authentication and Recovery in the Age of End-to-End Encryption
      hand-audited passkey support across an Alexa top-300 sample alongside the recovery mechanisms of 22 end-to-end-encrypted providers
  2025 USENIX   A Framework for Abusability Analysis: The Case of Passkeys in Interpersonal Threat Models
      stepped through passkey registration, portability, deletion and revocation on a Tranco 200 sample
  2026 USENIX   The State of Passkeys: Studying the Adoption and Security of Passkeys on the Web
      continuous passkey discovery over Tranco 1M and CrUX 18M, 208 confirmed implementations hand-audited, 103 security-tested
  2026 NDSS     Anchors of Trust: A Usability Study on User Awareness, Consent, and Control in Cross-Device Authentication
      manually evaluated cross-device authentication as deployed by 27 services before the user half of the study
 
[LOGINSURF]
  2017 WWW      Security Implications of Redirection Trail in Popular Websites Worldwide.
      located login pages across Alexa top-10k and top-1M and measured HTTPS posture of the login POST; reports how many sites offer login at all
  2020 CCS      The Cookie Hunter: Automated Black-box Auditing for Web Authentication and Authorization Flaws.
      automated account creation across 1.58M Alexa domains, then audited authentication-cookie and HSTS flaws per site
  2022 USENIX   Pre-hijacked accounts: An Empirical Study of Security Failures in User Account Creation on the Web
      manually tested account-creation and authentication workflows on 75 popular services for five pre-hijacking classes
  2023 USENIX   A Large-Scale Measurement of Website Login Policies
      automated account creation and login on CrUX top 1M to measure login policy per site
  2023 CCS      Measuring Website Password Creation Policies At Scale.
      automated signups across Tranco-ranked domains, varying passwords to infer each site’s policy
  2024 WWW      The Double Edged Sword: Identifying Authentication Pages and their Fingerprinting Behavior.
      crawled CrUX-ranked sites to identify authentication pages and then measured fingerprinting on them
  2024 CCS      Poster: Security of Login Interfaces in Modern Organizations.
      scanned 73,431 login-page URLs belonging to 100 European companies; a poster, so treat the figures as preliminary
  2024 CCS      Stealing Trust: Unraveling Blind Message Attacks in Web3 Authentication.
      probed wallet-based Web3 login APIs at 27 sites across 29 cases; the newest login mechanism anyone in this corpus measured
  2024 CCS      Unmasking the Security and Usability of Password Masking.
      audited password-field masking as deployed on 100 CrUX top-1K domains before the participant studies
  2025 USENIX   Demystifying the (In)Security of QR Code-based Login in Real-world Deployments
      measured QR-login prevalence and workflow security across ranked websites
  2026 USENIX   Inconsistent, Incomplete, and Insecure: A Survey of Account Security Interfaces
      scripted login sessions on 100 popular services and hand-coded what each account-security interface exposes
  2026 NDSS     One Email, Many Faces: A Deep Dive into Identity Confusion in Email Aliases
      tested how 18 platforms and 28 mail providers resolve alias addresses at signup, login and recovery — identifier handling as deployed
 
[POSTLOGIN]
  2015 USENIX   Cookies Lack Integrity: Real-World Implications
      Alexa 1M crawl for the shared-domain and HSTS conditions that let an attacker inject a session cookie
  2022 IEEE-SP  The State of the SameSite: Studying the Usage, Effectiveness, and Adequacy of SameSite Cookies.
      longitudinal SameSite adoption across Alexa 500K plus breakage tests; the session-cookie hardening half of the post-login surface
  2023 USENIX   Cookie Crumbles: Breaking and Fixing Web Session Integrity
      measured cookie-prefix (__Host-/__Secure-) adoption in HTTP Archive data alongside a framework audit
  2024 IEEE-SP  To Auth or Not To Auth? A Comparative Analysis of the Pre- and Post-Login Security Landscape.
      paired authenticated and unauthenticated crawls of 200 popular sites, comparing XSS, headers, JavaScript and postMessage behind the login
 
[OPERATOR]
  2015 WWW      Secrets, Lies, and Account Recovery: Lessons from the Use of Personal Knowledge Questions at Google.
      Google’s own secret-answer and recovery telemetry: recovery as deployed, measured from inside
  2019 WWW      Evaluating Login Challenges as aDefense Against Account Takeover.
      Google login and recovery traces measuring how often challenges stop hijacking and how often they stop legitimate users
  2020 USENIX   Empirical Measurement of Systemic 2FA Usability
      32M + 6M Duo 2FA log events and 17,085 support tickets from two mandatory university deployments
  2022 USENIX   Gossamer: Securely Measuring Password-based Logins
      instrumented the production login systems of two universities for 3-7 months, 34M requests
 
--- excluded, with the reason per paper ---
 
[ABUSE] 26 papers
  2010 CCS      Dissecting one click frauds.
      one-click fraud sites in Japan
  2010 CCS      @spam: the underground on 140 characters or less.
      Twitter spam accounts
  2010 USENIX   Re: CAPTCHAs—Understanding CAPTCHA-Solving Services in an Economic Context
      CAPTCHA-solving services as a market
  2013 WWW      The role of web hosting providers in detecting compromised websites.
      compromised-site remediation by hosters
  2013 WWW      Traveling the silk road: a measurement analysis of a large anonymous online marketplace.
      marketplace measurement
  2014 CCS      Dialing Back Abuse on Phone Verified Accounts.
      phone-verified account abuse at Google; the object is the abuse market
  2014 USENIX   Towards Detecting Anomalous User Behavior in Online Social Networks
      OSN behaviour anomaly detection
  2014 USENIX   Man vs. Machine: Practical Adversarial Detection of Malicious Crowdsourcing Workers
      crowdsourced abuse workers
  2014 IEEE-SP  Doppelgänger Finder: Taking Stylometry to the Underground.
      stylometry on underground forums
  2014 USENIX   Understanding the Dark Side of Domain Parking
      parked-domain monetisation chains; matched on the parking services’ account plumbing
  2015 USENIX   EVILCOHORT: Detecting Communities of Malicious Accounts on Online Services
      malicious account communities
  2017 WWW      An Army of Me: Sockpuppets in Online Discussion Communities.
      sockpuppets in discussion communities
  2017 IMC      Fifteen minutes of unwanted fame: detecting and characterizing doxing.
      detects and characterises doxing posts; matched on an incidental account mention
  2018 CCS      Phishing Attacks on Modern Android.
      mobile UI phishing that harvests credentials; the unit is the Android app, not a web deployment
  2019 WWW      Hack for Hire: Exploring the Emerging Market for Account Hijacking.
      the account-hijacking services market
  2019 IEEE-SP  Stealthy Porn: Understanding Real-World Adversarial Images for Illicit Online Promotion.
      illicit promotion imagery
  2020 NDSS     Into the Deep Web: Understanding E-commerce Fraud from Autonomous Chat with Cybercriminals
      e-commerce fraud interviews with criminals
  2020 USENIX   Sunrise to Sunset: Analyzing the End-to-end Life Cycle and Effectiveness of Phishing Attacks at Scale
      phishing lifecycle; security:phishing territory
  2022 USENIX   Behind the Tube: Exploitative Monetization of Content on YouTube
      YouTube monetisation abuse
  2022 WWW      Characterizing, Detecting, and Predicting Online Ban Evasion.
      ban evasion on Wikipedia
  2022 USENIX   Automated Detection of Automated Traffic
      bot detection at an operator; programming:crawler_detection territory
  2023 CCS      TxPhishScope: Towards Detecting and Understanding Transaction-based Phishing on Ethereum.
      Ethereum transaction phishing
  2023 PETS     Detect Your Fingerprint in Your Photographs: Photography-based Multi-Feature Sybil Detection
      Sybil detection from photo metadata
  2025 IMC      Exploration of the Dynamics of Buy and Sale of Social Media Accounts.
      account resale markets
  2025 USENIX   Analyzing the AI Nudification Application Ecosystem
      nudification app ecosystem
  2026 USENIX   Chameleon Channels: Measuring YouTube Accounts Repurposed for Deception and Profit
      repurposed YouTube channels
 
[ADJACENT] 18 papers
  2014 USENIX   XRay: Enhancing the Web’s Transparency with Differential Correlation
      targeting transparency through account inputs; design:platforms
  2018 PETS     Exploiting TLS Client Authentication for Widespread User Tracking
      TLS client certificates as a tracking vector; privacy:fingerprinting and security:tls_certificates
  2020 USENIX   Shattered Chain of Trust: Understanding Security Risks in Cross-Cloud IoT Access Delegation
      OAuth-style access delegation between ten IoT clouds; the device-cloud population belongs with IoT, not web login
  2021 NDSS     On the Insecurity of SMS One-Time Password Messages against Local Attackers in Modern Mobile Devices
      Android OTP interception
  2022 USENIX   Practical Data Access Minimization in Trigger-Action Platforms
      OAuth scopes inside IFTTT rules; the unit is a trigger-action rule, not a login
  2022 USENIX   Experimental Security Analysis of the App Model in Business Collaboration Platforms
      OAuth app permissions in Slack and Teams directories; delegated authorization between apps rather than a user logging in
  2022 PETS     Checking Websites’ GDPR Consent Compliance for Marketing Emails
      newsletter consent; privacy:email_tracking and privacy:consent
  2022 PETS     Leave No Data Behind – Empirical Insights into Data Erasure from Online Services
      data erasure requests; the queued privacy:data_subject_rights page
  2022 WWW      Left or Right: A Peek into the Political Biases in Email Spam Filtering Algorithms During US Election 2020.
      spam-filter bias; privacy:email_tracking
  2022 IEEE-SP  Scraping Sticky Leftovers: App User Information Left on Servers After Account Deletion.
      data left after account deletion; privacy:data_subject_rights
  2023 USENIX   An Empirical Study & Evaluation of Modern CAPTCHAs
      inspects CAPTCHA prevalence on 200 popular sites, but a bot challenge guards many flows and is not a claim about an identity; programming:registration owns CAPTCHA and this page points there
  2023 USENIX   Back to School: On the (In)Security of Academic VPNs
      VPN gateway and client authentication at universities; not a browser login surface
  2023 CCS      Poster: Towards a Dataset for the Discrimination between Warranted and Unwarranted Emails.
      email classification poster
  2023 USENIX   Security and Privacy Failures in Popular 2FA Apps
      22 Android TOTP apps; the unit is the app, so design:mobile_and_app_measurement
  2024 CCS      End-to-End Encrypted Cloud Storage in the Wild: A Broken Ecosystem.
      cryptographic analysis of storage providers; the SoK covers its authentication angle
  2024 USENIX   Swipe Left for Identity Theft: An Analysis of User Data Privacy Risks on Location-based Dating Apps
      dating-app data exposure; design:mobile_and_app_measurement
  2025 PETS     Echoes of Privacy: Uncovering the Profiling Practices of Voice Assistants
      voice-assistant profiling
  2025 USENIX   No Way to Sign Out? Unpacking Non-Compliance with Google Play's App Account Deletion Requirements
      app account-deletion compliance; design:mobile_and_app_measurement
 
[ATTACK] 20 papers
  2010 WWW      Automated detection of session fixation vulnerabilities.
      a detection technique evaluated on applications the authors chose
  2012 IEEE-SP  Signing Me onto Your Accounts through Facebook and Google: A Traffic-Guided Security Study of Commercially Deployed Single-Sign-On Web Services.
      eight logic flaws found in a handful of high-profile IdPs and RPs; foundational, but no measured population
  2012 USENIX   Clickjacking: Attacks and Defenses
      OAuth appears as one attack scenario in Mechanical Turk experiments
  2014 CCS      OAuth Demystified for Mobile Application Developers.
      OAuth flaws in 600 Android apps; mobile, and the unit is the app
  2014 IEEE-SP  When HTTPS Meets CDN: A Case of Authentication in Delegated Service.
      certificate delegation between site and CDN; security:tls_certificates territory
  2015 USENIX   The Unexpected Dangers of Dynamic JavaScript
      script-based data exfiltration; privacy:javascript territory
  2016 WWW      Tell Me About Yourself: The Malicious CAPTCHA Attack.
      a CAPTCHA-based attack, not authentication deployment
  2017 IMC      Measuring and mitigating oauth access token abuse by collusion networks.
      measures an abuse ecosystem that consumes OAuth tokens, not the deployment of OAuth
  2017 IEEE-SP  The Password Reset MitM Attack.
      an attack on reset flows, with a small hand-picked set of services and a participant study
  2020 NDSS     Cross-Origin State Inference (COSI) Attacks: Leaking Web Site States through XS-Leaks
      XS-Leaks that reveal login state; the deployment measured is the leak, not the login
  2020 USENIX   Cached and Confused: Web Cache Deception in the Wild
      web cache deception; the auth match is incidental
  2021 USENIX   ALPACA: Application Layer Protocol Confusion - Analyzing and Mitigating Cracks in TLS Authentication
      TLS application-layer protocol confusion
  2021 USENIX   Messy States of Wiring: Vulnerabilities in Emerging Personal Payment Systems
      payment-system integration flaws
  2021 USENIX   The Hijackers Guide To The Galaxy: Off-Path Taking Over Internet Resources
      off-path resource hijacking; network layer
  2022 IMC      No keys to the kingdom required: a comprehensive investigation of missing authentication vulnerabilities in the wild.
      IPv4-wide scan for services with no authentication at all; network services, not web login (security:web_vulnerabilities territory)
  2023 IEEE-SP  Fashion Faux Pas: Implicit Stylistic Fingerprints for Bypassing Browsers' Anti-Fingerprinting Defenses.
      fingerprinting evasion; privacy:fingerprinting territory
  2024 CCS      Breaching Security Keys without Root: FIDO2 Deception Attacks via Overlays exploiting Limited Display Authenticators.
      overlay deception against FIDO2 authenticators on Android
  2025 IEEE-SP  403 Forbidden? Ethically Evaluating Broken Access Control in the Wild.
      broken access control after login on 100 sites; authorization rather than authentication
  2025 USENIX   STEK Sharing is Not Caring: Bypassing TLS Authentication in Web Servers using Session Tickets
      TLS session-ticket key sharing; transport, not web login
  2026 USENIX   Analyzing the WebRTC Ecosystem and Breaking Authentication in DTLS-SRTP
      WebRTC media-path authentication
 
[HOMONYM] 11 papers
  2011 CCS      Fashion crimes: trending-term exploitation on the web.
      MFA here is "Made for AdSense", the paper’s own expansion; it is a search-spam measurement
  2020 IMC      On Measuring RPKI Relying Parties.
      a relying party in RPKI is a route-origin validator, not an SSO relying party
  2022 CCS      Behind the Scenes of RPKI.
      measures RPKI relying-party software deployment among network operators, a different relying party entirely
  2022 CCS      Poster: RPKI Kill Switch.
      poster on RPKI validator failure modes; the relying party is a route validator
  2022 USENIX   Stalloris: RPKI Downgrade Attack
      RPKI relying-party downgrade attack, not web login
  2023 WWW      HybridEval: A Human-AI Collaborative Approach for Evaluating Design Ideas at Scale.
      the OpenID match is inside "OpenIDEO", the design-idea platform the paper samples from
  2023 WWW      EmpMFF: A Multi-factor Sequence Fusion Framework for Empathetic Response Generation.
      "multi-factor" is a sequence-fusion architecture for empathetic response generation
  2024 IEEE-SP  Signing in Four Public Software Package Registries: Quantity, Quality, and Influencing Factors.
      "signing" is package signing in PyPI/Maven/Docker Hub/Hugging Face, not signing in
  2024 IMC      Watching TV with the Second-Party: A First Look at Automatic Content Recognition Tracking in Smart TVs.
      matched on an incidental "sign-in" in a smart-TV ACR tracking study; Connected TV is its own roadmap item
  2025 CCS      Poster: Exploring the Landscape of RPKI Relying Parties.
      surveys which RPKI validator implementations operators run; nothing to do with web login
  2025 PETS     Sheep's clothing, wolfish intent: Automated detection and evaluation of problematic 'allowed' advertisements
      matched on "authenticat" inside an ad-review study; the object is problematic advertisements
 
[LIB] 8 papers
  2012 USENIX   On Breaking SAML: Be Whoever You Want to Be
      XML-signature-wrapping attacks against 14 SAML frameworks; the unit is the framework
  2013 USENIX   Explicating SDKs:  Uncovering Assumptions Underlying Secure Authentication and Authorization
      formal models of three authentication SDKs plus applications the authors picked
  2017 CCS      AUTHSCOPE: Towards Automatic Discovery of Vulnerable Authorizations in Online Services.
      mutates authorization fields in 4,838 Android apps’ backends; mobile app-server pairs
  2018 USENIX   Vetting Single Sign-On SDK Implementations via Symbolic Reasoning
      symbolic execution of ten SSO SDKs
  2021 NDSS     A Formal Analysis of the FIDO UAF Protocol
      ProVerif model plus Android app analysis; the unit is the protocol and the app
  2022 CCS      Cerberus: Query-driven Scalable Vulnerability Detection in OAuth Service Provider Implementations.
      static analysis of 22 open-source OAuth server libraries
  2024 CCS      AuthSaber: Automated Safety Verification of OpenID Connect Programs.
      program verification of 15 OpenID Connect libraries
  2025 CCS      Be Aware of What You Let Pass: Demystifying URL-based Authentication Bypass Vulnerability in Java Web Applications.
      static scan of 529 Java web applications; source code, not deployments
 
[PASSWORD] 15 papers
  2012 IEEE-SP  The Science of Guessing: Analyzing an Anonymized Corpus of 70 Million Passwords.
      70M-password corpus analysis; no deployment measured
  2012 USENIX   Neuroscience Meets Cryptography: Designing Crypto Primitives Secure Against Rubber Hose Attacks
      implicit-learning authentication primitive, lab only
  2013 CCS      Measuring password guessability for an entire university.
      the university SSO system is only where the 42,563 passwords came from; the object is guessability
  2013 WWW      Security implications of password discretization for click-based graphical passwords.
      graphical-password scheme analysis
  2013 USENIX   On the Security of Picture Gesture Authentication
      Windows 8 picture-password scheme security
  2014 USENIX   Towards Reliable Storage of 56-bit Secrets in Human Memory
      human memory for secrets; a lab study
  2015 NDSS     Passwords Are Not Always Stronger on the Other Side of the Fence
      password strength across sites of different value, not what those sites deploy
  2015 NDSS     Multiple-Password Interference in the GeoPass User Authentication Scheme
      lab study of a geographic password scheme
  2018 USENIX   Forgetting of Passwords: Ecological Theory and Data
      memory model of password recall
  2019 IEEE-SP  Beyond Credential Stuffing: Password Similarity Models Using Neural Networks.
      password-similarity models; the population is leaked credentials
  2019 USENIX   Protecting accounts from credential stuffing with password breach alerting
      a breach-alerting protocol and its Chrome deployment, not a measurement of others’ deployments
  2020 IEEE-SP  Gesture Authentication for Smartphones: Evaluation of Gesture Password Selection Policies.
      gesture-password selection policies on phones
  2021 CCS      Don't Forget the Stuffing! Revisiting the Security Impact of Typo-Tolerant Password Authentication.
      security impact of typo-tolerant checking, evaluated on leaked password sets
  2023 USENIX   Araña: Discovering and Characterizing Password Guessing Attacks in Practice
      characterises guessing attacks seen by two universities; the object is the attack traffic, not the deployment
  2024 IEEE-SP  PassREfinder: Credential Stuffing Risk Prediction by Representing Password Reuse between Websites on a Graph.
      predicts credential-stuffing risk from password reuse; no authentication deployment measured
 
[PWMANAGER] 13 papers
  2014 USENIX   The Emperor’s New Password Manager: Security Analysis of Web-based Password Managers
      security analysis of five web password managers; the object is the manager
  2014 USENIX   Password Managers: Attacks and Defenses
      browser password-manager autofill attacks
  2019 CCS      "I don't see why I would ever want to use it": Analyzing the Usability of Popular Smartphone Password Managers.
      usability of mobile password managers
  2020 USENIX   That Was Then, This Is Now: A Security Evaluation of Password Generation, Storage, and Autofill in Browser-Based Password Managers
      password-manager generation/storage/autofill evaluation
  2021 USENIX   Why Older Adults (Don't) Use Password Managers
      interview study of adoption
  2021 IEEE-SP  They Would do Better if They Worked Together: The Case of Interaction Problems Between Password Managers and Websites.
      tests 15 manager extensions against 39 minimal examples; the unit is the manager, not a site population
  2022 USENIX   Why Users (Don't) Use Password Managers at a Large Educational Institution
      survey of adoption inside one institution
  2023 CCS      "I just stopped using one and started using the other": Motivations, Techniques, and Challenges When Switching Password Managers.
      interview study of switching managers
  2024 USENIX   Exploiting Leakage in Password Managers via Injection Attacks
      injection attacks against managers
  2025 IEEE-SP  Security Analysis of Master-Password-Protected Password Management Protocols.
      protocol analysis of manager sync
  2025 USENIX   Phishing Attacks against Password Manager Browser Extensions
      attacks on manager extensions; extension measurement is privacy:browser_extensions
  2026 USENIX   Zero Knowledge (About) Encryption: A Comparative Security Analysis of Three Cloud-based Password Managers
      cryptographic analysis of three cloud password managers
  2026 NDSS     Vault Raider: Stealthy UI-based Attacks Against Password Managers in Desktop Environments
      desktop UI attacks against managers
 
[SYSTEM] 12 papers
  2012 WWW      SessionJuggler: secure web login from an untrusted terminal using session hijacking.
      a login-from-untrusted-terminal system, not a measurement
  2014 WWW      Quite a mess in my cookie jar!: leveraging machine learning to protect web authentication.
      a classifier for authentication cookies validated on 70 sites; an instrument owned by programming:registration, cited on the page as a method
  2015 PETS     Toward Mending Two Nation-Scale Brokered Identification Systems
      privacy analysis and redesign of the GOV.UK Verify and Connect.gov hub designs; the extraction labels it simulation-or-theory-only with no measured population
  2015 USENIX   Sound-Proof: Usable Two-Factor Authentication Based on Ambient Sound
      a proposed second factor, evaluated in the lab
  2017 IMC      Tripwire: inferring internet site compromise.
      honey accounts registered to detect site compromise; the object is breach detection
  2017 CCS      Detecting Structurally Anomalous Logins Within Enterprise Networks.
      enterprise login-graph anomaly detection on internal logs
  2018 USENIX   WPSE: Fortifying Web Protocols via Browser-Side Security Monitoring
      a browser-side defence; the authors state their Alexa 100k crawl "is not meant to provide a comprehensive coverage of the deployment of OAuth 2.0" — its IdP counts are cited on the page as a by-product, not as a census
  2019 WWW      SWAT: Seamless Web Authentication Technology.
      a proposed canvas-based authentication scheme
  2022 NDSS     Let’s Authenticate: Automated Certificates for User Authentication
      a proposed certificate-based user authentication system
  2023 USENIX   "If I could do this, I feel anyone could:" The Design and Evaluation of a Secondary Authentication Factor Manager
      a prototype manager; the nine-site audit is background for the design
  2025 USENIX   Detecting Compromise of Passkey Storage on the Cloud
      a detection scheme for cloud passkey stores, simulation only
  2025 CCS      Passwords and FIDO2 Are Meant To Be Secret: A Practical Secure Authentication Channel for Web Browsers.
      a proposed secure channel for browsers
 
[USER] 16 papers
  2015 NDSS     “They brought in the horrible key ring thing!” Analysing the Usability of Two-Factor Authentication in UK Online Banking
      interviews with 21 UK banking customers
  2015 WWW      Authentication Melee: A Usability Analysis of Seven Web Authentication Systems.
      usability comparison of seven authentication schemes on a mock site; the unit is the scheme
  2019 IEEE-SP  "If HTTPS Were Secure, I Wouldn't Need 2FA" - End User and Administrator Mental Models of HTTPS.
      mental-model interviews; 2FA appears only in a participant quote
  2019 IEEE-SP  "Should I Worry?" A Cross-Cultural Examination of Account Security Incident Response.
      cross-cultural survey of incident response
  2019 CCS      Moving Beyond Set-It-And-Forget-It Privacy Settings on Social Media.
      social-media privacy settings study
  2020 IEEE-SP  Is FIDO2 the Kingslayer of User Authentication? A Comparative Usability Study of FIDO2 Passwordless Authentication.
      comparative usability study
  2021 USENIX   "It's Stored, Hopefully, on an Encrypted Server'': Mitigating Users' Misconceptions About FIDO2 Biometric WebAuthn
      three Prolific studies of misconceptions
  2021 USENIX   Driving 2FA Adoption at Scale: Optimizing Two-Factor Authentication Notification Design Patterns
      randomised notification experiments on Facebook users; an intervention study, not a deployment census
  2022 USENIX   Security and Privacy Perceptions of Third-Party Application Access for Google Accounts
      perception study of OAuth third-party access
  2023 IEEE-SP  Investigating the Password Policy Practices of Website Administrators.
      surveys and interviews 11 administrators about the policies they chose; the deployed policy itself is measured by the two Al Roomi crawls
  2023 USENIX   Account Security Interfaces: Important, Unintuitive, and Untrustworthy
      IPV clinic transcripts plus interface tests on four services; below the 10-service floor
  2023 CCS      "Make Them Change it Every Week!": A Qualitative Exploration of Online Developer Advice on Usable and Secure Authentication.
      qualitative analysis of developer advice online
  2024 USENIX   Why Aren't We Using Passkeys? Obstacles Companies Face Deploying FIDO2 Passwordless Authentication
      32 expert interviews about deployment obstacles; cited on the page as the best evidence for why the curves are flat, but it measures no deployment
  2025 WWW      Broken Access: On the Challenges of Screen Reader Assisted Two-Factor and Passwordless Authentication.
      accessibility evaluation of 12 authentication method types with six screen readers; the unit is the method, not a site population
  2025 CCS      Phishing Susceptibility and the (In-)Effectiveness of Common Anti-Phishing Interventions in a Large University Hospital.
      phishing-intervention field study in a hospital
  2025 CCS      Hidden in Plain Bytes: Investigating Interpersonal Account Compromise with Data Exports.
      interpersonal account compromise investigated through data exports
 
ASSERTIONS PASSED: 184 candidates, all judged; 45 in population; every verdict reason distinct.

auth_report.mjs

Every figure on the page, with its denominator, plus the 45-paper table generator.

auth_report.mjs
// security:authentication — every figure the page publishes, with its denominator.
//
// Population: the 45 papers whose verdict is IN in scripts/auth_pop.mjs (the hand audit of
// 184 candidates). Counts are of PAPERS. Sentinels (not-stated / none-mentioned) are printed
// as themselves and never folded into a stated value. Base rates for the whole corpus and for
// the 1,622 web-platform papers are printed next to any share of the population, because a
// share that matches the base rate is not a finding about this literature.
//
// Usage: node scripts/auth_report.mjs [--prevalence] [--quotes]
 
import { rows, audit, SUBGROUPS } from './auth_pop.mjs';
import { POPULATIONS, isSentinel } from './lib.mjs';
 
const { candidates, IN } = audit();
const pop = IN.map((x) => x.p);
const grp = new Map(IN.map((x) => [x.p.slug, x.verdict[1]]));
const web = rows.filter((p) => p.platforms.includes('web'));
const crawled = rows.filter(POPULATIONS.crawled);
 
const pct = (n, d) => (d === 0 ? 'n/a' : `${((n / d) * 100).toFixed(1)}%`);
const h = (s) => console.log(`\n===== ${s} =====`);
 
console.log('security:authentication — report');
console.log(`corpus: ${rows.length} extracted papers, 7 venues, 2010-2026 (data/extract/run1)`);
console.log(`candidates from five probes: ${candidates.length}`);
console.log(`POPULATION (hand audit, inclusion rule in scripts/auth_pop.mjs): ${pop.length} papers`);
// Denominators have to be honest in both directions: 45/1622 would put three papers that are
// not web-platform papers over the web-platform denominator, and 45/1120 would put twenty
// papers that ran no crawl over the crawl denominator. Both numerators are subsetted first.
const popWeb = pop.filter((p) => p.platforms.includes('web'));
const popCrawled = pop.filter(POPULATIONS.crawled);
console.log(`  web-platform: ${popWeb.length} of the ${pop.length} population papers = ${pct(popWeb.length, web.length)} of the ${web.length} web-platform papers`);
console.log(`  ran a crawl:  ${popCrawled.length} of the ${pop.length} population papers = ${pct(popCrawled.length, crawled.length)} of the ${crawled.length} papers that ran a crawl`);
console.log(`  have a crawlConfig object: ${pop.filter((p) => p.crawlConfig !== null).length} of ${pop.length} (the denominator for every crawlConfig share below)`);
console.log(`  2022 or later: ${pop.filter((p) => p.year >= 2022).length} of ${pop.length}`);
 
h('1. Population shape');
console.log('subgroup      papers  first  last');
for (const g of SUBGROUPS) {
  const ps = pop.filter((p) => grp.get(p.slug) === g);
  console.log(`${g.padEnd(13)} ${String(ps.length).padStart(6)}  ${Math.min(...ps.map((p) => p.year))}   ${Math.max(...ps.map((p) => p.year))}`);
}
console.log('\nby year  (2025-2026 are provisional venue-years)');
const yr = new Map();
for (const p of pop) yr.set(p.year, (yr.get(p.year) ?? 0) + 1);
for (let y = 2010; y <= 2026; y++) console.log(`  ${y}  ${String(yr.get(y) ?? 0).padStart(2)}  ${'#'.repeat(yr.get(y) ?? 0)}`);
console.log('\nby three-year window, with the corpus-wide window size for scale');
for (const [a, b] of [[2010, 2012], [2013, 2015], [2016, 2018], [2019, 2021], [2022, 2024], [2025, 2026]]) {
  const n = pop.filter((p) => p.year >= a && p.year <= b).length;
  const c = rows.filter((p) => p.year >= a && p.year <= b).length;
  console.log(`  ${a}-${b}  ${String(n).padStart(2)} of ${String(c).padStart(4)} corpus papers  (${pct(n, c)})`);
}
console.log('\nby subgroup and three-year window — which mechanism the field was measuring when');
console.log(`${'window'.padEnd(10)} ${SUBGROUPS.map((g) => g.padStart(10)).join(' ')}`);
for (const [a, b] of [[2010, 2012], [2013, 2015], [2016, 2018], [2019, 2021], [2022, 2024], [2025, 2026]]) {
  const cells = SUBGROUPS.map((g) => String(pop.filter((p) => grp.get(p.slug) === g && p.year >= a && p.year <= b).length).padStart(10));
  console.log(`${`${a}-${b}`.padEnd(10)} ${cells.join(' ')}`);
}
console.log('\nby venue, against the venue’s own size');
const vn = new Map();
for (const p of pop) vn.set(p.venue, (vn.get(p.venue) ?? 0) + 1);
[...vn.entries()].sort((a, b) => b[1] - a[1]).forEach(([v, n]) => {
  const tot = rows.filter((p) => p.venue === v).length;
  console.log(`  ${v.padEnd(8)} ${String(n).padStart(2)} of ${String(tot).padStart(4)}  (${pct(n, tot)})`);
});
 
h('2. What the population measured — every detection tuple with a stated prevalence');
let tuples = 0, withPrev = 0;
for (const p of pop) { tuples += p.detection.length; withPrev += p.detection.filter((d) => d.prevalence).length; }
console.log(`${tuples} detection tuples across ${pop.length} papers; ${withPrev} carry a prevalence string`);
console.log(`papers with at least one prevalence: ${pop.filter((p) => p.detection.some((d) => d.prevalence)).length} of ${pop.length}`);
if (process.argv.includes('--prevalence')) {
  for (const g of SUBGROUPS) {
    console.log(`\n---------- [${g}] ----------`);
    for (const p of pop.filter((q) => grp.get(q.slug) === g).sort((a, b) => a.year - b.year)) {
      console.log(`\n${p.year} ${p.venue} — ${p.title}`);
      const ns = p.population.filter((x) => x.n).map((x) => `${x.n} ${x.unit} (${x.sourceList})`);
      console.log(`  population[]: ${ns.length ? ns.join('; ') : '(no n stated)'}`);
      for (const d of p.detection) {
        if (!d.prevalence) continue;
        console.log(`  * ${d.phenomenon} — ${d.prevalence}`);
        console.log(`      technique: ${d.technique ?? '(none)'} | metric: ${d.metric ?? '(none)'}`);
        console.log(`      quote [${d.evidence?.section ?? '?'}]: "${(d.evidence?.quote ?? '').replace(/\s+/g, ' ')}"`);
      }
    }
  }
}
 
h('3. Instruments, folded, with the unmapped residue printed');
// Fold rule: the raw tools[] strings for this population are mostly browsers and drivers under
// several spellings. Everything not matched by a rule is printed below as residue.
const TOOLFOLD = [
  [/^(google )?chrom(e|ium)( browser)?$/i, 'Chrome/Chromium'],
  [/^(mozilla )?firefox$|^geckofx$/i, 'Firefox'],
  [/^safari$/i, 'Safari'], [/^(microsoft )?edge$/i, 'Edge'], [/^brave( browser)?$/i, 'Brave'],
  [/^selenium( webdriver)?$/i, 'Selenium'],
  [/^puppeteer$|^puppeteer-extra/i, 'Puppeteer'],
  [/^(microsoft )?playwright$/i, 'Playwright'],
  [/^chrome devtools protocol$/i, 'CDP (direct)'],
  [/^(mitm ?proxy|mitmproxy)$/i, 'mitmproxy'],
  [/^openwpm$/i, 'OpenWPM'],
  [/^tracker radar collector$/i, 'Tracker Radar Collector'],
  [/^(tranco|the tranco list)$/i, 'Tranco'],
  [/^(chrome ux report|crux|google crux)/i, 'CrUX'],
  [/^alexa/i, 'Alexa'], [/^majestic/i, 'Majestic'], [/^quantcast/i, 'Quantcast'],
  [/^2fa\.?directory$|^2fa directory$/i, '2fa.directory'],
  [/^(faker|randexp)$/i, 'synthetic-identity generator'],
  [/^(twilio|wit\.ai|gmail api|google g suite)$/i, 'registration plumbing (SMS/mail/CAPTCHA)'],
  [/^consent-o-matic$/i, 'Consent-O-Matic'],
  [/^prolific$|^(amazon )?mechanical turk$/i, 'participant panel'],
];
const toolPapers = new Map(); const toolRaw = new Map();
for (const p of pop) {
  const seen = new Set();
  for (const t of p.tools) {
    const name = (t.name ?? '').trim();
    if (!name) continue;
    toolRaw.set(name, (toolRaw.get(name) ?? 0) + 1);
    const rule = TOOLFOLD.find(([re]) => re.test(name));
    const key = rule ? rule[1] : null;
    if (key && !seen.has(key)) { seen.add(key); toolPapers.set(key, (toolPapers.get(key) ?? 0) + 1); }
  }
}
console.log(`folded names, counted by paper, of ${pop.length} population papers:`);
[...toolPapers.entries()].sort((a, b) => b[1] - a[1]).forEach(([k, n]) => console.log(`  ${k.padEnd(38)} ${String(n).padStart(2)}  ${pct(n, pop.length)}`));
const residue = [...toolRaw.entries()].filter(([n]) => !TOOLFOLD.some(([re]) => re.test(n))).sort((a, b) => b[1] - a[1]);
console.log(`\nRESIDUE — ${residue.length} distinct tool strings the fold does not map (${residue.reduce((a, b) => a + b[1], 0)} mentions):`);
console.log(residue.map(([n, c]) => `${n} (${c})`).join('; '));
 
h('4. Where the population drew its sites from — population[].sourceList, folded');
const LISTFOLD = [
  [/tranco/i, 'Tranco'], [/crux|chrome ux|chrome user experience/i, 'CrUX'], [/alexa/i, 'Alexa'],
  [/majestic/i, 'Majestic'], [/quantcast/i, 'Quantcast'], [/umbrella|cisco/i, 'Cisco Umbrella'],
  // /2fa/i alone also matches "UCB anonymized 2FA log events" and "UIUC 2FA-related support
  // tickets", which put an operator-telemetry paper in the directory bucket. Caught by the
  // figures review on 2026-09-11; the tight form is the one TOOLFOLD already used.
  [/2fa\.?\s?directory/i, '2fa.directory'], [/similarweb/i, 'Similarweb'], [/http ?archive/i, 'HTTP Archive'],
  [/fortune/i, 'Fortune 1000'], [/custom|not-stated|seed list/i, 'custom / not stated'],
  [/prolific|mechanical turk|participant/i, 'participant panel'],
];
const listPapers = new Map(); const listRaw = new Map();
for (const p of pop) {
  const seen = new Set();
  for (const s of p.population) {
    const v = (s.sourceList ?? '').trim();
    if (!v) continue;
    listRaw.set(v, (listRaw.get(v) ?? 0) + 1);
    const rule = LISTFOLD.find(([re]) => re.test(v));
    if (rule && !seen.has(rule[1])) { seen.add(rule[1]); listPapers.set(rule[1], (listPapers.get(rule[1]) ?? 0) + 1); }
  }
}
[...listPapers.entries()].sort((a, b) => b[1] - a[1]).forEach(([k, n]) => console.log(`  ${k.padEnd(24)} ${String(n).padStart(2)} papers  ${pct(n, pop.length)}`));
const lres = [...listRaw.entries()].filter(([n]) => !LISTFOLD.some(([re]) => re.test(n))).sort((a, b) => b[1] - a[1]);
console.log(`\nRESIDUE — ${lres.length} distinct source-list strings unmapped:`);
console.log(lres.map(([n, c]) => `${n} (${c})`).join('; '));
console.log('\nranking list by era (papers naming each, first/last year in this population):');
for (const k of ['Alexa', 'Tranco', 'CrUX', 'Majestic', 'Quantcast', 'Cisco Umbrella']) {
  const ps = pop.filter((p) => p.population.some((s) => LISTFOLD.find(([re]) => re.test(s.sourceList ?? ''))?.[1] === k));
  if (!ps.length) { console.log(`  ${k.padEnd(16)} 0`); continue; }
  console.log(`  ${k.padEnd(16)} ${String(ps.length).padStart(2)} papers  ${Math.min(...ps.map((p) => p.year))}-${Math.max(...ps.map((p) => p.year))}`);
}
 
h('5. How big were the site populations — population[].n for website/domain units');
const sizes = [];
for (const p of pop) for (const s of p.population) {
  if (!s.n) continue;
  if (!['websites', 'domains', 'web-pages'].includes(s.unit)) continue;
  sizes.push([s.n, p.year, p.slug]);
}
sizes.sort((a, b) => b[0] - a[0]);
console.log(`${sizes.length} site-unit population entries across ${new Set(sizes.map((s) => s[2])).size} papers`);
console.log('largest ten:');
sizes.slice(0, 10).forEach(([n, y, s]) => console.log(`  ${String(n).padStart(9)}  ${y}  ${s.slice(0, 60)}`));
const med = sizes.map((s) => s[0]).sort((a, b) => a - b)[Math.floor(sizes.length / 2)];
console.log(`median site-unit n: ${med}`);
console.log(`entries under 500 sites: ${sizes.filter((s) => s[0] < 500).length} of ${sizes.length}`);
 
h('6. Where this population goes quiet — sentinels, each with its own denominator');
const field = (label, subset, get) => {
  const vals = new Map();
  for (const p of subset) { const v = get(p); vals.set(v ?? 'null', (vals.get(v ?? 'null') ?? 0) + 1); }
  const stated = subset.filter((p) => !isSentinel(get(p))).length;
  console.log(`\n${label}  (population ${subset.length}; stated ${stated} = ${pct(stated, subset.length)})`);
  [...vals.entries()].sort((a, b) => b[1] - a[1]).forEach(([v, n]) => console.log(`    ${String(v).padEnd(26)} ${String(n).padStart(2)}`));
};
const popCrawl = pop.filter((p) => p.crawlConfig !== null);
console.log(`papers with a crawlConfig object: ${popCrawl.length} of ${pop.length}`);
field('crawlConfig.authentication', popCrawl, (p) => p.crawlConfig.authentication);
field('crawlConfig.statefulness', popCrawl, (p) => p.crawlConfig.statefulness);
field('crawlConfig.consentAction', popCrawl, (p) => p.crawlConfig.consentAction);
field('crawlConfig.interactionDepth', popCrawl, (p) => p.crawlConfig.interactionDepth);
field('ethics.reviewOutcome', pop.filter((p) => p.ethics !== null), (p) => p.ethics.reviewOutcome);
field('ethics.notifiedAffectedParties', pop.filter((p) => p.ethics !== null), (p) => p.ethics.notifiedAffectedParties);
field('artifacts.availability', pop.filter((p) => p.artifacts !== null), (p) => p.artifacts.availability);
console.log('\nbase rates for the same fields, so a share can be read against something:');
const base = (label, get, famFilter) => {
  const mk = (set) => { const st = set.filter((p) => !isSentinel(get(p))).length; return `${st}/${set.length} = ${pct(st, set.length)}`; };
  const popSet = pop.filter(famFilter), webSet = web.filter(famFilter), allSet = rows.filter(famFilter);
  console.log(`  ${label.padEnd(34)} population ${mk(popSet).padEnd(22)} web papers ${mk(webSet).padEnd(24)} corpus ${mk(allSet)}`);
};
base('crawlConfig.authentication', (p) => p.crawlConfig?.authentication, (p) => p.crawlConfig !== null);
base('crawlConfig.statefulness', (p) => p.crawlConfig?.statefulness, (p) => p.crawlConfig !== null);
base('ethics.reviewOutcome', (p) => p.ethics?.reviewOutcome, (p) => p.ethics !== null);
base('ethics.notifiedAffectedParties', (p) => p.ethics?.notifiedAffectedParties, (p) => p.ethics !== null);
base('artifacts.availability', (p) => p.artifacts?.availability, (p) => p.artifacts !== null);
 
h('6a. Absence claims, printed rather than asserted');
// The page claims almost nobody reuses a measurement framework. An absence claim that rests on
// one spelling of one tool is not a finding, so both the narrow and the widened check are
// printed: OpenWPM alone, and OpenWPM plus the other collectors a web-measurement paper might
// pick up. The widened one returns a paper the narrow one misses, and the page names it.
const OFFSHELF = /openwpm|tracker ?radar ?collector|webxray|puppeteer-?cluster|crawl4ai/i;
for (const [label, re] of [['OpenWPM', /openwpm/i], ['any off-the-shelf framework (OpenWPM, Tracker Radar Collector, webXray, crawl4ai)', OFFSHELF]]) {
  const inTools = pop.filter((p) => p.tools.some((t) => re.test(t.name ?? '')));
  const inOther = pop.filter((p) => (p.otherToolsMentioned ?? []).some((t) => re.test((t && (t.name ?? t)) ?? '')));
  console.log(`  ${label}: tools[] ${inTools.length} papers${inTools.length ? ' (' + inTools.map((p) => p.slug.slice(0, 30)).join(', ') + ')' : ''}; otherToolsMentioned[] ${inOther.length} papers${inOther.length ? ' (' + inOther.map((p) => p.slug.slice(0, 30)).join(', ') + ')' : ''}`);
}
 
h('7. Hand coding and validation inside this population');
const ann = pop.filter((p) => p.humanAnnotation.length > 0);
console.log(`papers with a humanAnnotation tuple: ${ann.length} of ${pop.length} (${pct(ann.length, pop.length)})`);
const annBaseWeb = web.filter((p) => p.humanAnnotation.length > 0).length;
console.log(`  base rate: ${annBaseWeb} of ${web.length} web papers = ${pct(annBaseWeb, web.length)}`);
const withCount = ann.filter((p) => p.humanAnnotation.some((a) => !isSentinel(a.annotatorCount)));
const withMetric = ann.filter((p) => p.humanAnnotation.some((a) => !isSentinel(a.agreementMetric)));
console.log(`  state an annotator count: ${withCount.length} of ${ann.length} = ${pct(withCount.length, ann.length)}`);
console.log(`  state an agreement metric: ${withMetric.length} of ${ann.length} = ${pct(withMetric.length, ann.length)}`);
const cls = pop.filter((p) => p.classification.length > 0);
console.log(`papers with a classification tuple: ${cls.length} of ${pop.length}`);
const vmap = new Map();
for (const p of cls) for (const v of new Set(p.classification.map((c) => c.validation))) vmap.set(v ?? 'null', (vmap.get(v ?? 'null') ?? 0) + 1);
[...vmap.entries()].sort((a, b) => b[1] - a[1]).forEach(([v, n]) => console.log(`    classification.validation ${String(v).padEnd(22)} ${n}`));
const mmap = new Map();
for (const p of cls) for (const v of new Set(p.classification.map((c) => c.method))) mmap.set(v ?? 'null', (mmap.get(v ?? 'null') ?? 0) + 1);
[...mmap.entries()].sort((a, b) => b[1] - a[1]).forEach(([v, n]) => console.log(`    classification.method     ${String(v).padEnd(22)} ${n}`));
 
h('8. Is anyone here using an LLM? (currency check)');
const llmPop = pop.filter((p) => p.classification.some((c) => c.method === 'llm'));
const llmAll = rows.filter((p) => p.classification.some((c) => c.method === 'llm'));
console.log(`classification.method == llm: ${llmPop.length} of the ${pop.length} population papers; ${llmAll.length} corpus-wide`);
const llmYr = new Map();
for (const p of llmAll) llmYr.set(p.year, (llmYr.get(p.year) ?? 0) + 1);
console.log('corpus-wide llm classification by year: ' + [...llmYr.entries()].sort().map(([y, n]) => `${y}:${n}`).join(' '));
if (llmPop.length) for (const p of llmPop) console.log(`  ${p.year} ${p.venue} ${p.title}`);
 
h('9. Artifact links released by this population');
const art = pop.filter((p) => p.artifacts && p.artifacts.availability && !isSentinel(p.artifacts.availability));
console.log(`papers stating an availability value: ${art.length} of ${pop.length}`);
for (const p of pop) {
  const a = p.artifacts;
  if (!a) continue;
  if (!a.links || !a.links.length) continue;
  const code = a.links.filter((l) => ['code-repository', 'dataset', 'artifact-archive'].includes(l.kind));
  const shown = (code.length ? code : a.links).slice(0, 2).map((l) => `${l.kind}:${l.url}`).join(' ');
  console.log(`  ${p.year} ${p.venue.padEnd(8)} ${(a.availability ?? '-').padEnd(26)} ${shown}`);
}
 
// ---------------------------------------------------------------------------
// --wikitable: the page's own "all 45 papers" table, generated rather than typed.
// Columns: year, venue, citekey+title, subgroup, and the largest site-unit n the paper
// DECLARES in population[] — which is the drawn frame, not necessarily the set analysed, and
// for a few papers (a phishing corpus, a breach dataset, a password leak) not even the frame
// for the deployment part of the study. The page says so in the row above the table rather
// than quietly presenting these as measured populations. Paste into the page as-is.
// ---------------------------------------------------------------------------
if (process.argv.includes('--wikitable')) {
  const SUBLABEL = { SSO: 'SSO', MFA: 'MFA/RBA', PASSKEY: 'passkey', LOGINSURF: 'login surface', POSTLOGIN: 'post-login', OPERATOR: 'operator' };
  console.log('\n===== --wikitable =====');
  console.log("^ Year ^ Venue ^ Paper ^ Measures ^ Largest n in ''population[]'' ^");
  const VENUE = { USENIX: 'USENIX Sec', 'IEEE-SP': 'IEEE S&P', PETS: 'PoPETs', WWW: 'TheWebConf', CCS: 'CCS', IMC: 'IMC', NDSS: 'NDSS' };
  for (const x of IN.slice().sort((a, b) => a.p.year - b.p.year || a.p.venue.localeCompare(b.p.venue))) {
    const p = x.p;
    const site = p.population.filter((s) => s.n && ['websites', 'domains', 'web-pages'].includes(s.unit)).sort((a, b) => b.n - a.n)[0];
    const other = p.population.filter((s) => s.n).sort((a, b) => b.n - a.n)[0];
    const popCell = site
      ? `${site.n.toLocaleString('en-US')} ${site.unit} (${site.sourceList})`
      : other ? `${other.n.toLocaleString('en-US')} ${other.unit} (${other.sourceList})` : 'no n stated';
    const title = (p.title ?? '').replace(/\.$/, '').replace(/\|/g, '-');
    console.log(`| ${p.year} | ${VENUE[p.venue] ?? p.venue} | //${title}// {[${x.citekey}]} | ${SUBLABEL[x.verdict[1]]} | ${popCell} |`);
  }
}

auth_report-output.txt

Unedited report output: both fold residues in full, the base rates, and the absence checks.

auth_report-output.txt
security:authentication — report
corpus: 5859 extracted papers, 7 venues, 2010-2026 (data/extract/run1)
candidates from five probes: 184
POPULATION (hand audit, inclusion rule in scripts/auth_pop.mjs): 45 papers
  2.8% of the 1622 web-platform papers
  4.0% of the 1120 papers that ran a crawl
 
===== 1. Population shape =====
subgroup      papers  first  last
SSO               12  2012   2026
MFA                7  2021   2025
PASSKEY            6  2022   2026
LOGINSURF         12  2017   2026
POSTLOGIN          4  2015   2024
OPERATOR           4  2015   2022
 
by year  (2025-2026 are provisional venue-years)
  2010   0  
  2011   0  
  2012   1  #
  2013   0  
  2014   1  #
  2015   2  ##
  2016   0  
  2017   2  ##
  2018   1  #
  2019   1  #
  2020   2  ##
  2021   2  ##
  2022   7  #######
  2023   9  #########
  2024   5  #####
  2025   7  #######
  2026   5  #####
 
by three-year window, with the corpus-wide window size for scale
  2010-2012   1 of  386 corpus papers  (0.3%)
  2013-2015   3 of  481 corpus papers  (0.6%)
  2016-2018   3 of  667 corpus papers  (0.4%)
  2019-2021   5 of 1185 corpus papers  (0.4%)
  2022-2024  21 of 1955 corpus papers  (1.1%)
  2025-2026  12 of 1185 corpus papers  (1.0%)
 
by subgroup and three-year window — which mechanism the field was measuring when
window            SSO        MFA    PASSKEY  LOGINSURF  POSTLOGIN   OPERATOR
2010-2012           1          0          0          0          0          0
2013-2015           1          0          0          0          1          1
2016-2018           2          0          0          1          0          0
2019-2021           1          1          0          1          0          2
2022-2024           4          4          2          7          3          1
2025-2026           3          2          4          3          0          0
 
by venue, against the venue’s own size
  USENIX   16 of 1410  (1.1%)
  CCS       9 of  990  (0.9%)
  NDSS      6 of  701  (0.9%)
  WWW       5 of  843  (0.6%)
  PETS      4 of  510  (0.8%)
  IEEE-SP   4 of  767  (0.5%)
  IMC       1 of  638  (0.2%)
 
===== 2. What the population measured — every detection tuple with a stated prevalence =====
261 detection tuples across 45 papers; 258 carry a prevalence string
papers with at least one prevalence: 45 of 45
 
===== 3. Instruments, folded, with the unmapped residue printed =====
folded names, counted by paper, of 45 population papers:
  Chrome/Chromium                        19  42.2%
  Firefox                                 7  15.6%
  Selenium                                6  13.3%
  participant panel                       6  13.3%
  Puppeteer                               5  11.1%
  CDP (direct)                            4  8.9%
  synthetic-identity generator            4  8.9%
  Playwright                              4  8.9%
  Safari                                  4  8.9%
  mitmproxy                               3  6.7%
  Edge                                    3  6.7%
  registration plumbing (SMS/mail/CAPTCHA)  2  4.4%
  Brave                                   2  4.4%
  Consent-O-Matic                         1  2.2%
  2fa.directory                           1  2.2%
  Tracker Radar Collector                 1  2.2%
 
RESIDUE — 203 distinct tool strings the fold does not map (218 mentions):
Google Search (3); zxcvbn (3); googletrans (2); Chrome extension (2); Python (2); regular expressions (2); NordVPN (2); Opera (2); XDriver (2); scikit-learn (2); XGBoost (2); ScraperAPI (2); AZcaptcha (2); browser add-on we designed (1); semi-automatic vulnerability assessment tools (1); Greasemonkey (1); impersonator tool (1); access token network sniffer (1); attacker.com (1); SSOScan (1); Facebook Single Sign-On APIs (1); browser extension (custom) (1); WebConnect (1); NodeJS (1); Passport (1); automated analysis tool (1); DuckDuckGo (1); network tap logging module (1); OpenID Connect module for Drupal (1); OpenIAM (1); Keycloak (1); Gluu (1); Soffid (1); feKara (1); Distinct (1); Live-Monitor (1); Communication-Inspector (1); Docker (1); NoVNC (1); JavaScript Proxy (1); custom OAuth crawler (1); McAfee's domain categorization API (1); EasyPrivacy (1); The ProgrammableWeb (1); SAAT (1); Chromium Accessibility API (1); GNU Parallel (1); OpenCV (1); Simplabel (1); BigQuery (1); IDB-DETECTOR (1); Whois Lookup (1); GitHub Code Search (1); Tracker Radar Entity List (1); COVScan (1); selenium-wire (1); undetected-chromedriver (1); Chrome WebDriver (1); TDLib (1); KiwiTalk (1); Android Auto Clicker (1); Google Search APIs (1); RetinaFace (1); FaceNet512 (1); Inception-ResNet-v1 (1); MobileNetV3 (1); multi-layer perceptron (MLP) (1); NVivo (1); PHP (1); Google Authenticator (1); k-modes (1); Screencasts (1); HOSIT (1); McAfee's URL Ticketing System (1); Disconnect.me (1); FP-Extractor (1); FP-Spoofer (1); VisibleV8 (1); Emkei's Fake Mailer (1); NRC EmoLex (1); Zoom (1); Chrome's built-in JS debugger (1); Chrome's built-in virtual authenticator (1); FIDO Alliance Metadata Service APIv3 (1); Symantec Sitereview (1); Proof-of-concept Chrome extension (1); PASSKEYS-RADAR (1); PASSKEYS-ATTACKER (1); Browser Use (1); Tracker Radar Entity Map (1); Google BigQuery (1); Google DNS API (1); Namecheap API (1); Chrome built-in translation (1); Google Scholar (1); Touch ID (1); AirDrop (1); iCloud Keychain (1); Google Password Manager (1); Yubico YubiKey (Security Key C NFC) (1); Yubico FIDO2 library (1); Wireshark (1); Node.js (1); Amazon AWS (1); threshold-based classifier (custom) (1); MediaStream API (1); Sitereview (1); custom crawler (1); ChromeDriver (1); Geckodriver (1); Google Translate (1); McAfee URL Ticketing System (1); EmailHarvester (1); modified proxy (1); OneLogin (1); Google (1); Facebook (1); Apple (1); SVM (1); langdetect (1); Translate (1); all-DistilRoBERTa (1); TF-IDF (1); SimilarWeb (1); binary SVM (custom) (1); Google search engine (1); TensorFlow (1); Fathom (1); Priv-Accept (1); uBlock Origin Core (1); JShelter (1); Zed Attack Proxy (ZAP) (1); FindIP API (1); HSQL Database Engine (1); SQLite (1); Python-native DNS resolver (1); QRLChecker (1); custom semi-automated detection pipeline (1); Wenjuanxing (1); Web3AuthChecker (1); FlexRequest (1); curl_cffi (1); curl-impersonate (1); Web3AuthGuard (1); MetaMask (1); Postman (1); Requests (1); GitHub Codespaces (1); ProtonVPN (1); Socket Secure (SOCKS) proxy (1); Google Chrome Extension (1); Account Framework (1); Foxhound (1); Exploit generator by Steffens et al. (1); Retire.js (1); Disconnect Tracker Protection List (1); PMForce (1); esprima (1); Xvfb (1); VNC (1); Bitwarden (1); BrowserStack (1); browser test suite (1); custom Cookie-header fuzzer (1); ProVerif (1); WebSpi (1); Web Platform Tests (WPT) (1); Google Consumer Surveys (1); CrowdFlower (1); Google passive reCAPTCHA (1); Google risk analysis engine (1); Cisco's Duo (1); pattern matching and name lists (1); Gossamer (1); Python Flask (1); Apache (1); MySQL (1); Python Fernet (1); Python Miscreant (1); Hashcat (1); PPSM (1); Pass2Path (1); MaxMind GeoIP2 (1); Blackbox API (1); Qualtrics (1); Samsung Browser (1); OriginMail (1); DrissionPage (1); IPQualityScore (1); Mailmeteor (1); custom SMTP server (1); WebShrinker API (1); EasyList (1); Host BlackList (1); Host BlockList (1); JAW (1); iOS Safari (1); random selection (1); Google search (1); Internet Archive (1); Bro (1); EditThisCookie (1); rst (1)
 
===== 4. Where the population drew its sites from — population[].sourceList, folded =====
  custom / not stated      17 papers  37.8%
  Tranco                   16 papers  35.6%
  Alexa                    11 papers  24.4%
  CrUX                      7 papers  15.6%
  Fortune 1000              2 papers  4.4%
  2fa.directory             2 papers  4.4%
  participant panel         2 papers  4.4%
  Quantcast                 1 papers  2.2%
  Majestic                  1 papers  2.2%
  Similarweb                1 papers  2.2%
  Cisco Umbrella            1 papers  2.2%
  HTTP Archive              1 papers  2.2%
 
RESIDUE — 47 distinct source-list strings unmapped:
Google login traces (3); public dataset from prior work [34] (2); partner RP authentication server logs (2); Google Consumer Surveys (2); Google's Top 1,000 Most-Visited Websites (1); Gmail, Hotmail, Yahoo!, and QQ mail (1); OpenIAM, Keycloak, Gluu, Soffid, and feKara (1); published employee payroll record (1); U.S. universities (1); all reachable websites where the algorithm did not find any OAuth implementation (1); websites requesting non-minimal scopes for at least one IdP (1); GitHub (1); Innocenti et al. dataset (1); Phish-A (1); Phish-B (1); APWG (1); FIDO Alliance's Metadata Service (MDS) (1); community directories (1); PASSKEYS-RADAR merged sources (1); confirmed independent passkey implementations (1); websites selected for full security evaluation (1); relevant academic venues and citation searches (1); FIDO Alliance certified devices (1); FIDO Alliance certified Level 1 hardware authenticators (1); Sitereview (1); Wenjuanxing (1); DappRadar's Top Decentralized Marketplaces list (1); Google searches (1); GitHub metrics (1); Google deployment (1); Google account recovery claims (1); CrowdFlower (1); RockYou (1); three existing threat intelligence feeds (1); Google accounts previously identified as victims of targeted attacks (1); Google sign-in flow (1); UCB anonymized 2FA log events (1); UIUC anonymized 2FA log events (1); UIUC 2FA-related support tickets (1); UIUC support tickets analyzed after automated-ticket removal (1); UIUC student/employee status data (1); breach data used in prior work (1); remaining 20% of breach dataset (1); npm API (1); GitHub repository and query APIs (1); MDN (1); GitHub 2020 Octoverse report (1)
 
ranking list by era (papers naming each, first/last year in this population):
  Alexa            11 papers  2015-2025
  Tranco           16 papers  2022-2026
  CrUX              7 papers  2023-2026
  Majestic          1 papers  2022-2022
  Quantcast         1 papers  2014-2014
  Cisco Umbrella    1 papers  2022-2022
 
===== 5. How big were the site populations — population[].n for website/domain units =====
85 site-unit population entries across 40 papers
largest ten:
   18000000  2026  the-state-of-passkeys-studying-the-adoption-and-security-of-
    1585964  2020  the-cookie-hunter-automated-black-box-auditing-for-web-authe
    1000000  2018  o-single-sign-off-where-art-thou-an-empirical-analysis-of-si
    1000000  2025  only-as-strong-as-the-weakest-link-on-the-security-of-broker
    1000000  2026  the-state-of-passkeys-studying-the-adoption-and-security-of-
    1000000  2022  how-not-to-handle-keys-timing-attacks-on-fido-authenticator-
    1000000  2017  security-implications-of-redirection-trail-in-popular-websit
    1000000  2023  a-large-scale-measurement-of-website-login-policies
    1000000  2023  measuring-website-password-creation-policies-at-scale
     961857  2015  cookies-lack-integrity-real-world-implications
median site-unit n: 872
entries under 500 sites: 39 of 85
 
===== 6. Where this population goes quiet — sentinels, each with its own denominator =====
papers with a crawlConfig object: 23 of 45
 
crawlConfig.authentication  (population 23; stated 19 = 82.6%)
    none                        9
    account-registration        7
    not-stated                  4
    manual-login                3
 
crawlConfig.statefulness  (population 23; stated 7 = 30.4%)
    not-stated                 16
    stateful                    4
    stateless                   2
    both                        1
 
crawlConfig.consentAction  (population 23; stated 8 = 34.8%)
    not-stated                 14
    no-interaction              6
    accept-all                  2
    not-applicable              1
 
crawlConfig.interactionDepth  (population 23; stated 21 = 91.3%)
    landing-plus-subpages      11
    single-target-page          7
    deep-crawl                  2
    not-stated                  2
    landing-page-only           1
 
ethics.reviewOutcome  (population 44; stated 20 = 45.5%)
    none-mentioned             24
    approved                   10
    not-required                4
    sought-outcome-unstated     3
    explicitly-discussed-no-review  2
    exempt                      1
 
ethics.notifiedAffectedParties  (population 44; stated 30 = 68.2%)
    yes                        22
    not-stated                  8
    partial                     6
    not-applicable              6
    no                          2
 
artifacts.availability  (population 41; stated 28 = 68.3%)
    public                     20
    none-mentioned             13
    on-request                  3
    promised-not-yet-available  3
    restricted                  1
    explicitly-withheld         1
 
base rates for the same fields, so a share can be read against something:
  crawlConfig.authentication         population 19/23 = 82.6%          web papers 634/838 = 75.7%          corpus 779/1080 = 72.1%
  crawlConfig.statefulness           population 7/23 = 30.4%           web papers 203/838 = 24.2%          corpus 219/1080 = 20.3%
  ethics.reviewOutcome               population 20/44 = 45.5%          web papers 522/1435 = 36.4%         corpus 1777/4965 = 35.8%
  ethics.notifiedAffectedParties     population 30/44 = 68.2%          web papers 747/1435 = 52.1%         corpus 2552/4965 = 51.4%
  artifacts.availability             population 28/41 = 68.3%          web papers 974/1568 = 62.1%         corpus 3356/5539 = 60.6%
 
===== 6a. Absence claims, printed rather than asserted =====
  OpenWPM: tools[] 0 papers; otherToolsMentioned[] 0 papers
  any off-the-shelf framework (OpenWPM, Tracker Radar Collector, webXray, crawl4ai): tools[] 1 papers (the-double-edged-sword-identif); otherToolsMentioned[] 0 papers
 
===== 7. Hand coding and validation inside this population =====
papers with a humanAnnotation tuple: 38 of 45 (84.4%)
  base rate: 1126 of 1622 web papers = 69.4%
  state an annotator count: 13 of 38 = 34.2%
  state an agreement metric: 7 of 38 = 18.4%
papers with a classification tuple: 42 of 45
    classification.validation manual-validation      28
    classification.validation none-reported          22
    classification.validation not-applicable         12
    classification.validation held-out-test-set      3
    classification.validation comparison-to-other-method 3
    classification.validation cross-validation       2
    classification.method     heuristic-rules        23
    classification.method     manual-labelling       20
    classification.method     curated-database       11
    classification.method     third-party-service    10
    classification.method     dynamic-analysis       5
    classification.method     regex-or-signature     5
    classification.method     blocklist              4
    classification.method     supervised-ml          4
    classification.method     other                  1
    classification.method     unsupervised-ml        1
 
===== 8. Is anyone here using an LLM? (currency check) =====
classification.method == llm: 0 of the 45 population papers; 177 corpus-wide
corpus-wide llm classification by year: 2023:2 2024:27 2025:77 2026:71
 
===== 9. Artifact links released by this population =====
papers stating an availability value: 28 of 45
  2012 CCS      none-mentioned             dataset:http://www.google.com/adplanner/static/top1000/
  2014 USENIX   public                     dataset:quantcast.com
  2017 PETS     public                     source-code:https://github.com/Sparika/WebConnect other:http://www.alexa.com/topsites
  2018 USENIX   public                     dataset:https://www.cs.uic.edu/~sso-study/
  2021 WWW      none-mentioned             dataset:https://data.ny.gov/Transparency/Salary-Information-for-State-Authorities/unag-2p27 dataset:https://booleanstrings.com/wp-content/uploads/2014/01/fortune1000-2012.xls/
  2022 CCS      public                     dataset:https://tranco-list.eu/list/ZGXG
  2023 PETS     public                     source-code:https://anonymous.4open.science/r/oauth_project_code-2003 other:https://github.com/ssut/py-googletrans
  2022 IEEE-SP  on-request                 dataset:https://majestic.com/reports/majestic-million
  2023 IMC      public                     dataset:https://github.com/zakird/cruxtop-lists
  2025 IEEE-SP  public                     dataset:https://tranco-list.eu/list/6Z2X
  2025 USENIX   public                     source-code:https://doi.org/10.5281/zenodo.14677002 project-page:https://mobitec.ie.cuhk.edu.hk/cross-app-oauth-security
  2026 NDSS     none-mentioned             other:https://github.com/tdlib/td other:https://github.com/KiwiTalk/KiwiTalk
  2021 USENIX   none-mentioned             project-page:https://www.usenix.org/conference/usenixsecurity21/presentation/ulqinaku web-demo-or-service:https://login.two-step.online/google.com/index.php?acc=8[..]b
  2023 NDSS     none-mentioned             dataset:https://2fa.directory/ dataset:https://github.com/2factorauth/twofactorauth
  2023 CCS      public                     dataset:https://2fa.directory/int/
  2023 USENIX   none-mentioned             other:https://tranco-list.eu/list/42XX other:https://2fa.directory/
  2022 USENIX   promised-not-yet-available dataset:https://apwg.org/ecx/
  2025 NDSS     none-mentioned             web-demo-or-service:https://emkei.cz/ web-demo-or-service:https://www.prolific.com/
  2023 CCS      none-mentioned             other:https://developer.chrome.com/docs/devtools/webauthn other:https://developer.chrome.com/docs/devtools/javascript
  2026 USENIX   public                     project-page:https://passkeys.tools code-and-data:https://github.com/RUB-NDS/state-of-passkeys-artifacts
  2025 PETS     none-mentioned             dataset:https://www.kaggle.com/datasets/cheedcheed/top1m
  2025 USENIX   public                     code-and-data:https://doi.org/10.5281/zenodo.14745290 other:https://passkeys.directory/
  2022 PETS     public                     code-and-data:https://osf.io/t7dpa/?view_only=c8595da6c6d34fadb87f2f6db7e5d626 other:https://chromium.googlesource.com/chromium/src/+/refs/heads/main/device/fido/get_assertion_task.cc
  2026 NDSS     public                     dataset:https://github.com/XDAuth-security/XDAuth
  2023 USENIX   on-request                 dataset:https://developer.chrome.com/docs/crux/ dataset:https://plaintextoffenders.com/
  2023 CCS      on-request                 dataset:https://github.com/danielmiessler/SecLists/tree/master/Passwords/Common-Credentials dataset:https://xato.net/today-i-am-releasing-ten-million-passwords-b6278bbe7495
  2024 WWW      public                     dataset:https://github.com/asumansenol/double_edged_sword_data dataset:https://developers.google.com/web/tools/chrome-user-experience-report
  2024 CCS      none-mentioned             web-demo-or-service:https://findip.net/ web-demo-or-service:https://www.zaproxy.org/
  2025 USENIX   restricted                 code-and-data:https://doi.org/10.5281/zenodo.14676762 source-code:https://doi.org/10.5281/zenodo.14676842
  2024 CCS      public                     source-code:https://github.com/d0scoo1/Web3AuthChecker source-code:https://github.com/d0scoo1/Web3AuthGuard
  2026 USENIX   public                     dataset:https://tranco-list.eu/list/7XN5X
  2024 IEEE-SP  public                     code-and-data:https://github.com/cispa/login-security-landscape other:https://github.com/SAP/project-foxhound
  2023 USENIX   public                     dataset:https://httparchive.org/ dataset:https://almanac.httparchive.org/
  2019 WWW      none-mentioned             other:https://developers.google.com/recaptcha/docs/v3
  2020 USENIX   explicitly-withheld        project-page:https://www.usenix.org/conference/usenixsecurity20/presentation/reynolds
  2022 USENIX   promised-not-yet-available web-demo-or-service:https://blackbox.ipinfo.app/ other:https://cryptography.io/en/latest/fernet.html
  2024 CCS      none-mentioned             dataset:https://github.com/danielmiessler/SecLists/tree/master/Passwords/Common-Credentials
  2026 NDSS     public                     dataset:https://github.com/Marphownio/RepSEO Classifier/tree/main/RepSEO-package-list/npm
  2022 IEEE-SP  none-mentioned             dataset:https://github.com/alviser/mitch/tree/master/dataset
  2015 USENIX   public                     source-code:https://github.com/seccookie/ExtSecureCookie browser-extension:http://www.editthiscookie.com/

auth_recall.py

The full-text recall probe, with its positive control.

auth_recall.py
#!/usr/bin/env python3
"""Recall check for security:authentication.
 
The page's population comes from a title+summary candidate set (scripts/auth_audit.mjs).
This asks the complementary question: does any paper whose title and summary never mention
a login mechanism nevertheless MEASURE one in its body? It streams every paper.cols.txt,
collapses whitespace (a PDF line break inside "single sign-on" otherwise hides it), and
prints, for every non-candidate paper, how many times each family fires. Papers over the
review threshold are then read by hand.
 
Usage: python3 scripts/auth_recall.py [--threshold 8]
"""
import json, re, os, sys, glob, subprocess
 
ROOT = '/workspace/publications_dataset/data'
FT = f'{ROOT}/fulltext'
THRESH = int(sys.argv[sys.argv.index('--threshold') + 1]) if '--threshold' in sys.argv else 8
 
FAMILIES = {
    'sso': re.compile(r'single sign-?on|\bSSO\b|OAuth|OpenID Connect|\bSAML\b|identity provider', re.I),
    'passkey': re.compile(r'WebAuthn|passkey|navigator\.credentials|\bFIDO2?\b|\bCTAP\b', re.I),
    'mfa': re.compile(r'two-?factor|multi-?factor|\b2FA\b|\bMFA\b|risk-based authentication|one-?time (password|code)|\bTOTP\b', re.I),
    'loginsurf': re.compile(r'login page|login form|sign-?in page|login policy|password policy|account creation|registration form', re.I),
}
 
# the candidate set, recomputed here so the two scripts cannot disagree about it
cand = set(json.loads(subprocess.run(
    ['node', '-e', """
import { loadExtractions } from './scripts/lib.mjs';
const rows = loadExtractions();
const T = (p) => `${p.title ?? ''} • ${p.summary ?? ''}`;
const P = [
  (p) => /(single sign-?on|\\bSSO\\b|OAuth|OpenID|SAML|WebAuthn|passkey|\\bFIDO\\b|multi-?factor|two-?factor|\\b2FA\\b|\\bMFA\\b)/i.test(T(p)),
  (p) => /\\blog ?-?in\\b|\\blogins?\\b|\\bsign-?in\\b|\\bsign ?up\\b|\\bsigning in\\b|identity provider|relying part|\\bOTP\\b|\\bTOTP\\b|one-?time (password|code|pin)|\\bU2F\\b|security key|passwordless|magic link|account recovery|password reset|forgot password|account takeover|credential stuffing|session (management|cookie|hijack|fixation|integrity|token)|password manager/i.test(T(p)),
  (p) => /\\bauthenticat/i.test(T(p)) && p.platforms.includes('web'),
  (p) => /\\baccounts?\\b/i.test(T(p)) && p.platforms.includes('web'),
];
console.log(JSON.stringify(rows.filter(p => P.some(f => f(p))).map(p => p.slug)));
"""], capture_output=True, text=True, check=True).stdout))
 
# Keyed on (year, venue, slug), not on slug alone: two slugs occur twice in the corpus
# (a 2010 and a 2012 social-spam paper, and two UIScope records), and a slug-keyed dict
# silently drops one of each — a two-paper hole in a denominator nobody would notice.
# Caught by the generic review, 2026-09-11.
meta = {}
lines = 0
for line in open(f'{ROOT}/extract/run1/extractions.jsonl', encoding='utf-8'):
    lines += 1
    p = json.loads(line)
    meta[(p['year'], p['venue'], p['slug'])] = p
assert len(meta) == lines, f'{lines} records but {len(meta)} keys: the key is not unique'
 
missing_ft = 0
scored = []
for (year, venue, slug), p in meta.items():
    path = f'{FT}/{year}/{venue}/{slug}/paper.cols.txt'
    if not os.path.exists(path):
        missing_ft += 1
        continue
    raw = open(path, encoding='utf-8', errors='replace').read().replace('\x00', '')
    text = re.sub(r'\s+', ' ', raw)
    counts = {k: len(rx.findall(text)) for k, rx in FAMILIES.items()}
    scored.append((slug, p, counts, sum(counts.values())))
 
print(f'papers scanned: {len(scored)}; no paper.cols.txt: {missing_ft} (counted as negatives)')
print(f'candidate set (title+summary probes): {len(cand)}')
print(f'threshold for hand review: total full-text hits >= {THRESH} AND not already a candidate')
print('')
out = [s for s in scored if s[0] not in cand and s[3] >= THRESH]
out.sort(key=lambda s: -s[3])
print(f'papers over threshold and outside the candidate set: {len(out)}')
print('total sso passkey mfa loginsurf  year venue  title')
for slug, p, c, tot in out:
    print(f"{tot:5d} {c['sso']:3d} {c['passkey']:7d} {c['mfa']:3d} {c['loginsurf']:9d}  {p['year']} {p['venue']:8s} {p['title'][:95]}")
 
# how the population itself scores, as a positive control: a probe that cannot see the
# papers we know are in the population is not measuring recall of anything.
inpop = set(json.loads(subprocess.run(['node', 'scripts/auth_audit.mjs', '--csv'], capture_output=True, text=True).stdout
            .split('slug,year,venue,code,subgroup')[1].strip().split('\n').__str__().replace("'", '"'))) if False else None
print('')
print('positive control — full-text hit totals for the 41 population papers:')
pop = [l.split(',')[0] for l in subprocess.run(['node', 'scripts/auth_audit.mjs', '--csv'], capture_output=True, text=True)
       .stdout.split('slug,year,venue,code,subgroup')[1].strip().split('\n') if l.split(',')[3] == 'IN']
pmap = {s[0]: s[3] for s in scored}
low = [(s, pmap.get(s, -1)) for s in pop if pmap.get(s, -1) < THRESH]
print(f'  population papers scoring under the threshold: {len(low)} of {len(pop)}')
for s, v in low:
    print(f'    {v:4d} {s}')

auth_recall-output.txt

Unedited recall output: the 155 papers over threshold, ranked, and the control.

auth_recall-output.txt
papers scanned: 5855; no paper.cols.txt: 4 (counted as negatives)
candidate set (title+summary probes): 173
threshold for hand review: total full-text hits >= 8 AND not already a candidate
 
papers over threshold and outside the candidate set: 155
total sso passkey mfa loginsurf  year venue  title
  142   2     113  26         1  2024 NDSS     A Security and Usability Analysis of Local Attacks Against FIDO2
  113   0       0  12       101  2023 IEEE-SP  Investigating the Password Policy Practices of Website Administrators.
   99   0       4  95         0  2018 IEEE-SP  A Tale of Two Studies: The Best and Worst of YubiKey Usability.
   97  97       0   0         0  2020 USENIX   Shattered Chain of Trust: Understanding Security Risks in Cross-Cloud IoT Access Delegation
   80  80       0   0         0  2015 IEEE-SP  Securing Multiparty Online Services Via Certification of Symbolic Transactions.
   65   0      65   0         0  2021 IEEE-SP  Method Confusion Attack on Bluetooth Pairing.
   62  48       0   7         7  2023 USENIX   Back to School: On the (In)Security of Academic VPNs
   52   0      52   0         0  2020 USENIX   Breaking Secure Pairing of Bluetooth Low Energy Using Downgrade Attacks
   50   0       0  50         0  2021 USENIX   "Why wouldn't someone think of democracy as a target?": Security practices & challenges of peop
   49  43       0   6         0  2024 NDSS     Maginot Line: Assessing a New Cross-app Threat to PII-as-Factor Authentication in Chinese Mobil
   48   0       0  44         4  2024 USENIX   A Mixed-Methods Study on User Experiences and Challenges of Recovery Codes for an End-to-End En
   48   0       9  39         0  2024 IEEE-SP  Everyone for Themselves? A Qualitative Study about Individual Security Setups of Open Source So
   47  45       0   0         2  2018 USENIX   An Empirical Study of Web Resource Manipulation in Real-world Mobile Applications
   47  44       0   0         3  2016 IEEE-SP  Security Analysis of Emerging Smart Home Applications.
   44   0       0  44         0  2016 IEEE-SP  I Think They're Trying to Tell Me Something: Advice Sources and Selection for Digital Security.
   43   0      42   1         0  2022 USENIX   Trust Dies in Darkness: Shedding Light on Samsung's TrustZone Keymaster Design
   40  32       0   8         0  2019 NDSS     how-bad-can-it-git-characterizing-secret-leakage-in-public-github-repositories
   37  31       0   0         6  2022 IEEE-SP  The State of the SameSite: Studying the Usage, Effectiveness, and Adequacy of SameSite Cookies.
   36   0       0  36         0  2016 CCS      How I Learned to be Secure: a Census-Representative Survey of Security Advice Sources and Behav
   35   0      14  21         0  2021 USENIX   On the Usability of Authenticity Checks for Hardware Security Tokens
   34   0       0  34         0  2024 USENIX   In Wallet We Trust: Bypassing the Digital Wallets Payment Security for Free Shopping
   34   0       0  28         6  2016 IEEE-SP  Sending Out an SMS: Characterizing the Security of the SMS Ecosystem with Public Gateways.
   32   0       2  25         5  2022 IMC      Retroactive identification of targeted DNS infrastructure hijacking.
   32   4       6  22         0  2025 CCS      Quantifying Security Training in Organizations Through the Analysis of U.S. SEC 10-K Filings.
   31   0       0  31         0  2023 USENIX   Know Your Cybercriminal: Evaluating Attacker Preferences by Measuring Profile Sales on an Activ
   31   0      31   0         0  2025 IEEE-SP  EUCLEAK Side-Channel Attack on the YubiKey 5 Series (Revealing and Breaking Infineon ECDSA Impl
   30  30       0   0         0  2023 CCS      Formal Analysis of Access Control Mechanism of 5G Core Network.
   28   0       0  28         0  2020 CCS      Impersonation-as-a-Service: Characterizing the Emerging Criminal Infrastructure for User Impers
   28  28       0   0         0  2022 NDSS     PHYjacking: Physical Input Hijacking for Zero-Permission Authorization Attacks on Android
   27  25       0   0         2  2015 WWW      Network-based Origin Confusion Attacks against HTTPS Virtual Hosting.
   27   0       0  26         1  2024 USENIX   SoK (or SoLK?): On the Quantitative Study of Sociodemographic Factors and Computer Security Beh
   27   0       0  27         0  2023 IEEE-SP  Skilled or Gullibleƒ Gender Stereotypes Related to Computer Security and Privacy.
   26  25       0   1         0  2015 PETS     Toward Mending Two Nation-Scale Brokered Identification Systems
   25  24       0   1         0  2019 NDSS     total-recall-persistence-of-passwords-in-android
   25   0       0  25         0  2021 USENIX   Risky Business? Investigating the Security Practices of Vendors on an Online Anonymous Market u
   25   0       0  25         0  2023 USENIX   In the Quest to Protect Users from Side-Channel Attacks – A User-Centred Design Space to Mitiga
   24   0       0  24         0  2024 USENIX   I Experienced More than 10 DeFi Scams: On DeFi Users' Perception of Security Breaches and Count
   24   0       0   0        24  2024 WWW      Experimental Security Analysis of Sensitive Data Access by Browser Extensions.
   23  23       0   0         0  2014 CCS      Cross-Tenant Side-Channel Attacks in PaaS Clouds.
   23   0       0  23         0  2023 USENIX   Are Consumers Willing to Pay for Security and Privacy of IoT Devices?
   22   2       0   0        20  2020 PETS     No boundaries: data exfiltration by third parties embedded on web pages
   22   0       0  21         1  2025 USENIX   Understanding How Users Prepare for and React to Smartphone Theft
   22   0      22   0         0  2023 IEEE-SP  BLEDiff: Scalable and Property-Agnostic Noncompliance Checking for BLE Implementations.
   21  21       0   0         0  2022 USENIX   Practical Data Access Minimization in Trigger-Action Platforms
   20   0       0  15         5  2021 USENIX   "Now I'm a bit angry:" Individuals' Awareness, Perception, and Responses to Data Breaches that 
   20  15       0   1         4  2024 USENIX   Racing for TLS Certificate Validation: A Hijacker's Guide to the Android TLS Galaxy
   20   0      19   1         0  2025 NDSS     Rediscovering Method Confusion in Proposed Security Fixes for Bluetooth
   19   0       0   0        19  2024 CCS      Unmasking the Security and Usability of Password Masking.
   19  19       0   0         0  2025 IEEE-SP  Countmamba: A Generalized Website Fingerprinting Attack via Coarse-Grained Representation and F
   19   0      18   1         0  2026 IEEE-SP  One Tap to Hijack Them All: A Security Analysis of the Google Fast Pair Protocol.
   18  16       0   0         2  2015 USENIX   Cookies Lack Integrity: Real-World Implications
   18   0       0  18         0  2019 PETS     Investigating sources of PII used in Facebook’s targeted advertising
   18  18       0   0         0  2020 USENIX   Droplet: Decentralized Authorization and Access Control for Encrypted Data Streams
   18   0       0  16         2  2022 IMC      PhishInPatterns: measuring elicited user interactions at scale on phishing websites.
   18   0       0  18         0  2022 NDSS     Above and Beyond: Organizational Efforts to Complement U.S. Digital Security Compliance Mandate
   18   0       0   2        16  2024 WWW      Phishing Vs. Legit: Comparative Analysis of Client-Side Resources of Phishing and Target Brand 
   18   0       0  18         0  2021 IEEE-SP  Which Privacy and Security Attributes Most Impact Consumers' Risk Perception and Willingness to
   18  16       0   2         0  2025 USENIX   Easy As Child's Play: An Empirical Study on Age Verification of Adult-Oriented Android Apps
   17   0      17   0         0  2020 CCS      FirmXRay: Detecting Bluetooth Link Layer Vulnerabilities From Bare-Metal Firmware.
   17  17       0   0         0  2023 IEEE-SP  Continuous Intrusion: Characterizing the Security of Continuous Integration Services.
   16  16       0   0         0  2022 USENIX   Experimental Security Analysis of the App Model in Business Collaboration Platforms
   16  11       0   0         5  2022 USENIX   Web Cache Deception Escalates!
   16   8       7   0         1  2024 IMC      Whatcha Lookin' At: Investigating Third-Party Web Content in Popular Android Apps.
   16   0       0  16         0  2024 USENIX   DVa: Extracting Victims and Abuse Vectors from Android Accessibility Malware
   15   0       0  15         0  2012 IEEE-SP  A Framework to Eliminate Backdoors from Response-Computable Authentication.
   15  15       0   0         0  2025 IMC      $CookieGuard: $ Characterizing and Isolating the First-Party Cookie Jar.
   15   0       3  12         0  2025 USENIX   Digital Security Perceptions and Practices Around the World: A WEIRD versus Non-WEIRD Compariso
   15   2      10   3         0  2023 IEEE-SP  Understanding the (In)Security of Cross-side Face Verification Systems in Mobile Apps: A System
   14  14       0   0         0  2015 NDSS     I Do Not Know What You Visited Last Summer: Protecting Users from Third-party Web Tracking with
   14   0       0  14         0  2017 USENIX   When the Weakest Link is Strong: Secure Collaboration in the Case of the Panama Papers
   14   1       6   6         1  2018 USENIX   Man-in-the-Machine: Exploiting Ill-Secured Communication Inside the Computer
   14  12       0   0         2  2020 CCS      Mnemosyne: An Effective and Efficient Postmortem Watering Hole Attack Investigation System.
   14  14       0   0         0  2025 NDSS     Misdirection of Trust: Demystifying the Abuse of Dedicated URL Shortening Service
   14  11       1   0         2  2022 IEEE-SP  A Formal Security Analysis of the W3C Web Payment APIs: Attacks and Verification.
   13   0       0   0        13  2018 USENIX   The Rewards and Costs of Stronger Passwords in a University: Linking Password Lifetime to Stren
   13  13       0   0         0  2019 WWW      Measurement and Early Detection of Third-Party Application Abuse on Twitter.
   13   2       0  11         0  2020 PETS     SoK: Anatomy of Data Breaches
   13  13       0   0         0  2023 CCS      Devil in Disguise: Breaching Graph Neural Networks Privacy through Infiltration.
   13   0       0   7         6  2023 USENIX   The Digital-Safety Risks of Financial Technologies for Survivors of Intimate Partner Violence
   13   1       0   0        12  2023 USENIX   An Empirical Study & Evaluation of Modern CAPTCHAs
   13   0       0  13         0  2023 USENIX   PhyAuth: Physical-Layer Message Authentication for ZigBee Networks
   13   0       0   7         6  2023 USENIX   Rods with Laser Beams: Understanding Browser Fingerprinting on Phishing Pages
   13   0       9   4         0  2024 NDSS     From Hardware Fingerprint to Access Token: Enhancing the Authentication on IoT Devices
   13  13       0   0         0  2025 NDSS     Do (Not) Follow the White Rabbit: Challenging the Myth of Harmless Open Redirection
   12   0       0   0        12  2011 USENIX   Dirty Jobs: The Role of Freelance Labor in Web Service Abuse
   12   0       0  12         0  2022 PETS     User Perceptions of Gmail’s Confidential Mode
   12   0       0   9         3  2023 USENIX   A Two-Decade Retrospective Analysis of a University's Vulnerability to Attacks Exploiting Reuse
   12  10       0   1         1  2023 PETS     "Revoked just now!" Users' Behaviors Toward Fitness-Data Sharing with Third-Party Applications
   12   0       0  12         0  2021 IEEE-SP  Defensive Technology Use by Political Activists During the Sudanese Revolution.
   12   0      12   0         0  2025 CCS      How Blind and Low-Vision Users Manage Their Passwords.
   12   0       0  12         0  2024 IEEE-SP  Security, Privacy, and Data-sharing Trade-offs When Moving to the United States: Insights from 
   11   1       0   0        10  2015 CCS      A Multi-Modal Neuro-Physiological Study of Phishing Detection and Malware Warnings.
   11   0       0   0        11  2020 IMC      Are You Human?: Resilience of Phishing Detection to Evasion Techniques Based on Human Verificat
   11   0       0  11         0  2021 NDSS     Towards Measuring Supply Chain Attacks on Package Managers for Interpreted Languages
   11   0       0   7         4  2022 CCS      I'm SPARTACUS, No, I'm SPARTACUS: Proactively Protecting Users from Phishing by Intentionally T
   11   0       0  11         0  2022 IEEE-SP  SoK: A Framework for Unifying At-Risk User Research.
   11   0       0  11         0  2022 PETS     On the Challenges of Developing a Concise Questionnaire to Identify Privacy Personas
   11   0       0   0        11  2022 USENIX   Leaky Forms: A Study of Email and Password Exfiltration Before Form Submission
   11   0      10   1         0  2023 NDSS     VICEROY: GDPR-/CCPA-compliant Enforcement of Verifiable Accountless Consumer Requests
   11  11       0   0         0  2023 PETS     Blocking JavaScript Without Breaking the Web: An Empirical Investigation
   11  11       0   0         0  2023 USENIX   Every Signature is Broken: On the Insecurity of Microsoft Office’s OOXML Signatures
   11   1       0  10         0  2023 USENIX   To Cloud or not to Cloud: A Qualitative Study on Self-Hosters' Motivation, Operation, and Secur
   11   0       0   0        11  2024 USENIX   The Imitation Game: Exploring Brand Impersonation Attacks on Social Media Platforms
   11   0       0   0        11  2025 IEEE-SP  Open Sesame! On the Security and Memorability of Verbal Passwords.
   11   0       0   7         4  2023 IEEE-SP  "In Eighty Percent of the Cases, I Select the Password for Them": Security and Privacy Challeng
   11   7       0   0         4  2024 IEEE-SP  Tabbed Out: Subverting the Android Custom Tab Security Model.
   11   2       0   8         1  2023 IEEE-SP  Investigating Package Related Security Threats in Software Registries.
   10   0       0   0        10  2012 CCS      Collaborative TCP sequence number inference attack: how to crack sequence number under a second
   10   0       0   0        10  2012 NDSS     WarningBird: Detecting Suspicious URLs in Twitter Stream
   10   8       0   0         2  2012 USENIX   Privilege Separation in HTML5 Applications
   10   0       0   0        10  2019 CCS      Protocols for Checking Compromised Credentials.
   10   9       0   1         0  2021 CCS      All your Credentials are Belong to Us: On Insecure WPA2-Enterprise Configurations.
   10   0       0   0        10  2024 IMC      DiffAudit: Auditing Privacy Practices of Online Services for Children and Adolescents.
   10   9       0   0         1  2024 USENIX   Rise of Inspectron: Automated Black-box Auditing of Cross-platform Electron Apps
   10   0       0   5         5  2011 IEEE-SP  Using Fingerprint Authentication to Reduce System Security: An Empirical Study.
   10   0       0  10         0  2025 IEEE-SP  "It's Time. Time for Digital Security.": An End User Study on Actionable Security and Privacy A
   10   7       0   2         1  2026 PETS     WebSP-Eval: Evaluating Web Agents on Website Security and Privacy Tasks
   10   0       0   0        10  2025 USENIX   Evaluating the Effectiveness and Robustness of Visual Similarity-based Phishing Detection Model
   10   0       0  10         0  2026 USENIX   "Your imaging may be stone-cold normal, but if they look sick, they're going to get admitted": 
   10   2       0   0         8  2022 IEEE-SP  Spook.js: Attacking Chrome Strict Site Isolation via Speculative Execution.
    9   4       0   5         0  2014 USENIX   On the Feasibility of Large-Scale Infections of iOS Devices
    9   0       0   8         1  2017 CCS      Data Breaches, Phishing, or Malware?: Understanding the Risks of Stolen Credentials.
    9   9       0   0         0  2017 USENIX   Measuring the Insecurity of Mobile Deep Links of Android
    9   0       0   0         9  2018 IMC      Needle in a Haystack: Tracking Down Elite Phishing Domains in the Wild.
    9   0       0   1         8  2019 USENIX   The Web's Identity Crisis: Understanding the Effectiveness of Website Identity Indicators
    9   8       0   1         0  2021 PETS     Data Portability between Online Services: An Empirical Analysis on the Effectiveness of GDPR Ar
    9   9       0   0         0  2022 USENIX   Mistrust Plugins You Must: A Large-Scale Study Of Malicious Plugins In WordPress Marketplaces
    9   9       0   0         0  2022 USENIX   Oops... Code Execution and Content Spoofing: The First Comprehensive Analysis of OpenDocument S
    9   0       0   0         9  2023 NDSS     ReScan: A Middleware Framework for Realistic and Robust Black-box Web Application Scanning
    9   0       0   9         0  2025 CCS      Harnessing Vital Sign Vibration Harmonics for Effortless and Inbuilt XR User Authentication.
    9   0       2   4         3  2026 NDSS     Targeted Password Guessing Using k-Nearest Neighbors
    9   9       0   0         0  2025 NDSS     A Multifaceted Study on the Use of TLS and Auto-detect in Email Ecosystems
    9   0       0   8         1  2025 USENIX   Predictive Response Optimization: Using Reinforcement Learning to Fight Online Social Network A
    9   0       3   5         1  2025 CCS      How to Design Secure Honey Vault Schemes.
    9   0       0   0         9  2026 NDSS     One Email, Many Faces: A Deep Dive into Identity Confusion in Email Aliases
    8   8       0   0         0  2013 CCS      Unauthorized origin crossing on mobile platforms: threats and mitigation.
    8   0       0   0         8  2015 CCS      Surpass: System-initiated User-replaceable Passwords.
    8   1       0   0         7  2015 IMC      Going Wild: Large-Scale Classification of Open DNS Resolvers.
    8   7       0   0         1  2017 USENIX   SmartAuth: User-Centered Authorization for the Internet of Things
    8   0       0   7         1  2018 USENIX   Better managed than memorized? Studying the Impact of Managers on Password Strength and Reuse
    8   2       0   0         6  2019 IEEE-SP  Postcards from the Post-HTTP World: Amplification of HTTPS Vulnerabilities in the Web Ecosystem
    8   1       0   7         0  2020 USENIX   Security Analysis of Unified Payments Interface and Payment Apps in India
    8   2       0   6         0  2021 CCS      PARASITE: PAssword Recovery Attack against Srp Implementations in ThE wild.
    8   1       0   3         4  2021 CCS      This Sneaky Piggy Went to the Android Ad Market: Misusing Mobile Sensors for Stealthy Data Exfi
    8   0       0   8         0  2022 CCS      Understanding Security Issues in the NFT Ecosystem.
    8   8       0   0         0  2023 CCS      CookieGraph: Understanding and Detecting First-Party Tracking Cookies.
    8   0       0   8         0  2023 USENIX   Anatomy of a High-Profile Data Breach: Dissecting the Aftermath of a Crypto-Wallet Case
    8   5       0   3         0  2024 CCS      Gopher: High-Precision and Deep-Dive Detection of Cryptographic API Misuse in the Go Ecosystem.
    8   7       0   0         1  2024 PETS     Our Data, Our Solutions: A Participatory Approach for Enhancing Privacy in Wearable Activity Tr
    8   0       0   0         8  2012 IEEE-SP  Off-path TCP Sequence Number Inference Attack - How Firewall Middleboxes Reduce Security.
    8   0       0   2         6  2025 PETS     Can Social Media Privacy and Safety Features Protect Targets of Interpersonal Attacks? A System
    8   0       0   0         8  2025 PETS     Understanding Privacy Norms through Web Forms
    8   0       0   8         0  2025 USENIX   Practically Secure Honey Password Vaults: New Design and New Evaluation against Online Guessing
    8   0       5   3         0  2026 PETS     A Risk Assessment Framework for Digital Identification Systems
    8   0       0   8         0  2025 USENIX   Preventing Artificially Inflated SMS Attacks through Large-Scale Traffic Inspection
 
positive control — full-text hit totals for the 41 population papers:
  population papers scoring under the threshold: 2 of 45
       1 cookie-crumbles-breaking-and-fixing-web-session-integrity
       2 secrets-lies-and-account-recovery-lessons-from-the-use-of-personal-knowledge-que

auth_absence_probe.py

The full-text sweep behind the two corpus-wide absence claims (FedCM, enterprise SSO).

auth_absence_probe.py
#!/usr/bin/env python3
"""Full-text probe for the page's two corpus-wide ABSENCE claims.
 
The page says no paper in these seven venues measures FedCM, and none measures enterprise SSO
(Entra/Okta/Workspace). Those are claims about 5,859 papers, not about the 45-paper population,
so they need a full-text sweep rather than a population fold. Streams every paper.cols.txt with
whitespace collapsed and prints every paper with >=1 hit per family, so each claim can be
checked by reading rather than trusted.
 
Usage: python3 scripts/auth_absence_probe.py
"""
import json, os, re
 
ROOT = '/workspace/publications_dataset/data'
FT = f'{ROOT}/fulltext'
FAM = {
    'fedcm': re.compile(r'\bFedCM\b|Federated Credential Management', re.I),
    'enterprise_idp': re.compile(r'\bOkta\b|Azure Active Directory|\bAzure AD\b|Microsoft Entra|Google Workspace|\bADFS\b|Active Directory Federation', re.I),
    'relying_party_web': re.compile(r'relying part(y|ies)', re.I),
}
# Keyed on (year, venue, slug), not on slug alone: two slugs occur twice in the corpus
# (a 2010 and a 2012 social-spam paper, and two UIScope records), and a slug-keyed dict
# silently drops one of each — a two-paper hole in a denominator nobody would notice.
# Caught by the generic review, 2026-09-11.
meta = {}
lines = 0
for line in open(f'{ROOT}/extract/run1/extractions.jsonl', encoding='utf-8'):
    lines += 1
    p = json.loads(line)
    meta[(p['year'], p['venue'], p['slug'])] = p
assert len(meta) == lines, f'{lines} records but {len(meta)} keys: the key is not unique'
 
hits = {k: [] for k in FAM}
scanned = missing = 0
for (year, venue, slug), p in meta.items():
    path = f'{FT}/{year}/{venue}/{slug}/paper.cols.txt'
    if not os.path.exists(path):
        missing += 1
        continue
    scanned += 1
    text = re.sub(r'\s+', ' ', open(path, encoding='utf-8', errors='replace').read().replace('\x00', ''))
    for k, rx in FAM.items():
        n = len(rx.findall(text))
        if n:
            hits[k].append((n, p['year'], p['venue'], p['title'], slug))
 
print(f'scanned {scanned} papers ({missing} without paper.cols.txt, counted as negatives)')
for k in FAM:
    rows = sorted(hits[k], reverse=True)
    print(f'\n=== {k}: {len(rows)} papers with >=1 full-text hit')
    for n, y, v, t, s in rows[:40]:
        print(f'  {n:4d}  {y} {v:8s} {t[:100]}')
    if len(rows) > 40:
        print(f'  … {len(rows) - 40} more')

auth_absence_probe-output.txt

Unedited absence-probe output: one FedCM paper, 39 enterprise-identity mentions, 69 papers using the phrase “relying party”.

auth_absence_probe-output.txt
scanned 5855 papers (4 without paper.cols.txt, counted as negatives)
 
=== fedcm: 1 papers with >=1 full-text hit
     3  2025 IEEE-SP  "Only as Strong as the Weakest Link": On the Security of Brokered Single Sign-On on the Web.
 
=== enterprise_idp: 39 papers with >=1 full-text hit
     6  2024 WWW      Unfiltered: Measuring Cloud-based Email Filtering Bypasses.
     4  2026 USENIX   Bridges to Self: Silent Web-to-App Tracking on Mobile via Localhost
     4  2025 IEEE-SP  "Only as Strong as the Weakest Link": On the Security of Brokered Single Sign-On on the Web.
     4  2023 CCS      Evaluating the Security Posture of Real-World FIDO2 Deployments.
     4  2022 USENIX   Gossamer: Securely Measuring Password-based Logins
     3  2026 PETS     AudAgent: Automated Auditing of Privacy Policy Compliance in AI Agents
     3  2026 NDSS     Mapping the Cloud: A Mixed-Methods Study of Cloud Security and Privacy Configuration Challenges
     3  2024 USENIX   Why Aren't We Using Passkeys? Obstacles Companies Face Deploying FIDO2 Passwordless Authentication
     3  2023 USENIX   Content-Type: multipart/oracle - Tapping into Format Oracles in Email End-to-End Encryption
     3  2023 USENIX   "My Privacy for their Security": Employees' Privacy Perspectives and Expectations when using Enterpr
     3  2022 USENIX   Pre-hijacked accounts: An Empirical Study of Security Failures in User Account Creation on the Web
     2  2025 NDSS     A Multifaceted Study on the Use of TLS and Auto-detect in Email Ecosystems
     2  2025 IMC      Understanding and Characterizing Intermediate Paths of Email Delivery: The Hidden Dependencies.
     2  2024 USENIX   SIMurai: Slicing Through the Complexity of SIM Card Security Research
     2  2024 USENIX   LanDscAPe: Exploring LDAP Weaknesses and Data Leaks at Internet Scale
     2  2024 USENIX   ChainReactor: Automated Privilege Escalation Chain Discovery via AI Planning
     2  2024 CCS      AirGapAgent: Protecting Privacy-Conscious Conversational Agents.
     2  2023 USENIX   Extending a Hand to Attackers: Browser Privilege Escalation Attacks via Extensions
     2  2023 USENIX   Every Signature is Broken: On the Insecurity of Microsoft Office’s OOXML Signatures
     2  2023 CCS      "Make Them Change it Every Week!": A Qualitative Exploration of Online Developer Advice on Usable an
     2  2022 USENIX   Security and Privacy Perceptions of Third-Party Application Access for Google Accounts
     2  2020 USENIX   Empirical Measurement of Systemic 2FA Usability
     1  2026 NDSS     CoordMail: Exploiting SMTP Timeout and Command Interaction to Coordinate Email Middleware for Conver
     1  2025 PETS     Who’s Watching You Zoom? Investigating Privacy of Third-Party Zoom Apps
     1  2025 NDSS     Do (Not) Follow the White Rabbit: Challenging the Myth of Harmless Open Redirection
     1  2025 NDSS     A Comprehensive Memory Safety Analysis of Bootloaders
     1  2025 IMC      $CookieGuard: $ Characterizing and Isolating the First-Party Cookie Jar.
     1  2025 IEEE-SP  Understanding Users' Security and Privacy Concerns and Attitudes Towards Conversational AI Platforms
     1  2025 CCS      Phishing Susceptibility and the (In-)Effectiveness of Common Anti-Phishing Interventions in a Large 
     1  2025 CCS      Evaluating the Robustness of a Production Malware Detection System to Transferable Adversarial Attac
     1  2024 USENIX   Unpacking Privacy Labels: A Measurement and Developer Perspective on Google's Data Safety Section
     1  2024 USENIX   SPF Beyond the Standard: Management and Operational Challenges in Practice and Practical Recommendat
     1  2024 IEEE-SP  Injection Attacks Against End-to-End Encrypted Applications.
     1  2024 CCS      AuthSaber: Automated Safety Verification of OpenID Connect Programs.
     1  2023 USENIX   You've Got Report: Measurement and Security Implications of DMARC Reporting
     1  2023 PETS     Heads in the Clouds? Measuring Universities’ Migration to Public Clouds: Implications for Privacy & 
     1  2022 IEEE-SP  Spook.js: Attacking Chrome Strict Site Isolation via Speculative Execution.
     1  2021 USENIX   Is Real-time Phishing Eliminated with FIDO? Social Engineering Downgrade Attacks against FIDO Protoc
     1  2019 WWW      Evaluating Login Challenges as aDefense Against Account Takeover.
 
=== relying_party_web: 69 papers with >=1 full-text hit
   187  2022 CCS      Behind the Scenes of RPKI.
   171  2022 USENIX   Stalloris: RPKI Downgrade Attack
   141  2014 CCS      OAuth Demystified for Mobile Application Developers.
    83  2022 NDSS     Let’s Authenticate: Automated Certificates for User Authentication
    46  2022 CCS      Poster: RPKI Kill Switch.
    32  2025 USENIX   SoK: An Introspective Analysis of RPKI Security
    26  2015 IEEE-SP  Securing Multiparty Online Services Via Certification of Symbolic Transactions.
    21  2022 IEEE-SP  Towards Automated Auditing for Account and Session Management Flaws in Single Sign-On Deployments.
    18  2020 IMC      On Measuring RPKI Relying Parties.
    17  2022 PETS     How Not to Handle Keys: Timing Attacks on FIDO Authenticator Privacy
    17  2022 CCS      Cerberus: Query-driven Scalable Vulnerability Detection in OAuth Service Provider Implementations.
    17  2021 NDSS     A Formal Analysis of the FIDO UAF Protocol
    14  2023 USENIX   A Study of Multi-Factor and Risk-Based Authentication Availability
    12  2012 USENIX   On Breaking SAML: Be Whoever You Want to Be
    11  2024 CCS      AuthSaber: Automated Safety Verification of OpenID Connect Programs.
     9  2025 CCS      Poster: Exploring the Landscape of RPKI Relying Parties.
     9  2018 USENIX   WPSE: Fortifying Web Protocols via Browser-Side Security Monitoring
     9  2018 USENIX   O Single Sign-Off, Where Art Thou? An Empirical Analysis of Single Sign-On Account Hijacking and Ses
     8  2026 USENIX   The State of Passkeys: Studying the Adoption and Security of Passkeys on the Web
     8  2026 NDSS     Crack in the Armor: Underlying Infrastructure Threats to RPKI Publication Point Reachability
     8  2025 USENIX   Detecting Compromise of Passkey Storage on the Cloud
     8  2024 CCS      Poster: Kill Krill or Proxy RPKI.
     7  2024 NDSS     dRR: A Decentralized, Scalable, and Auditable Architecture for RPKI Repository
     7  2020 IEEE-SP  Is FIDO2 the Kingslayer of User Authentication? A Comparative Usability Study of FIDO2 Passwordless 
     6  2025 PETS     SoK: Web Authentication and Recovery in the Age of End-to-End Encryption
     6  2024 NDSS     The CURE to Vulnerabilities in RPKI Validation
     6  2023 USENIX   Keep Your Friends Close, but Your Routeservers Closer: Insights into RPKI Validation in the Internet
     6  2015 PETS     Toward Mending Two Nation-Scale Brokered Identification Systems
     5  2024 NDSS     A Security and Usability Analysis of Local Attacks Against FIDO2
     4  2019 IMC      RPKI is Coming of Age: A Longitudinal Study of RPKI Deployment and Invalid Route Origins.
     4  2018 USENIX   An Empirical Study of Web Resource Manipulation in Real-world Mobile Applications
     3  2026 NDSS     Pruning the Tree: Rethinking RPKI Architecture from the Ground up
     3  2025 USENIX   Universal Cross-app Attacks: Exploiting and Securing OAuth 2.0 in Integration Platforms
     3  2024 USENIX   Why Aren't We Using Passkeys? Obstacles Companies Face Deploying FIDO2 Passwordless Authentication
     3  2017 PETS     Why can’t users choose their identity providers on the web?
     3  2015 USENIX   Cookies Lack Integrity: Real-World Implications
     3  2014 NDSS     Web PKI: Closing the Gap between Guidelines and Practices
     3  2012 IEEE-SP  Signing Me onto Your Accounts through Facebook and Google: A Traffic-Guided Security Study of Commer
     2  2026 NDSS     Demystifying RPKI-Invalid Prefixes: Hidden Causes and Security Risks
     2  2023 USENIX   Downgrading DNSSEC: How to Exploit Crypto Agility for Hijacking Signed Zones
  … 29 more

auth_quotecheck.mjs

The 95 quote and figure checks, with the three matching tiers.

auth_quotecheck.mjs
#!/usr/bin/env node
// Quote and figure spot-check for security:authentication.
//
// Every phrase quoted on the page, and every paper-sourced figure it publishes, is looked for
// in the cited paper's own data/fulltext/<year>/<venue>/<slug>/paper.cols.txt — whitespace
// collapsed, hyphenation across line breaks joined, ligatures and curly quotes normalised,
// case folded. Needles are sentence fragments, not bare numbers: a bare "42.3%" can be a true
// string in the wrong paper.
//
// Exits non-zero on any FAIL. Known-FAIL entries are listed at the bottom with the reason.
import fs from 'node:fs';
import path from 'node:path';
import { dataRoot } from './lib.mjs';
 
const FT = path.join(dataRoot(), 'fulltext');
const norm = (s) =>
  s.replace(/-\n/g, '')
    .replace(/­/g, '')
    .replace(/fi/g, 'fi').replace(/fl/g, 'fl')
    .replace(/[‘’]/g, "'").replace(/[“”]/g, '"')
    .replace(/[–—]/g, '-')
    .replace(/[   ]/g, ' ')
    .replace(/\x00/g, '')
    .replace(/\s+/g, ' ')
    .toLowerCase();
 
const CHECKS = {
  'IMC/2023/the-prevalence-of-single-sign-on-on-the-web-towards-the-next-generation-of-web-c': [
    '51% (4743) of sites in the Top 10K',
    '57.8% (2742) of these 4743 sites support authentication with 3rd-party SSO',
    'sufficient to log in to 47.2% (2238) of sites that have authentication',
    'Crawler is successful for 64% of sites',
  ],
  'USENIX/2018/o-single-sign-off-where-art-thou-an-empirical-analysis-of-single-sign-on-account': [
    'identified SSO support on 57,555 (6.30%) domains',
    '89.5% of the RPs we evaluate do not offer options for invalidating active sessions',
  ],
  'PETS/2023/everybodys-looking-for-ssomething-a-large-scale-evaluation-on-the-privacy-of-oau': [
    'prevalence of OAuth buttons on 6,211 (7.23%) websites',
    'On 14104 websites (14.1%), the crawler failed',
    'We found 10,304 OAuth buttons in total',
    '18.53% of websites using OAuth request at least one non-minimal scope',
  ],
  'CCS/2022/distinct-identity-theft-using-in-browser-communications-in-dual-window-single-si': [
    '273 of the Tranco top 1k websites (27%) support SSO logins',
    '153 implement dual-window SSO (56%)',
    '24 of 77 websites (31%) with manual dual-window SSO integrations are vulnerable',
  ],
  'USENIX/2014/ssoscan-automated-testing-of-web-applications-for-single-sign-on-vulnerabilities': [
    '1660 sites using Facebook SSO among the 17,913 sites (9.3% of the total)',
    'A total of 345 sites (20.3%) suffered from at least one of the five tested vulnerabilities',
  ],
  'IEEE-SP/2022/towards-automated-auditing-for-account-and-session-management-flaws-in-single-si': [
    'Only 13 (0.8%) of the 1,622 RPs adequately protect user accounts from IdP cookie hijackers',
    '67% of the RPs continued to allow', 'access to the accounts even 10 days past the revocation',
    '40.5% of the RPs allowed us to access the account after logout',
    '17.6% of the RPs we tested having non-functional SSO implementations',
  ],
  'IEEE-SP/2025/only-as-strong-as-the-weakest-link-on-the-security-of-brokered-single-sign-on-on': [
    'identified 249 brokers used on 8,241 websites',
    '25% of websites prefer to use brokered SSO',
  ],
  'USENIX/2023/a-study-of-multi-factor-and-risk-based-authentication-availability': [
    'Of the 208 sites in our study, 114 were not documented in 2fa.directory',
    'Only 88 sites (42.3%) support some form of MFA',
    '46 sites (22.1%) blocked the suspicious login attempt',
    '167 sites (80.29%) in our set either have MFA or could inherit it through SSO providers',
  ],
  'CCS/2023/weve-disabled-mfa-for-you-an-evaluation-of-the-security-and-usability-of-multi-f': [
    'mobile applications were the most popular MFA method, deployed on 1,036 pages (79.51%)',
    'We regained access to 37 (52.11%)',
  ],
  'NDSS/2023/a-systematic-study-of-the-consistency-of-two-factor-authentication-user-journeys-on-top-ranked-websites': [
    'set differs in 6-7 of those 14 factors from the other websites',
  ],
  'USENIX/2021/is-real-time-phishing-eliminated-with-fido-social-engineering-downgrade-attacks': [
    'all websites that support FIDO (23 out of 100) allow choosing weaker alternatives',
  ],
  'PETS/2022/how-not-to-handle-keys-timing-attacks-on-fido-authenticator-privacy': [
    'We checked the 1 million most popular',
    'found 684 FIDO authentication deployments',
  ],
  'CCS/2023/evaluating-the-security-posture-of-real-world-fido2-deployments': [
    'Sites with account login/signup pages 585',
    'We found the pair of strings present in JS resources loaded by 135 sites, out of which for 82 sites',
    'were not detected by this method',
    'we find that 27/29 RPs',
    'only 7 out of 160 (4%) authenticators have L2 certification',
  ],
  'PETS/2025/sok-web-authentication-and-recovery-in-the-age-of-end-to-end-encryption': [
    'we find 17 sites (10.5%) offer direct passkey support',
    'of sites in the top 300 directly or indirectly offer passkey support',
    '41.6% of academic authentication research has focused on passwords',
    'we manually inspect each site in the top 300 of the',
  ],
  'USENIX/2026/the-state-of-passkeys-studying-the-adoption-and-security-of-passkeys-on-the-web': [
    '872 unique websites remained',
    'All but one site requested deprecated cryptographic algorithms',
    '68 websites vulnerable to account enumeration in their passkey authentication',
    'allow an attacker to take over accounts on 72 related origins',
  ],
  'USENIX/2023/a-large-scale-measurement-of-website-login-policies': [
    '296.9K (82.7%) sites had a login page with a third-party script',
    '358.9K domains with a login page found',
    'we found nearly 2K domains where the login page was served only over HTTP',
    '5.9K domains (19%) exhibiting some form of user enumeration vulnerability',
    '4335 domains (24%) demonstrating some rate limiting measure',
    '570 domains that sent an email containing our plaintext password',
  ],
  'CCS/2023/measuring-website-password-creation-policies-at-scale': [
    'over 30% of sites do not support spaces, Unicode, or emojis in passwords',
    '20,119 domains for which we successfully analyze password policies',
    '88% allow breached passwords',
    'AZcaptcha correctly solved 94% of all CAPTCHAs',
  ],
  'CCS/2020/the-cookie-hunter-automated-black-box-auditing-for-web-authentication-and-author': [
    'we crawl 1.5 million domains, and identify over 200 thousand domains that support account creation',
    'fully audit almost 25 thousand',
    '12,014 unique domains do not protect their authentication cookies with the secure flag',
    'a total of 5,680 domains do not protect them with',
  ],
  'WWW/2024/the-double-edged-sword-identifying-authentication-pages-and-their-fingerprinting': [
    '9.2% of the pages our crawler visited were flagged as fingerprinting',
    'the percentage rises slightly to 10.2%',
  ],
  'USENIX/2022/pre-hijacked-accounts-an-empirical-study-of-security-failures-in-user-account-cr': [
    'at least 35 of these were vulnerable to one or more account pre-hijacking attacks',
  ],
  'WWW/2017/security-implications-of-redirection-trail-in-popular-websites-worldwide': [
    'only 4,570 of the 9,159 reachable websites provide login capabilities',
  ],
  'USENIX/2025/demystifying-the-in-security-of-qr-code-based-login-in-real-world-deployments': [
    'manual verification confirms that 350 of them indeed implement QRLogin',
    'we find 47 (43%) websites with a total of 75 flaws',
  ],
  'USENIX/2026/inconsistent-incomplete-and-insecure-a-survey-of-account-security-interfaces': [
    'We discovered 200 unique ASIs from the 71 remaining services',
    '41 (67.2%) were vulnerable',
  ],
  'IEEE-SP/2022/the-state-of-the-samesite-studying-the-usage-effectiveness-and-adequacy-of-sames': [
    '18.94% of them adopted one of the three valid policy',
  ],
  'IEEE-SP/2024/to-auth-or-not-to-auth-a-comparative-analysis-of-the-pre-and-post-login-security': [
    'analyzing 200 sites across four experiments',
    'the largest-to-date study on the postlogin security landscape on 200 sites',
  ],
  'USENIX/2020/empirical-measurement-of-systemic-2fa-usability': [
    'more than one in twenty 2FA ceremonies did not end successfully',
    '70% (21.1M of 30.0M) of logins at UCB were remembered',
  ],
  'WWW/2019/evaluating-login-challenges-as-adefense-against-account-takeover': [
    'blocking over 94% of hijacking attempts rooted in phishing',
  ],
  'WWW/2015/secrets-lies-and-account-recovery-lessons-from-the-use-of-personal-knowledge-que': [
    '40% of our English-speaking US users were unable to recall their answers',
    '81% for SMS vs 75% for Email vs 61% (US/English)',
  ],
  'USENIX/2022/gossamer-securely-measuring-password-based-logins': [
    '34 million login requests',
  ],
  'CCS/2024/unmasking-the-security-and-usability-of-password-masking': [
    'All 66 sites employed password masking by default on their login forms',
    '41 sites did not support a method to toggle off or disable password masking',
  ],
  'NDSS/2026/anchors-of-trust-a-usability-study-on-user-awareness-consent-and-control-in-cross-device-authentication': [
    'none of the 27 evaluated services fully safeguard all three user rights',
  ],
  'NDSS/2026/connecting-the-dots-an-investigative-study-on-linking-private-user-data-across-messaging-apps': [
    'we compiled a set of 85,053 authentication webpages',
  ],
  'CCS/2012/the-devil-is-in-the-implementation-details-an-empirical-analysis-of-oauth-sso-sy': [
    'access tokens can be eavesdropped on 32% of RPs',
  ],
  'PETS/2017/why-can-t-users-choose-their-identity-providers-on-the-web': [
    'we observe 103 unique RPs and 23 OAuth 2 provider',
  ],
  'USENIX/2018/wpse-fortifying-web-protocols-via-browser-side-security-monitoring': [
    'not meant to provide a comprehensive coverage of the deployment of OAuth 2.0',
    'Facebook (1,666 websites), Google',
  ],
  'USENIX/2015/cookies-lack-integrity-real-world-implications': [
    'we only found 1,252 (0.13%) domains have enabled full HSTS',
  ],
  'CCS/2024/poster-security-of-login-interfaces-in-modern-organizations': [
    'The ZAP scans succeeded on 56k out of the 73.5k login pages',
  ],
  'USENIX/2025/a-framework-for-abusability-analysis-the-case-of-passkeys-in-interpersonal-threa': [
    'each hypothesized abuse vector was viable on at least one service',
  ],
  'USENIX/2025/universal-cross-app-attacks-exploiting-and-securing-oauth-2-0-in-integration-pla': [
    'Out of 18 platforms analyzed, 16 are susceptible to cross-app OAuth attacks',
  ],
  'NDSS/2025/was-this-you-investigating-the-design-considerations-for-suspicious-login-notifications': [
    'we collected suspicious login notifications from 34 domains',
  ],
  'NDSS/2026/one-email-many-faces-a-deep-dive-into-identity-confusion-in-email-aliases': [
    '9 platforms were completely unable to counter any of the alias mechanisms',
    '9 platforms were completely unable to counter any of the alias mechanisms',
  ],
  'NDSS/2025/who-is-trying-to-access-my-account-exploring-user-perceptions-and-reactions-to-risk-based-authentication-notifications': [
    'received 161 RBA email notifications',
  ],
  'WWW/2021/an-investigation-of-identity-account-inconsistency-in-single-sign-on': [
    // the abstract's "80 out of 100 websites are vulnerable to the inconsistency threat" is
    // split by a column splice inside the hyphenated word "web-sites" and cannot be matched by
    // any tolerance worth having; the results section states the same finding per case:
    'sites are vulnerable to the inconsistency threat',
    // ("79 out of 100 SPs are vulnerable to case 3" is spliced the same way; dropped rather
    // than matched with a tolerance that would accept almost anything)
  ],
};
 
// Figures the page publishes that come from a paper's own wording rather than the extraction's
// prevalence string. Checked the same way; listed apart so the provenance page can say which
// figures were re-read rather than inherited.
const DERIVED = {
  'PETS/2023/everybodys-looking-for-ssomething-a-large-scale-evaluation-on-the-privacy-of-oau': [
    '6,211', '18.53',
  ],
};
 
// Three renderings of the same PDF, because they fail on different sentences: paper.cols.txt
// has the repaired column reading order but splices a sentence when a column break falls
// inside it; paper.txt and paper.norm.txt keep the raw pdf order, which reads two columns
// interleaved but leaves short sentences intact. A needle found in any rendering is verbatim
// in the paper; the rendering that matched is printed so a reader can repeat the check.
const RENDERINGS = ['paper.cols.txt', 'paper.txt', 'paper.norm.txt'];
let fails = 0, passes = 0;
const failed = [];
const spliced = [];
const wordCache = new Map();
// Token comparison strips punctuation at the edges of a word: the rendering writes
// "sessions." where the needle has "sessions", and an exact token match would call that a
// FAIL and send a reader hunting for a quote that is in fact verbatim.
// Also: a PDF hyphenates across a line break, and .cols keeps the hyphen and the space
// ("web- sites", "pre- hijacking"), while the paper's own prose may hyphenate the same word
// permanently. Join a token ending in a hyphen to the next one, then drop internal hyphens, so
// "prehijacking", "pre-hijacking" and "pre- hijacking" are one token.
const tok = (w) => w.replace(/^[^a-z0-9$%]+/, '').replace(/[^a-z0-9$%]+$/, '').replace(/-/g, '');
const toks = (t) => {
  const raw = t.split(' ').filter(Boolean);
  const joined = [];
  for (let i = 0; i < raw.length; i++) {
    let w = raw[i];
    while (w.endsWith('-') && i + 1 < raw.length) { w = w.slice(0, -1) + raw[i + 1]; i++; }
    joined.push(w);
  }
  return joined.map(tok).filter(Boolean);
};
const wordsOf = (r, t) => {
  const k = r + t.length;
  if (!wordCache.has(k)) wordCache.set(k, toks(t));
  return wordCache.get(k);
};
const run = (label, table) => {
  console.log(`\n########## ${label} ##########`);
  for (const [key, needles] of Object.entries(table)) {
    const [venue, year, slug] = key.split('/');
    const dir = path.join(FT, year, venue, slug);
    const texts = {};
    for (const r of RENDERINGS) {
      const f = path.join(dir, r);
      if (fs.existsSync(f)) texts[r] = norm(fs.readFileSync(f, 'utf8'));
    }
    if (Object.keys(texts).length === 0) { console.log(`\n!! NO RENDERING FOUND: ${key}`); fails += needles.length; needles.forEach((n) => failed.push([key, n])); continue; }
    console.log(`\n${key}  [renderings: ${Object.keys(texts).join(', ')}]`);
    for (const n of needles) {
      const hit = Object.entries(texts).find(([, t]) => t.includes(norm(n)));
      if (hit) { console.log(`  PASS exact (${hit[0]})  ${n}`); passes++; continue; }
      // Column-splice tolerant second tier. A two-column PDF drops the other column's words
      // into the middle of a sentence, so the sentence is present but not contiguous. Match the
      // needle's words in order against the rendering's word list, allowing injected words
      // between them, and accept only if at most MAX_INJECTED words had to be skipped. The
      // count is printed, so a match that only held because 40 foreign words were tolerated is
      // visible rather than hidden behind a PASS.
      const MAX_INJECTED = 8;
      const nw = toks(norm(n));
      let best = null;
      for (const [r, t] of Object.entries(texts)) {
        const tw = wordsOf(r, t);
        for (let i = 0; i + nw.length <= tw.length; i++) {
          if (tw[i] !== nw[0]) continue;
          let j = i + 1, k = 1, injected = 0;
          while (k < nw.length && j < tw.length && injected <= MAX_INJECTED) {
            if (tw[j] === nw[k]) { k++; j++; } else { injected++; j++; }
          }
          if (k === nw.length && injected <= MAX_INJECTED && (best === null || injected < best[1])) best = [r, injected];
          if (best && best[1] === 0) break;
        }
        if (best && best[1] === 0) break;
      }
      if (best) { console.log(`  PASS spliced (${best[0]}, ${best[1]} injected words)  ${n}`); passes++; spliced.push([key, n, best[1]]); continue; }
      console.log(`  FAIL  ${n}`); fails++; failed.push([key, n]);
    }
  }
};
run('page quotes and figures', CHECKS);
run('figures re-read from the paper (not from the extraction)', DERIVED);
console.log(`\n==== ${passes} PASS, ${fails} FAIL ====`);
console.log(`\nmatched only after column-splice tolerance: ${spliced.length}`);
spliced.sort((a, b) => b[2] - a[2]).forEach(([k, n, g]) => console.log(`  ${String(g).padStart(2)} injected words  ${k}\n    ${n}`));
if (failed.length) { console.log('\nfailed needles, for the provenance page:'); failed.forEach(([k, n]) => console.log(`  ${k}\n    ${n}`)); }
process.exit(fails === 0 ? 0 : 1);

auth_quotecheck-output.txt

Unedited quote-check output: which rendering matched each needle, and how many injected words were tolerated.

auth_quotecheck-output.txt
########## page quotes and figures ##########
 
IMC/2023/the-prevalence-of-single-sign-on-on-the-web-towards-the-next-generation-of-web-c  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  51% (4743) of sites in the Top 10K
  PASS exact (paper.cols.txt)  57.8% (2742) of these 4743 sites support authentication with 3rd-party SSO
  PASS exact (paper.cols.txt)  sufficient to log in to 47.2% (2238) of sites that have authentication
  PASS exact (paper.cols.txt)  Crawler is successful for 64% of sites
 
USENIX/2018/o-single-sign-off-where-art-thou-an-empirical-analysis-of-single-sign-on-account  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  identified SSO support on 57,555 (6.30%) domains
  PASS spliced (paper.cols.txt, 1 injected words)  89.5% of the RPs we evaluate do not offer options for invalidating active sessions
 
PETS/2023/everybodys-looking-for-ssomething-a-large-scale-evaluation-on-the-privacy-of-oau  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  prevalence of OAuth buttons on 6,211 (7.23%) websites
  PASS exact (paper.cols.txt)  On 14104 websites (14.1%), the crawler failed
  PASS exact (paper.cols.txt)  We found 10,304 OAuth buttons in total
  PASS exact (paper.cols.txt)  18.53% of websites using OAuth request at least one non-minimal scope
 
CCS/2022/distinct-identity-theft-using-in-browser-communications-in-dual-window-single-si  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  273 of the Tranco top 1k websites (27%) support SSO logins
  PASS exact (paper.cols.txt)  153 implement dual-window SSO (56%)
  PASS exact (paper.cols.txt)  24 of 77 websites (31%) with manual dual-window SSO integrations are vulnerable
 
USENIX/2014/ssoscan-automated-testing-of-web-applications-for-single-sign-on-vulnerabilities  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  1660 sites using Facebook SSO among the 17,913 sites (9.3% of the total)
  PASS exact (paper.cols.txt)  A total of 345 sites (20.3%) suffered from at least one of the five tested vulnerabilities
 
IEEE-SP/2022/towards-automated-auditing-for-account-and-session-management-flaws-in-single-si  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  Only 13 (0.8%) of the 1,622 RPs adequately protect user accounts from IdP cookie hijackers
  PASS exact (paper.cols.txt)  67% of the RPs continued to allow
  PASS exact (paper.cols.txt)  access to the accounts even 10 days past the revocation
  PASS exact (paper.cols.txt)  40.5% of the RPs allowed us to access the account after logout
  PASS exact (paper.cols.txt)  17.6% of the RPs we tested having non-functional SSO implementations
 
IEEE-SP/2025/only-as-strong-as-the-weakest-link-on-the-security-of-brokered-single-sign-on-on  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  identified 249 brokers used on 8,241 websites
  PASS exact (paper.cols.txt)  25% of websites prefer to use brokered SSO
 
USENIX/2023/a-study-of-multi-factor-and-risk-based-authentication-availability  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  Of the 208 sites in our study, 114 were not documented in 2fa.directory
  PASS spliced (paper.cols.txt, 7 injected words)  Only 88 sites (42.3%) support some form of MFA
  PASS exact (paper.cols.txt)  46 sites (22.1%) blocked the suspicious login attempt
  PASS exact (paper.cols.txt)  167 sites (80.29%) in our set either have MFA or could inherit it through SSO providers
 
CCS/2023/weve-disabled-mfa-for-you-an-evaluation-of-the-security-and-usability-of-multi-f  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  mobile applications were the most popular MFA method, deployed on 1,036 pages (79.51%)
  PASS exact (paper.cols.txt)  We regained access to 37 (52.11%)
 
NDSS/2023/a-systematic-study-of-the-consistency-of-two-factor-authentication-user-journeys-on-top-ranked-websites  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  set differs in 6-7 of those 14 factors from the other websites
 
USENIX/2021/is-real-time-phishing-eliminated-with-fido-social-engineering-downgrade-attacks  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  all websites that support FIDO (23 out of 100) allow choosing weaker alternatives
 
PETS/2022/how-not-to-handle-keys-timing-attacks-on-fido-authenticator-privacy  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  We checked the 1 million most popular
  PASS exact (paper.cols.txt)  found 684 FIDO authentication deployments
 
CCS/2023/evaluating-the-security-posture-of-real-world-fido2-deployments  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  Sites with account login/signup pages 585
  PASS exact (paper.cols.txt)  We found the pair of strings present in JS resources loaded by 135 sites, out of which for 82 sites
  PASS exact (paper.cols.txt)  were not detected by this method
  PASS exact (paper.cols.txt)  we find that 27/29 RPs
  PASS exact (paper.cols.txt)  only 7 out of 160 (4%) authenticators have L2 certification
 
PETS/2025/sok-web-authentication-and-recovery-in-the-age-of-end-to-end-encryption  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  we find 17 sites (10.5%) offer direct passkey support
  PASS spliced (paper.cols.txt, 8 injected words)  of sites in the top 300 directly or indirectly offer passkey support
  PASS exact (paper.cols.txt)  41.6% of academic authentication research has focused on passwords
  PASS exact (paper.cols.txt)  we manually inspect each site in the top 300 of the
 
USENIX/2026/the-state-of-passkeys-studying-the-adoption-and-security-of-passkeys-on-the-web  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  872 unique websites remained
  PASS exact (paper.cols.txt)  All but one site requested deprecated cryptographic algorithms
  PASS exact (paper.cols.txt)  68 websites vulnerable to account enumeration in their passkey authentication
  PASS exact (paper.cols.txt)  allow an attacker to take over accounts on 72 related origins
 
USENIX/2023/a-large-scale-measurement-of-website-login-policies  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  296.9K (82.7%) sites had a login page with a third-party script
  PASS exact (paper.cols.txt)  358.9K domains with a login page found
  PASS exact (paper.cols.txt)  we found nearly 2K domains where the login page was served only over HTTP
  PASS exact (paper.cols.txt)  5.9K domains (19%) exhibiting some form of user enumeration vulnerability
  PASS exact (paper.cols.txt)  4335 domains (24%) demonstrating some rate limiting measure
  PASS exact (paper.cols.txt)  570 domains that sent an email containing our plaintext password
 
CCS/2023/measuring-website-password-creation-policies-at-scale  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  over 30% of sites do not support spaces, Unicode, or emojis in passwords
  PASS exact (paper.cols.txt)  20,119 domains for which we successfully analyze password policies
  PASS exact (paper.cols.txt)  88% allow breached passwords
  PASS exact (paper.cols.txt)  AZcaptcha correctly solved 94% of all CAPTCHAs
 
CCS/2020/the-cookie-hunter-automated-black-box-auditing-for-web-authentication-and-author  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  we crawl 1.5 million domains, and identify over 200 thousand domains that support account creation
  PASS exact (paper.cols.txt)  fully audit almost 25 thousand
  PASS exact (paper.cols.txt)  12,014 unique domains do not protect their authentication cookies with the secure flag
  PASS exact (paper.cols.txt)  a total of 5,680 domains do not protect them with
 
WWW/2024/the-double-edged-sword-identifying-authentication-pages-and-their-fingerprinting  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  9.2% of the pages our crawler visited were flagged as fingerprinting
  PASS exact (paper.cols.txt)  the percentage rises slightly to 10.2%
 
USENIX/2022/pre-hijacked-accounts-an-empirical-study-of-security-failures-in-user-account-cr  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS spliced (paper.cols.txt, 0 injected words)  at least 35 of these were vulnerable to one or more account pre-hijacking attacks
 
WWW/2017/security-implications-of-redirection-trail-in-popular-websites-worldwide  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  only 4,570 of the 9,159 reachable websites provide login capabilities
 
USENIX/2025/demystifying-the-in-security-of-qr-code-based-login-in-real-world-deployments  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  manual verification confirms that 350 of them indeed implement QRLogin
  PASS spliced (paper.cols.txt, 7 injected words)  we find 47 (43%) websites with a total of 75 flaws
 
USENIX/2026/inconsistent-incomplete-and-insecure-a-survey-of-account-security-interfaces  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  We discovered 200 unique ASIs from the 71 remaining services
  PASS exact (paper.cols.txt)  41 (67.2%) were vulnerable
 
IEEE-SP/2022/the-state-of-the-samesite-studying-the-usage-effectiveness-and-adequacy-of-sames  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  18.94% of them adopted one of the three valid policy
 
IEEE-SP/2024/to-auth-or-not-to-auth-a-comparative-analysis-of-the-pre-and-post-login-security  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  analyzing 200 sites across four experiments
  PASS exact (paper.cols.txt)  the largest-to-date study on the postlogin security landscape on 200 sites
 
USENIX/2020/empirical-measurement-of-systemic-2fa-usability  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS spliced (paper.cols.txt, 1 injected words)  more than one in twenty 2FA ceremonies did not end successfully
  PASS exact (paper.cols.txt)  70% (21.1M of 30.0M) of logins at UCB were remembered
 
WWW/2019/evaluating-login-challenges-as-adefense-against-account-takeover  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  blocking over 94% of hijacking attempts rooted in phishing
 
WWW/2015/secrets-lies-and-account-recovery-lessons-from-the-use-of-personal-knowledge-que  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS spliced (paper.cols.txt, 0 injected words)  40% of our English-speaking US users were unable to recall their answers
  PASS spliced (paper.cols.txt, 8 injected words)  81% for SMS vs 75% for Email vs 61% (US/English)
 
USENIX/2022/gossamer-securely-measuring-password-based-logins  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  34 million login requests
 
CCS/2024/unmasking-the-security-and-usability-of-password-masking  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  All 66 sites employed password masking by default on their login forms
  PASS exact (paper.cols.txt)  41 sites did not support a method to toggle off or disable password masking
 
NDSS/2026/anchors-of-trust-a-usability-study-on-user-awareness-consent-and-control-in-cross-device-authentication  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  none of the 27 evaluated services fully safeguard all three user rights
 
NDSS/2026/connecting-the-dots-an-investigative-study-on-linking-private-user-data-across-messaging-apps  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  we compiled a set of 85,053 authentication webpages
 
CCS/2012/the-devil-is-in-the-implementation-details-an-empirical-analysis-of-oauth-sso-sy  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  access tokens can be eavesdropped on 32% of RPs
 
PETS/2017/why-can-t-users-choose-their-identity-providers-on-the-web  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  we observe 103 unique RPs and 23 OAuth 2 provider
 
USENIX/2018/wpse-fortifying-web-protocols-via-browser-side-security-monitoring  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  not meant to provide a comprehensive coverage of the deployment of OAuth 2.0
  PASS exact (paper.cols.txt)  Facebook (1,666 websites), Google
 
USENIX/2015/cookies-lack-integrity-real-world-implications  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  we only found 1,252 (0.13%) domains have enabled full HSTS
 
CCS/2024/poster-security-of-login-interfaces-in-modern-organizations  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  The ZAP scans succeeded on 56k out of the 73.5k login pages
 
USENIX/2025/a-framework-for-abusability-analysis-the-case-of-passkeys-in-interpersonal-threa  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  each hypothesized abuse vector was viable on at least one service
 
USENIX/2025/universal-cross-app-attacks-exploiting-and-securing-oauth-2-0-in-integration-pla  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  Out of 18 platforms analyzed, 16 are susceptible to cross-app OAuth attacks
 
NDSS/2025/was-this-you-investigating-the-design-considerations-for-suspicious-login-notifications  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  we collected suspicious login notifications from 34 domains
 
NDSS/2026/one-email-many-faces-a-deep-dive-into-identity-confusion-in-email-aliases  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  9 platforms were completely unable to counter any of the alias mechanisms
  PASS exact (paper.cols.txt)  9 platforms were completely unable to counter any of the alias mechanisms
 
NDSS/2025/who-is-trying-to-access-my-account-exploring-user-perceptions-and-reactions-to-risk-based-authentication-notifications  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  received 161 RBA email notifications
 
WWW/2021/an-investigation-of-identity-account-inconsistency-in-single-sign-on  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  sites are vulnerable to the inconsistency threat
 
########## figures re-read from the paper (not from the extraction) ##########
 
PETS/2023/everybodys-looking-for-ssomething-a-large-scale-evaluation-on-the-privacy-of-oau  [renderings: paper.cols.txt, paper.txt, paper.norm.txt]
  PASS exact (paper.cols.txt)  6,211
  PASS exact (paper.cols.txt)  18.53
 
==== 95 PASS, 0 FAIL ====
 
matched only after column-splice tolerance: 8
   8 injected words  PETS/2025/sok-web-authentication-and-recovery-in-the-age-of-end-to-end-encryption
    of sites in the top 300 directly or indirectly offer passkey support
   8 injected words  WWW/2015/secrets-lies-and-account-recovery-lessons-from-the-use-of-personal-knowledge-que
    81% for SMS vs 75% for Email vs 61% (US/English)
   7 injected words  USENIX/2023/a-study-of-multi-factor-and-risk-based-authentication-availability
    Only 88 sites (42.3%) support some form of MFA
   7 injected words  USENIX/2025/demystifying-the-in-security-of-qr-code-based-login-in-real-world-deployments
    we find 47 (43%) websites with a total of 75 flaws
   1 injected words  USENIX/2018/o-single-sign-off-where-art-thou-an-empirical-analysis-of-single-sign-on-account
    89.5% of the RPs we evaluate do not offer options for invalidating active sessions
   1 injected words  USENIX/2020/empirical-measurement-of-systemic-2fa-usability
    more than one in twenty 2FA ceremonies did not end successfully
   0 injected words  USENIX/2022/pre-hijacked-accounts-an-empirical-study-of-security-failures-in-user-account-cr
    at least 35 of these were vulnerable to one or more account pre-hijacking attacks
   0 injected words  WWW/2015/secrets-lies-and-account-recovery-lessons-from-the-use-of-personal-knowledge-que
    40% of our English-speaking US users were unable to recall their answers

auth_report_prevalence-output.txt

Every prevalence string in the population, with the extraction evidence quote and section, plus the generated 45-paper table.

auth_report_prevalence-output.txt
security:authentication — report
corpus: 5859 extracted papers, 7 venues, 2010-2026 (data/extract/run1)
candidates from five probes: 184
POPULATION (hand audit, inclusion rule in scripts/auth_pop.mjs): 45 papers
  2.8% of the 1622 web-platform papers
  4.0% of the 1120 papers that ran a crawl
 
===== 1. Population shape =====
subgroup      papers  first  last
SSO               12  2012   2026
MFA                7  2021   2025
PASSKEY            6  2022   2026
LOGINSURF         12  2017   2026
POSTLOGIN          4  2015   2024
OPERATOR           4  2015   2022
 
by year  (2025-2026 are provisional venue-years)
  2010   0  
  2011   0  
  2012   1  #
  2013   0  
  2014   1  #
  2015   2  ##
  2016   0  
  2017   2  ##
  2018   1  #
  2019   1  #
  2020   2  ##
  2021   2  ##
  2022   7  #######
  2023   9  #########
  2024   5  #####
  2025   7  #######
  2026   5  #####
 
by three-year window, with the corpus-wide window size for scale
  2010-2012   1 of  386 corpus papers  (0.3%)
  2013-2015   3 of  481 corpus papers  (0.6%)
  2016-2018   3 of  667 corpus papers  (0.4%)
  2019-2021   5 of 1185 corpus papers  (0.4%)
  2022-2024  21 of 1955 corpus papers  (1.1%)
  2025-2026  12 of 1185 corpus papers  (1.0%)
 
by subgroup and three-year window — which mechanism the field was measuring when
window            SSO        MFA    PASSKEY  LOGINSURF  POSTLOGIN   OPERATOR
2010-2012           1          0          0          0          0          0
2013-2015           1          0          0          0          1          1
2016-2018           2          0          0          1          0          0
2019-2021           1          1          0          1          0          2
2022-2024           4          4          2          7          3          1
2025-2026           3          2          4          3          0          0
 
by venue, against the venue’s own size
  USENIX   16 of 1410  (1.1%)
  CCS       9 of  990  (0.9%)
  NDSS      6 of  701  (0.9%)
  WWW       5 of  843  (0.6%)
  PETS      4 of  510  (0.8%)
  IEEE-SP   4 of  767  (0.5%)
  IMC       1 of  638  (0.2%)
 
===== 2. What the population measured — every detection tuple with a stated prevalence =====
261 detection tuples across 45 papers; 258 carry a prevalence string
papers with at least one prevalence: 45 of 45
 
---------- [SSO] ----------
 
2012 CCS — The devil is in the (implementation) details: an empirical analysis of OAuth SSO systems.
  population[]: 96 websites (Google's Top 1,000 Most-Visited Websites); 3 other (not-stated); 15 websites (custom seed list)
  * access-token eavesdropping — 32% of RPs
      technique: Trace tokens through browser-RP communications and check SSL protection. | metric: share of relying parties
      quote [evaluation]: "our results show that access tokens can be eavesdropped on 32% of RPs."
  * access-token theft via XSS — 91% of evaluated RPs
      technique: Execute JavaScript exploits using hidden iframes and token exfiltration. | metric: share of relying parties vulnerable
      quote [introduction]: "access tokens can be stolen on most (91%) of the evaluated RPs, if an adversary could exploit an XSS vulnerability on any page"
  * impersonation — 64% of RPs
      technique: Submit stolen or guessed SSO credentials through an attacker-controlled user agent. | metric: share of relying parties vulnerable
      quote [introduction]: "an attacker could gain complete control of the victim's account on many RPs (64%) by sending a forged SSO credential"
  * session swapping — 34% of RPs
      technique: Replay attacker credentials through dynamically generated iframe or form requests. | metric: share of relying parties vulnerable
      quote [evaluation]: "Table 2 shows the summary of our evaluation results."
  * force-login CSRF — 33% of RPs
      technique: Send forged login or authorization requests through the victim's browser. | metric: share of relying parties vulnerable
      quote [evaluation]: "Table 3 shows the percentages of RPs that are vulnerable to impersonation (A3) or session swapping (A4) attacks."
  * CSRF profile alteration — 21% of tested RPs
      technique: After force-login, issue forged requests altering RP profile information. | metric: share of relying parties with vulnerable profile information
      quote [evaluation]: "Our results show that, on 21% of the tested RPs, their users' profile information is indeed vulnerable to CSRF exploits."
 
2014 USENIX — SSOScan: Automated Testing of Web Applications for Single Sign-On Vulnerabilities
  population[]: 20000 websites (Quantcast); 100 websites (Quantcast); 500 websites (Quantcast)
  * Facebook SSO integration — 1660 of 17,913 sites (9.3%)
      technique: Detected SSO buttons and recognized Facebook SSO traffic | metric: share of valid websites
      quote [results]: "SSOScan found a total of 1660 sites using Facebook SSO among the 17,913 sites (9.3% of the total)."
  * At least one SSO vulnerability — 345 of 1660 sites (20.3%)
      technique: Simulated attacks and passive traffic monitoring | metric: share of Facebook SSO sites
      quote [results]: "A total of 345 sites (20.3%) suffered from at least one of the five tested vulnerabilities."
  * Credential misuse — 202 sites (12.1%)
      technique: Replayed another account's access token and signed request | metric: share of Facebook SSO sites
      quote [results]: "We found 202 sites (12.1%) that misuse credentials (126 of which are misusing both access token and signed request)."
  * Credential leakage — 146 sites (8.6%)
      technique: Compared observed referrers, traffic, and page contents with OAuth credentials | metric: share of Facebook SSO sites
      quote [results]: "We found... 146 sites (8.6%) that leak Facebook SSO credentials (of which 72 sites are leaking through both referrer headers and DOM)."
  * App secret leak — 0 sites detected
      technique: Inspected client-side token-exchange traffic for app secrets | metric: number of vulnerable sites
      quote [results]: "SSOScan did not find any sites leaking their app secret to the public by calling the token exchange API on the client side."
  * Facebook SSO detection failure — 1 of 100 sites included Facebook SSO but was missed
      technique: Manual examination of ranked samples reported as unsupported | metric: false-negative rate in sample
      quote [evaluation]: "From manually investigating these 100 sites, we could only find one site that included Facebook SSO but was missed by SSOScan."
 
2017 PETS — Why can’t users choose their identity providers on the web?
  population[]: 500 websites (Alexa ranking)
  * OAuth 2/OIDC usage — 103 unique RPs and 23 OAuth 2 provider domain names
      technique: Parsed authorization request URLs from browser navigation history. | metric: unique relying parties and provider domains
      quote [results]: "In total, we observe 103 unique RPs and 23 OAuth 2 provider's domain names."
  * Relying-party scope requirements — 58% of 103 RPs were Authentication or Profile
      technique: Classified requested scopes into Authentication, Profile, and Specialized classes. | metric: share of observed RPs by minimum/maximum class
      quote [results]: "a majority of RPs, 58 % of 103, can be classified as Authentication or Profile."
  * OIDC implementation — Only four observed IdPs implemented OIDC; no observed provider implemented dynamic registration or Web Finger.
      technique: Inspected openid scopes, metadata, dynamic registration, and Web Finger support. | metric: number of observed provider domains implementing features
      quote [results]: "No observed OIDC provider implement dynamic registration or Web Finger, and we find that only two out of five offer openid-configuration metadata."
  * OIDC scope and claim usage — Only 4 of 20 investigated providers implemented OIDC; 10 of 22 Google OIDC-scope RPs requested ID Tokens.
      technique: Compared collected authorization scopes with OIDC standard claims. | metric: number of providers and relying parties
      quote [results]: "From our observation, only four IdPs out of twenty where implementing OIDC, as reported on Table 2."
  * Implicit RP-IdP trust — 14 of 103 observed RPs had an implicit trust relationship
      technique: Manually examined provider compatibility and organizational relationships. | metric: share of observed RPs
      quote [results]: "Out of the hundred and three observed RPs, we estimate that fourteen have an implicit trust relationship with their IdP."
 
2018 USENIX — O Single Sign-Off, Where Art Thou? An Empirical Analysis of Single Sign-On Account Hijacking and Session Management on the Web
  population[]: 1000000 websites (Alexa); 29 websites (Alexa top 500); 66 mobile-apps (custom seed list)
  * SSO adoption — 57,555 domains (6.30%)
      technique: Automated browser crawl with DOM, regex, endpoint, and search analysis. | metric: share of processed Alexa websites supporting SSO
      quote [results]: "Our tool identified SSO support on 57,555 (6.30%) domains on the list."
  * Facebook cookie exposure — 5,729 unique vulnerable cookies over four months
      technique: Passive counting of unique Facebook cookie values on a wireless network tap. | metric: unique vulnerable cookies
      quote [results]: "Overall, we collected a total of 5,729 unique vulnerable cookies during our experiment"
  * SSO-enabled RP account takeover — 93 of 95 RPs did not consistently require IdP reauthentication
      technique: Manual replay of hijacked IdP cookies across web and mobile relying parties. | metric: RPs where cookie-based access was possible
      quote [results]: "only two RPs consistently require this authentication during the SSO process."
  * long-term account access — 22 of 29 web RPs supported long-term access through email/password changes
      technique: Manual email replacement, password setting, and account-linking attack experiments. | metric: RPs vulnerable to maintaining access
      quote [results]: "she can leverage this process and maintain long-term access in 22 out of the 29 RPs that we tested."
  * preemptive account hijacking — 95 relying parties manually recreated
      technique: Manual creation and later re-access of accounts through SSO cookies. | metric: RPs tested
      quote [methodology]: "we manually recreated the attack scenario in the 95 RPs."
  * session-remediation availability — 89.5% of evaluated RPs
      technique: Independent execution of logout, password, access-revocation, and session-invalidation actions. | metric: share of RPs lacking active-session invalidation
      quote [introduction]: "89.5% of the RPs we evaluate do not offer options for invalidating active sessions."
 
2021 WWW — An Investigation of Identity-Account Inconsistency in Single Sign-On.
  population[]: 4 other (Gmail, Hotmail, Yahoo!, and QQ mail); 5 other (OpenIAM, Keycloak, Gluu, Soffid, and feKara); 100 websites (Alexa top 1,000 websites); 971 other (Fortune 1000 company list); 80147 other (published employee payroll record); 50 other (U.S. universities)
  * identity-account inconsistency — 80 out of 100 websites were vulnerable
      technique: Manually tested SSO login and account-update behavior in three scenarios. | metric: share of service providers
      quote [introduction]: "we observe that 80 out of 100 websites are vulnerable to the inconsistency threat"
  * email account reuse — Hotmail, Yahoo!, QQ, and business accounts permit reuse; Gmail public accounts prohibit it.
      technique: Inspected provider policies for deletion, modification, and re-registration. | metric: provider policy availability
      quote [results]: "Our study indicates that Hotmail and Yahoo! allow the same email address to be re-registered by other users."
  * SSO case-3 compromise — 79 out of 100 SPs allowed login; all updated the empty UserID.
      technique: Registered an SP account without SSO, then attempted SSO login with matching email. | metric: share of service providers
      quote [results]: "79 out of 100 SPs are vulnerable to case ❸, which means they allow any identity with the same email address to SSO login to an account with empty UserID."
  * SSO case-4 compromise — 52 SPs allowed login with a different UserID; none updated the UserID.
      technique: Deleted and recreated an IdP identity with the same email and tested SSO login. | metric: share of service providers
      quote [results]: "52 SPs allow SSO login for case ❹: even with a different UserID, an identity with the same email address can SSO login to the SP's account."
  * email address collision — 31% for firstname-only, 18% for first-initial plus lastname, and 6% for firstname plus lastname.
      technique: Applied common naming conventions to MTA employee records. | metric: percentage of assigned email addresses colliding
      quote [results]: "the {Firstname} convention has the highest probability: an astonishing 31% of the assigned emails would have a collision"
  * email address reuse after retirement — 48.14%, 57.71%, and 65.77% by naming convention at the end of 2018.
      technique: Tracked released 2013 addresses against later MTA hires through 2018. | metric: percentage of released addresses reassigned
      quote [results]: "at the end of 2018, 48.14%, 57.71%, and 65.77% of the email addresses could have been re-assigned"
  * university email-policy risk — 32 allowed students to change email addresses; 24 deleted student accounts after graduation.
      technique: Reviewed publicly available policies from 50 randomly selected universities. | metric: number of universities
      quote [introduction]: "32 of them allow students to modify their email addresses, and 24 of them delete student email accounts after their graduation"
 
2022 CCS — DISTINCT: Identity Theft using In-Browser Communications in Dual-Window Single Sign-On.
  population[]: 1000 domains (Tranco)
  * Dual-window SSO adoption — 153 of 273 websites (56%) implemented at least one dual-window SSO flow
      technique: Distinct traced SSO flows and classified window communications | metric: share of SSO-supporting websites
      quote [results]: "From 273 websites, 153 implement dual-window SSO (56%), surpassing textbook SSO implemented by 134 websites."
  * SSO support — 273 of 1,000 websites (27%) supported SSO logins
      technique: Manual SSO-button activation with Live-Monitor recognition | metric: share of Tranco top-1k websites
      quote [results]: "In sum, 273 of the Tranco top 1k websites (27%) support SSO logins."
  * Manual dual-window SSO integrations — 77 of 153 websites (50%) manually integrated dual-window SSO
      technique: SDK detection and flow tracing | metric: share of dual-window websites
      quote [results]: "Every second website with dual-window SSO uses manual integrations (77 of 153, 50%)."
  * SSO implementation vulnerabilities — 24 of 77 websites (31%) were vulnerable
      technique: Automated indicators followed by manual confirmation and PoC testing | metric: share of manual dual-window integrations
      quote [results]: "We found that 24 of 77 websites (31%) with manual dual-window SSO integrations are vulnerable to the Wildcard Receiver Attack (WRA), Malicious Receiver Attack (MRA), and Malicious Initiator Attack (MIA)."
  * Token and privacy leaks — 23 websites failed to protect InBC confidentiality; tokens were redeemable on 17 sites
      technique: Threat indicators, manual data inspection, and exploit verification | metric: vulnerable websites
      quote [results]: "The great majority of them (23) fail to protect the confidentiality of InBMs, resulting in Token Leaks (TLs) and Privacy Leaks (PLs) with confirmed account takeovers on 17 sites."
  * SSO detection accuracy — FPR 0%; TPR 100%
      technique: Comparison with manual SSO-button activation | metric: false-positive and true-positive rates
      quote [results]: "The false positive rate (FPR) for Live-Monitor's SSO and SDK detection is 0%, respectively the true positive rate (TPR) is 100%."
 
2022 IEEE-SP — Towards Automated Auditing for Account and Session Management Flaws in Single Sign-On Deployments.
  population[]: 100000 websites (Majestic)
  * Non-functional Facebook SSO — 17.6% of RPs
      technique: Interactive SSO login and collection of IdP-generated errors. | metric: share of tested relying parties
      quote [results]: "The login process for 17.6% of Relying Parties resulted in errors, demonstrating that an accurate assessment of the ecosystem requires interactive measurements."
  * SSO support volatility — 119 websites dropped SSO support
      technique: Two crawl rounds separated by 50 days. | metric: websites dropping SSO support
      quote [results]: "We tracked changes in Single Sign-On support across two rounds of data collection that were 50 days apart. We found that Single Sign-On support was dropped in 119 websites."
  * Re-authentication enforcement — 13 (0.8%) of 1,622 RPs
      technique: Attempted SSO login with injected IdP cookies and bypass testing. | metric: RPs adequately enforcing re-authentication
      quote [results]: "Only 13 (0.8%) of the 1,622 RPs adequately protect user accounts from IdP cookie hijackers."
  * Access-revocation failure — 67% continued allowing access
      technique: Revoked IdP access, then tested RP-cookie access daily. | metric: RPs allowing access 10 days after revocation
      quote [results]: "67% of the RPs continued to allow access to the accounts even 10 days past the revocation."
  * Logout/session invalidation failure — 40.5% of RPs
      technique: Reused collected cookies after RP logout. | metric: RPs allowing access after logout
      quote [results]: "Alarmingly, 40.5% of the RPs allowed us to access the account after logout."
  * Client-side-only expiration — 6 RPs
      technique: Compared original cookies with cookies extended one year. | metric: RPs responding differently
      quote [results]: "If an RP responds differently to these requests, it means that they rely on the browser to enforce session expiration (client-side). We examined ... and found 6 RPs."
  * Account-merging violations — 11% for preexisting accounts and 10% when initial creation used SSO
      technique: Type-1 and type-2 registration-path tests with distinct accounts. | metric: share violating merging guidelines
      quote [results]: "11% of the RPs violated the merging guidelines when SSO is used with preexisting accounts, and 10% violated them when the initial account creation was done over SSO."
  * Cookie persistence after login — 48% accepted cookies 40 days after the initial login
      technique: Daily state detection for 40 days and cookie-expiration comparison. | metric: RPs accepting cookies 40 days after login
      quote [results]: "48% of RPs accepted cookies 40 days after the initial login and 86% of those RPs were non-compliant and continued to accept cookies even after 70 days."
 
2023 PETS — Everybody's Looking for SSOmething: A large-scale evaluation on the privacy of OAuth authentication on the web
  population[]: 100000 websites (Chrome User Experience Report (CrUX)); 100 websites (all reachable websites where the algorithm did not find any OAuth implementation); 100 websites (websites requesting non-minimal scopes for at least one IdP); 200 websites (websites using OAuth from the CrUX dataset)
  * OAuth login adoption — 6,211 of 85,896 reachable websites (7.23%)
      technique: Keyword search, candidate-button scoring, and authorization-endpoint traffic monitoring. | metric: share of websites using OAuth
      quote [results]: "We report on the prevalence of OAuth buttons on 6,211 (7.23%) websites."
  * Non-minimal OAuth scopes — 1,151 websites (18.53%) requested non-minimal scopes.
      technique: Extracted scope URL parameters and categorized scopes against IdP-specific minimal scopes. | metric: share of OAuth websites
      quote [results]: "We found such buttons on 1,151 websites in our dataset (18.53%)."
  * Undetected OAuth implementations — 18 of 100 websites were missed.
      technique: Manual visits and clicks on login and registration pages for 100 negative cases. | metric: manual false-negative rate
      quote [evaluation]: "We found that out of the 100 websites, our algorithm failed to detect OAuth buttons on 18 of them."
  * Scope necessity — 65 of 100 websites were unaffected.
      technique: Changed authorization scopes to minimal scopes and checked login success, errors, and post-login fields. | metric: share unaffected by scope reduction
      quote [results]: "On 65 out of the 100 websites, logging in with minimal scopes instead of a non-minimal ones did not affect the login process or the user experience."
  * Cookie-banner prevalence — 2,220 websites (35.74%) had a cookie banner.
      technique: Homepage screenshots followed by manual inspection and targeted revisits. | metric: share of OAuth websites
      quote [results]: "In total, we found a cookie banner on 2220 (35.74%) websites that use OAuth."
  * Third-party tracking — 68.0% of minimal-scope and 60.0% of non-minimal-scope websites.
      technique: Inspected browser requests and long-lived cookies using EasyPrivacy matches. | metric: share with at least one tracker
      quote [results]: "We find that 1259 (68.0%) websites with minimal OAuth scopes include at least one third-party tracker and 222 (60.0%) websites with non-minimal scopes use third-party tracking."
  * Preselected marketing consent — 31.82% of minimal-scope and 54.55% of non-minimal-scope sites.
      technique: Manual observation during account registration. | metric: share of sites with marketing consent preselected
      quote [results]: "14 out of these 44 (31.82%) websites include a preselected choice. On websites that use OAuth with non-minimal scopes ... 30 (54.55%)"
  * Registration versus OAuth data collection — 20 minimal-scope and 14 non-minimal-scope websites.
      technique: Manual comparison of requested OAuth scopes and registration fields. | metric: number of websites where registration requested more data
      quote [results]: "This is the case for 14 websites with OAuth with non-minimal scopes and 20 websites with OAuth with minimal scopes."
 
2023 IMC — The Prevalence of Single Sign-On on the Web: Towards the Next Generation of Web Content Measurement.
  population[]: 1000 websites (Chrome UX Report (CrUX)); 10000 websites (Chrome UX Report (CrUX))
  * login mechanisms — 51% (4743) of Top 10K sites had a login function
      technique: DOM regular expression finds and clicks common login buttons | metric: share of top websites
      quote [results]: "51% (4743) of sites in the Top 10K and 51% (507) in the Top 1K have a login function"
  * third-party SSO support — 57.8% (2742) of Top 10K sites with login supported third-party SSO
      technique: DOM inference and logo detection on login-page content | metric: share of sites with login
      quote [results]: "57.8% (2742) of these 4743 sites support authentication with 3rd-party SSO IdPs."
  * SSO identity-provider prevalence — Google, Apple, and Facebook enabled login for 47.2% (2238) of authenticated sites
      technique: Combined binary OR of DOM and logo detections | metric: share of sites with authentication
      quote [results]: "having accounts on three SSO IdPs, Google, Apple, and Facebook, is sufficient to log in to 47.2% (2238) of sites that have authentication"
  * crawler navigation success — The Crawler was successful for 64% of sites
      technique: Manual ground-truth labeling of crawler outcomes | metric: share of Top 1K crawls
      quote [results]: "Our Crawler is successful for 64% of sites by correctly navigating to the login page or finding that there is no login."
 
2025 IEEE-SP — "Only as Strong as the Weakest Link": On the Security of Brokered Single Sign-On on the Web.
  population[]: 1000000 websites (Tranco); 88983 network-flows (public dataset from prior work [34]); 50 network-flows (public dataset from prior work [34])
  * brokered SSO adoption — 249 brokers used on 8,241 websites; 25% of websites with SSO used brokered SSO
      technique: IDB-DETECTOR processing recorded HAR login flows | metric: share of SSO websites
      quote [introduction]: "We used IDB-DETECTOR to analyze the Tranco top 1M websites and identified 249 brokers used on 8,241 websites. In general, 25% of websites prefer to use brokered SSO."
  * misdirected redirection chains — 126 flows used out-of-order or open-end chains
      technique: Reconstructed redirect_uri chains from recorded login requests | metric: affected brokered SSO flows
      quote [results]: "We found 126 brokered SSO login flows affected by this issue."
  * redirect validation failures — 49 brokers did not validate the redirection chain; 20% of brokers
      technique: Manual manipulation of redirect_uri and custom callback parameters | metric: share of brokers
      quote [results]: "Surprisingly, 49 brokers did not validate the redirection chain, which is alarming."
  * authentication-token leakage — Account takeover enabled on 1,950 SPs
      technique: Inspecting attacker-site data after manipulated redirects and redeeming leaked tokens | metric: affected service providers
      quote [results]: "We manually confirmed token leaks for 34 of 36 brokers, which allow account takeover attacks on 1,950 SPs."
  * unauthorized user-data access — 15 brokers exposed data on 1,103 SPs
      technique: CID linkage analysis followed by malicious-SP verification | metric: affected service providers
      quote [results]: "We found 15 brokers that fail to protect the user's data. If a user logs in to one of the 1,103 SPs integrating such a vulnerable broker, their data is at risk."
  * account takeover through consent reuse — 6 brokers enabled takeover on 799 SPs
      technique: Testing whether malicious SPs received unscoped tokens valid at trusted SPs | metric: affected service providers
      quote [results]: "On 6 brokers, we could escalate the issue further as they returned unscoped tokens to the malicious SP, allowing them to take over the victim's accounts."
  * SBCP violations — 3,367 downgrade violations and 7,415 tolerated violations
      technique: Comparing security parameters between SP-broker and broker-IdP flows | metric: violations in analyzed flows
      quote [results]: "In §8.2, we reveal 3,367 violations in 5,668 SSO flows... In §8.3, we discover 7,415 violations."
  * broker security downgrades — 1,872 websites experienced active downgrades
      technique: Detecting removal of PKCE, state, and nonce parameters across flow segments | metric: affected websites
      quote [results]: "we discovered 1,872 violations on 2,780 websites where brokers are actively downgrading security."
 
2025 USENIX — Universal Cross-app Attacks: Exploiting and Securing OAuth 2.0 in Integration Platforms
  population[]: 24 other (custom curated list of integration platforms); 4 code-repositories (GitHub)
  * Cross-app OAuth vulnerabilities — 16 of 18 platforms
      technique: COVScan decision-tree testing followed by manual PoC exploitation | metric: share of platforms
      quote [results]: "Out of 18 platforms analyzed, 16 are susceptible to cross-app OAuth attacks"
  * COAT attacks — 11 platforms, including 7 COATU and 5 COATD cases
      technique: Testing universal and distinct redirect-URI handling | metric: number of platforms
      quote [results]: "Specifically, 11 platforms are vulnerable to COAT attacks: 7 to the COATU variant, 5 to the COATD variant, including 1 platform susceptible to both."
  * CORF attacks — 5 platforms
      technique: Replacing redirect-URI identifiers and authorization codes | metric: number of platforms
      quote [results]: "Additionally, 5 platforms are subject to CORF attacks."
  * Single-click attacks — 9 of 18 platforms
      technique: Evaluating CSRF protection, access isolation, and automatic authorization | metric: share of platforms
      quote [results]: "Furthermore, 9 platforms fall in the worst-case scenario, where an end-user can be compromised with a single click and without the need of the attacker to distribute the malicious app."
 
2026 NDSS — Connecting the Dots: An Investigative Study on Linking Private User Data Across Messaging Apps
  population[]: 300 websites (Similarweb statistics (top 300 websites in S. Korea)); 85053 web-pages (custom seed list of authentication webpages); 155147 other (custom seed list of South Korean phone numbers); 5000 other (custom seed list of phone numbers); 4000 documents (custom logo image dataset); 1000 documents (custom classifier evaluation dataset)
  * contact-discovery profile enumeration — 105,366 of 155,147 KakaoTalk numbers; 67.9%
      technique: Queried randomly generated South Korean phone numbers across four messaging apps. | metric: registration rate and retrieved users
      quote [results]: "among these, 105,366 users were successfully added as contacts over 10 days (registration rate: 67.9%)."
  * OAuth access-token exposure — 63 websites exposed tokens; 16 exposed them in URLs
      technique: Crawled login pages and inspected URLs, cookies, and browser storage. | metric: share of websites
      quote [introduction]: "Among the 63 vulnerable websites, we observe explicitly exposed access tokens in the URLs used by the third-party scripts in 16 websites."
  * third-party token access — 56 of 63 token-exposing websites deployed third-party scripts
      technique: Manually examined embedded third-party scripts on token-exposing pages. | metric: number of websites
      quote [results]: "Among the 63 websites that expose their tokens, 56 websites deploy third-party scripts."
  * Tinder location inference — 324 meters with 40 queries
      technique: Varied forged GPS locations and used binary-search distance queries. | metric: average localization error
      quote [evaluation]: "Additionally, with 40 queries, the average error is 324 meters."
  * cross-platform identity linking — 70 of 88 sampled Telegram users identified; 79.55%
      technique: Cross-referenced phone numbers and profiles between messaging platforms. | metric: identified users and success rate
      quote [results]: "Overall, 70 out of 88 users were identified via cross-referencing, achieving a success rate of 79.55%."
  * cross-platform location tracking — 336 and 418 meters for two targets
      technique: Matched KakaoTalk face embeddings against Tinder profiles, then inferred locations. | metric: localization error
      quote [results]: "The localization errors between the actual and inferred positions were 336 meters and 418 meters for the two targets, respectively."
  * trajectory tracking — approximately 335 meters
      technique: Repeated Tinder location updates and applied the location-inference attack. | metric: average localization error
      quote [results]: "The average error between the actual and inferred locations was approximately 335 meters."
  * messaging-app account overlap — 84% of sampled users in Telegram, WhatsApp, and Signal also appeared on KakaoTalk
      technique: Sampled phone numbers and computed pairwise overlap coefficients. | metric: overlap coefficient
      quote [introduction]: "84% of sampled phone number owners in Telegram, WhatsApp, and Signal are also found on KakaoTalk (§XI-B)."
 
---------- [MFA] ----------
 
2021 USENIX — Is Real-time Phishing Eliminated with FIDO? Social Engineering Downgrade Attacks against FIDO Protocols
  population[]: 100 websites (Alexa's top 100 websites); 51 human-participants (custom participant recruitment)
  * FIDO downgrade phishing susceptibility — 55% (28 of 51)
      technique: Phishing website, mock FIDO prompt, alternative OTP, and behavioral classification. | metric: share of participants classified susceptible in practice
      quote [results]: "Given our conservative measures in classifying susceptibility, our results suggest that at least 55% (Case 1) of participants would be susceptible to our phishing attacks in practice."
  * Phishing-attempt awareness — 43% of participants; 10% both detected and avoided the attacks
      technique: Interview responses coded for phishing emails and genuine phishing indicators. | metric: share of participants aware of phishing attempts
      quote [results]: "In contrast, 43% of participants (Cases 3 + 4) were classified as aware of phishing attempts, but only the Case 4 participants (10% of all participants) are likely to detect the discussed phishing attempts in practice."
  * FIDO alternative availability — 23 of 23 FIDO-enabled websites
      technique: Manual documentation review and account-based policy testing. | metric: share of FIDO-supporting sites allowing weaker alternatives
      quote [introduction]: "all websites that support FIDO (23 out of 100) allow choosing weaker alternatives."
 
2022 USENIX — Phish in Sheep's Clothing: Exploring the Authentication Pitfalls of Browser Fingerprinting
  population[]: 20000 websites (Alexa top 20K); 300 websites (Alexa top 20K); 71343 websites (Phish-A); 82431 websites (Phish-B); 173269 websites (APWG)
  * login-page discovery — 11,527 websites
      technique: Crawled Alexa sites and searched same-domain links and URL keywords. | metric: number of login pages found
      quote [methodology]: "With this approach we have located the login pages of 11,527 websites from the Alexa top 20K websites"
  * browser fingerprinting on login pages — Basic fingerprinting was widespread; advanced techniques included canvas, fonts, WebRTC, and AudioContext.
      technique: Chrome with FP-Extractor logged fingerprinting calls. | metric: counts of sites using each technique
      quote [methodology]: "When visiting a page our extension logs all fingerprinting calls."
  * fingerprint-based authentication — 16 of 300 websites
      technique: Differential testing compared remembered and new devices after clearing browsing data. | metric: share of tested websites
      quote [results]: "Our experiments reveal that only 16 out of the 300 websites use fingerprints for remembering the user's device"
  * 2FA bypass — 9 out of 14 websites; abstract reports 10 of 16 tested services
      technique: Extracted victim fingerprints, then spoofed them on a secondary device. | metric: successful bypasses
      quote [results]: "our attack can successfully bypass 2FA in 9 out of the 14 websites."
  * phishing-site fingerprint collection — 73.98%, 90.08%, and 91.36% across the three datasets
      technique: VisibleV8 execution traces over phishing-site datasets. | metric: share of sites with JavaScript traces collecting fingerprints
      quote [results]: "for the phishing websites with JavaScript execution traces, we find that the majority collect fingerprints, with 73.98%, 90.08% and 91.36% across the 3 datasets respectively."
  * phishing-site 2FA-bypass capability — Bank-A capability rose to 22.42% in the most recent dataset.
      technique: Cross-referenced collected attributes with target services' required fingerprints. | metric: sites with sufficient fingerprints
      quote [results]: "in the most recent dataset the ratio climbs to 22.42%."
 
2023 NDSS — A Systematic Study of the Consistency of Two-Factor Authentication User Journeys on Top-Ranked Websites
  population[]: 85 websites (2FA Directory); 120 websites (Tranco)
  * 2FA user-journey consistency — The average website differed in 6–7 of 14 factors.
      technique: Manual factor coding followed by pairwise Hamming distances and entropy. | metric: Hamming distance across 14 non-conditional factors
      quote [results]: "We find that the average website in our data set differs in 6-7 of those 14 factors from the other websites"
  * 2FA journey design clusters — Six inter-clusters and three conditional-factor subclusters.
      technique: Two-stage k-modes clustering of comparison-factor vectors. | metric: Number of website clusters
      quote [results]: "For the intra-clustering of the conditional factors, we found 3 clusters to best describe the data."
  * Common 2FA naming and settings location — 78 of 85 websites (92%) located 2FA settings under security-related account settings.
      technique: Manual inspection and comparison-factor categorization. | metric: Share of websites
      quote [results]: "on 78 (92%) websites, the 2FA settings are located in the security settings of the account settings under similar paths"
  * 2FA user friction from inconsistency — 60 of 308 participants (19.5%) reported reduced use, abandonment, or refusal to adopt an option.
      technique: Survey of 2FA users recruited through Prolific. | metric: Share of final respondents
      quote [appendix]: "Taken together, 60 (19.5%) of our participants reported using a website less, abandoning a website, or refusing adoption of (a specific) 2FA option."
 
2023 CCS — "We've Disabled MFA for You": An Evaluation of the Security and Usability of Multi-Factor Authentication Recovery Deployments.
  population[]: 1303 websites (2fa.directory); 71 websites (2fa.directory)
  * documented MFA recovery procedures — 321 websites (24.64%) provided no publicly accessible recovery information; 17 procedures were identified.
      technique: Manual coding of official help, support pages, and FAQs. | metric: share of websites
      quote [results]: "While 179 (13.74%) websites offered MFA using hardware tokens, no website in our sample offered them as a recovery procedure."
  * MFA recovery success — 37 of 71 accounts (52.11%)
      technique: Created accounts, configured MFA, waited one week, then attempted recovery without the MFA factor. | metric: recovered accounts
      quote [results]: "Overall, we created 71 accounts in August and September 2022. We regained access to 37 (52.11%), and lost access to 30 (42.25%)."
  * email-mediated MFA recovery — Email access was sufficient for 26 recovered accounts (70.27%).
      technique: Measured whether access to the associated email inbox enabled recovery. | metric: share of recovered accounts
      quote [results]: "The majority of accounts, to which we regained access, it was sufficient to have email access (26, 70.27%)"
  * documentation-experience mismatch — Only 9 of 71 websites (12.68%) matched on available MFA methods and recovery procedures.
      technique: Compared observed setup and recovery processes with saved help-page screenshots. | metric: matching documentation
      quote [results]: "we still only find 9 (12.68%) of all help and support pages to match our experience regarding available MFA methods and recovery procedures."
  * deployed MFA methods — Mobile applications appeared on 1,036 pages (79.51%); SMS appeared on 559 (42.90%).
      technique: Manual categorization of methods documented by websites. | metric: share of websites
      quote [results]: "mobile applications were the most popular MFA method, deployed on 1,036 pages (79.51%), mostly as TOTP generator apps. Second most popular were SMS (559, 42.90%)."
  * recovery-procedure configuration — 50 of 71 websites (70.42%) had at least one configured recovery procedure.
      technique: Recorded whether accounts were prompted to configure recovery during MFA setup. | metric: share of websites
      quote [results]: "Overall, we set up at least one MFA recovery procedure on 50 (70.42%) websites."
 
2023 USENIX — A Study of Multi-Factor and Risk-Based Authentication Availability
  population[]: 5000 websites (Tranco); 366 websites (Innocenti et al. dataset); 235 websites (custom seed list)
  * MFA availability — 88 of 208 sites (42.3%) supported MFA
      technique: Manual inspection of account settings and MFA enrollment options | metric: share of audited sites
      quote [results]: "Only 88 sites (42.3%) support some form of MFA"
  * RBA suspicious-login blocking — 46 of 208 sites (22.1%) blocked the suspicious login attempt
      technique: Changed IP, operating system, browser, and screen resolution | metric: share of audited sites
      quote [results]: "We found that 46 sites (22.1%) blocked the suspicious login attempt."
  * RBA alerting — 23 sites alerted users without blocking
      technique: Observed whether suspicious logins generated email alerts | metric: share of audited sites
      quote [results]: "23 sites did not block the suspicious login attempt, but did send an email to the user alerting them of the login."
  * SSO authentication inheritance — 80.29% had or could inherit MFA; 72.60% had or could inherit blocking RBA
      technique: Recursively traversed SSO-provider relationships | metric: share of audited sites
      quote [results]: "167 sites (80.29%) in our set either have MFA or could inherit it through SSO providers."
  * Post-login account protection — 10 of 50 blocked password changes; 19 of 40 sent change alerts
      technique: Tested account settings, personal-information changes, and password changes | metric: share of sampled sites
      quote [results]: "Only 10 sites blocked us from changing the account password by requiring email verification, and among the remaining 40 sites that allowed the password change, just 19 sent an email or SMS alert"
  * Cookie-stealing resistance — 10 of 46 blocking sites blocked access after cookie copying
      technique: Copied domain cookies to the suspicious machine and tested account access | metric: share of blocking sites
      quote [results]: "10 of these sites blocked us from accessing the account"
 
2025 NDSS — ”Who is Trying to Access My Account?” Exploring User Perceptions and Reactions to Risk-based Authentication Notifications
  population[]: 251 websites (Tranco)
  * Risk-based authentication notifications — 161 RBA email notifications from 251 websites
      technique: Triggered correct-password, incorrect-password, and password-reset events across websites. | metric: number of websites producing notifications and emails received
      quote [conclusion]: "Our RBA notification tests are conducted on 251 websites from the top 5K listed on Tranco. We have received 161 RBA email notifications from these 251 sites."
 
2025 NDSS — Was This You? Investigating the Design Considerations for Suspicious Login Notifications
  population[]: 100 websites (Tranco)
  * suspicious login notifications — 34 domains produced notifications; 21 distinct website notifications were gathered.
      technique: Create accounts and trigger unusual logins via new device and location. | metric: notifications collected
      quote [methodology]: "From this process, we collected suspicious login notifications from 34 domains... Thus, in total, we gathered distinct login notifications across 21 websites."
  * notification design diversity — Collected notifications exhibited diverse components and design decisions.
      technique: Independent manual categorization of collected notification components. | metric: component prevalence across 21 notifications
      quote [methodology]: "From this analysis, we observed common notification components, but diversity in design decisions, as discussed below."
 
---------- [PASSKEY] ----------
 
2022 PETS — How Not to Handle Keys: Timing Attacks on FIDO Authenticator Privacy
  population[]: 111 other (FIDO Alliance certified devices); 8 other (FIDO Alliance certified Level 1 hardware authenticators); 1000000 domains (Cisco Umbrella set); 3 human-participants (not-stated)
  * timing vulnerability in FIDO2 authenticators — 2 of 8 hardware authenticators were vulnerable
      technique: Compared silent-authentication times for random and bad-origin key handles. | metric: average timing difference
      quote [results]: "We successfully executed timing attacks on HyperFIDO Titanium Pro (average difference of 10ms per execution) and Feitian K26 token (average difference of 2ms per execution)."
  * key-handle linking attack — 0.1% error for HyperFIDO and 6% for Feitian when user-presence timing was known
      technique: Compared WebAuthn execution times using random versus candidate key handles. | metric: classifier error rate
      quote [results]: "A simple threshold based classifier correctly identifies key handles with a 0.1% error (HyperFido) and 6% error (Feitian) if user presence timing is known."
  * silent authentication in browsers — All tested desktop browser configurations generally permitted the attack; platform limitations varied
      technique: Inspected browser behavior and USB traffic for allowCredential lists. | metric: browser/platform support
      quote [methodology]: "We found that all browsers considered in this study (Chrome, Brave, Firefox, Opera, Edge and Safari) parse an allowCredential parameter with multiple key handles in this way."
  * FIDO2 deployments in the wild — 684 WebAuthn execution records among one million popular DNS records
      technique: Crawled JavaScript resources for navigator.credentials.create. | metric: share of high-traffic DNS records
      quote [results]: "We gathered 684 records of WebAuthn executions from which we extracted following groups."
  * non-resident-key deployment — Almost all identified implementations used non-resident keys; only Microsoft passwordless login used resident keys
      technique: Categorized crawled FIDO2 implementations by key configuration. | metric: share of deployments
      quote [results]: "In the public space FIDO2 is mostly used as a second factor mechanism with non-resident keys."
 
2023 CCS — Evaluating the Security Posture of Real-World FIDO2 Deployments.
  population[]: 100000 domains (Tranco); 1000 domains (Tranco); 160 other (FIDO Alliance's Metadata Service (MDS)); 200878 other (partner RP authentication server logs); 14616 other (partner RP authentication server logs)
  * FIDO2 deployment support — 85 domains supported WebAuthn; 40 distinct RPs; 29 evaluated
      technique: Manual inspection and semi-automated configuration assessment | metric: number of domains/RPs
      quote [methodology]: "Of these domains, we identified 85 supporting FIDO2's WebAuthn... In total, we aggregated the FIDO2-supporting domains into 40 distinct RPs... we could create accounts on and evaluate 29 RPs"
  * Virtual authenticator acceptance — 27/29 RPs allowed a virtual authenticator to register
      technique: Attempted registration using Chrome virtual authenticator configurations | metric: share of RPs accepting registration
      quote [results]: "we find that 27/29 RPs - including financially sensitive RPs such as BofA, PayPal, Binance, Stripe, and eBay, allow even a virtual authenticator to be registered."
  * Authenticator attestation distribution — Approximately 71% Apple, 27% Android SafetyNet, 1% unattested, and one self-attested response
      technique: Parsed WebAuthn attestation payloads from RP logs | metric: share of registrations
      quote [results]: "From the 200,878 WebAuthn responses in the entire bulk WebAuthn data, we were able to parse ∼ 72% of responses as coming from Apple-attested authenticators, ∼ 1% without any attestation, and 1 self-attested response."
  * Authenticator malware-resistance certification — 7/160 had Level 2 certification; 96% lacked malware-resistance certification
      technique: Analyzed FIDO MDS certification levels | metric: share of available authenticators
      quote [results]: "only 7 out of 160 (4%) authenticators have L2 certification... 96% of authenticators available today did not receive FIDO Alliance's malware-resistance certification"
  * Hardware-backed SafetyNet attestations — Approximately 94% were hardware-backed
      technique: Parsed SafetyNet evaluationType fields | metric: share of SafetyNet attestations
      quote [results]: "We found that ∼94% of attestations in the SafetyNet WebAuthn sample were hardware-backed"
  * Compromised mobile authenticators — Approximately 0.25% hardware-backed and 13% non-hardware-backed indicated compromise
      technique: Analyzed SafetyNet device-integrity results | metric: share of attestations by hardware status
      quote [results]: "∼0.25% indicated compromise... and ∼13% of the non-hardware-backed SafetyNet attestation indicated compromise"
  * RP authenticator preferences — Only 3/29 required user verification; 5/29 preferred platform authenticators; 14/29 requested attestation
      technique: Manually inspected WebAuthn challenge parameters | metric: share of RPs declaring preferences
      quote [results]: "only 3/29 RPs required user verification... only 5/29 RPs declare a preference for platform authenticators"
  * Background WebAuthn social engineering — Automated attack executed in seconds
      technique: Chrome extension proof-of-concept on PayPal and eBay | metric: attack execution time
      quote [evaluation]: "The attack is automated and takes only seconds to execute (e.g., time for the page load and for the user to provide biometrics)."
 
2025 PETS — SoK: Web Authentication and Recovery in the Age of End-to-End Encryption
  population[]: 300 websites (Alexa Top 1M dataset); 22 other (not-stated); 245 documents (relevant academic venues and citation searches)
  * Direct passkey support — 17 of 162 sites (10.5%)
      technique: Manual inspection of top-300 websites' login and account-creation flows. | metric: share of audited deduplicated domains
      quote [results]: "Of these 162 sites, we find 17 sites (10.5%) offer direct passkey support for user authentication."
  * Direct or indirect passkey support — 87 of 162 sites (53.7%)
      technique: Manual inspection including single-sign-on providers supporting passkeys. | metric: share of audited deduplicated domains
      quote [results]: "If we include sites which offer indirect passkey support through SSO, 87 of 162, or 53.7%, of sites in the top 300 directly or indirectly offer passkey support"
  * E2EE recovery-code deployment — 17 of 22 providers offered or mandated recovery codes
      technique: Review of deployed recovery mechanisms across 22 E2EE providers. | metric: number of providers
      quote [results]: "We find that recovery codes are the primary backup method used to recover access to encrypted data, with 17 of the 22 providers surveyed offering or mandating this backup method."
  * E2EE recovery-mechanism diversity — Six offered automatic storage, two offered PINs, and five offered social authentication.
      technique: Manual comparison of provider authentication and recovery options. | metric: number of providers by mechanism
      quote [results]: "six of the 22 providers offered the ability to automatically save the recovery code in either third-party storage ... Two providers allowed short PINs ... five providers offered some form of social authentication."
  * Authentication-literature topic distribution — 41.6% focused on passwords
      technique: Keyword search, citation search, and manual title and abstract screening. | metric: share of included papers
      quote [results]: "Overall, we find that 41.6% of academic authentication research has focused on passwords"
 
2025 USENIX — A Framework for Abusability Analysis: The Case of Passkeys in Interpersonal Threat Models
  population[]: 200 websites (Tranco); 15 websites (Tranco); 6 websites (custom seed list)
  * Passkey abuse vectors — Each hypothesized abuse vector was viable on at least one service.
      technique: Six-stage framework with analyst brainstorming and stepthrough protocols. | metric: seven hypothesized abuse vectors
      quote [methodology]: "As we will see, each hypothesized abuse vector was viable on at least one service."
  * Adversarial biometrics — Adding adversarial biometrics succeeded for all services.
      technique: Added attacker fingerprints, then attempted passkey logins across client platforms. | metric: 30 stepthroughs across 10 services and three configurations
      quote [results]: "Adding adversarial biometrics succeeded for all services, demonstrating that any registered biometric suffices to unlock any passkey."
  * Passkey cloning — Authentication succeeded for all twelve services with functioning implementations.
      technique: Exported or synchronized passkeys to adversarial devices and tested remote login. | metric: 21 stepthroughs
      quote [results]: "All three passkey cloning mechanisms allowed analysts to log into the twelve services that had functioning passkey implementations."
  * Adversarial passkeys — Successful on ten services.
      technique: Registered attacker-controlled passkeys on victim accounts and tested subsequent access. | metric: 12 stepthroughs
      quote [results]: "We find that adding a remote adversarial passkey is successful on Adobe, Amazon, Github, Google, Ebay, Intuit, LinkedIn, Microsoft, Roblox, and Samsung."
  * Passkey deletion — Authentication was denied for all studied services.
      technique: Deleted client-stored credentials and attempted victim authentication. | metric: 21 stepthroughs
      quote [results]: "For all services, authentication was denied using the (now deleted) passkey, as expected."
  * Passkey revocation — Succeeded for eleven services.
      technique: Revoked service-side passkeys through account interfaces and tested login. | metric: 12 stepthroughs
      quote [results]: "Adversarial passkey revocation succeeded for eleven services (see Figure 6)."
  * Gaslighting through ASIs — Gaslighting was achievable when attackers controlled security-relevant ASI information.
      technique: Spoofed user-agent strings, locations, and passkey labels. | metric: three spoofing mechanisms
      quote [results]: "Gaslighting can be achieved when the adversary controls information shown to the victim in security-relevant ASIs."
 
2026 USENIX — The State of Passkeys: Studying the Adoption and Security of Passkeys on the Web
  population[]: 1000000 websites (Tranco 1M); 18000000 websites (CrUX 18M); 12 other (community directories); 872 websites (PASSKEYS-RADAR merged sources); 208 websites (confirmed independent passkey implementations); 103 websites (websites selected for full security evaluation)
  * Passkey-enabled websites — 872 unique websites
      technique: Merge directories, well-known-file scans, and WebAuthn API detection | metric: number of unique websites
      quote [results]: "After merging (§3.2), 872 unique websites remained."
  * Historical passkey adoption — 05/2021 to 08/2025
      technique: Retrieve archived directory snapshots from the Wayback Machine | metric: number of websites over time
      quote [results]: "Figure 5: Adoption of Passkeys from 05/2021 to 08/2025."
  * Passkey management weaknesses — 66% allowed immediate registration without additional confirmation
      technique: Manual registration, authentication, and account-management testing | metric: share and count of audited sites
      quote [results]: "The majority of sites (66%) allowed immediate registration without any additional confirmation."
  * Deprecated cryptographic algorithms — All but one site requested deprecated cryptographic algorithms; 90 used recommended ones
      technique: Inspect requested and supported WebAuthn algorithms | metric: number of websites
      quote [introduction]: "All but one site requested deprecated cryptographic algorithms, and only 90 of 208 RPs used the recommended ones."
  * Passkey security vulnerabilities — 103 of 103 had at least one issue; 18 critical and 53 high severity
      technique: Semi-automated manipulation of WebAuthn messages using 28 detection methods | metric: number of vulnerable websites
      quote [results]: "We found that all of the analyzed websites (103) are vulnerable to at least one AT."
  * Dangling related origins — One available domain could affect 72 related origins
      technique: DNS resolution followed by domain-registration availability checks | metric: allowlisted domains
      quote [results]: "We found one allowlisted domain available for registration for 10C/year. If acquired, it would allow an attacker to take over accounts on 72 related origins."
  * Account enumeration — 68 websites vulnerable in passkey authentication
      technique: Compare allowCredentials and error responses across three account types | metric: number of vulnerable websites
      quote [results]: "We found 68 websites vulnerable to account enumeration in their passkey authentication."
  * WebAuthn framing validation failures — All but one website failed to validate protections
      technique: Alter cross-origin, top-origin, and framing-related message parameters | metric: number of websites
      quote [results]: "We found that all but one website failed to validate the built-in clickjacking protections of WebAuthn."
 
2026 NDSS — Anchors of Trust: A Usability Study on User Awareness, Consent, and Control in Cross-Device Authentication
  population[]: 100 websites (Tranco top site list); 10 other (Sitereview); 27 other (custom seed list)
  * User-right support in XDAuth — None of the 27 services fully safeguarded all three rights
      technique: Manual assessment using 15 evaluation metrics | metric: share of evaluated services
      quote [results]: "none of the 27 evaluated services fully safeguard all three user rights in XDAuth."
  * Missing device or environment information — 14 of 27 services provided no device or environment information
      technique: Manual inspection of authentication interfaces | metric: number of services
      quote [results]: "Among the 27 services, over half (14) provide no device or environment information (e.g., model, geolocation)"
  * Missing login notifications — 10 of 27 services provided no real-time login notification
      technique: Manual inspection of post-authentication workflows | metric: number of services
      quote [results]: "many evaluated services (10/27) fail to provide any form of real-time notification when a login occurs"
  * Unavailable session revocation — Six services provided no means to revoke active sessions
      technique: Manual testing of session-management interfaces | metric: number of services
      quote [results]: "Six evaluated services provide no means to revoke active sessions"
  * User preference for rights-preserving designs — 91% preferred know, 73% consent, and 85% control designs
      technique: Questionnaire comparisons of paired interface designs | metric: preference percentage
      quote [results]: "participants overwhelmingly preferred the rights-preserving version (Table IV)."
  * Interactive validation of user preferences — 8 preferred consent; 9 favored know and control
      technique: Functional prototype task followed by questionnaire | metric: number of participants
      quote [results]: "Eight preferred the design implementing the right to consent, nine favored the right to know and right to control."
 
---------- [LOGINSURF] ----------
 
2017 WWW — Security Implications of Redirection Trail in Popular Websites Worldwide.
  population[]: 1000000 websites (Alexa top 1M list); 10000 websites (Alexa top 10K websites); 2000 websites (Alexa top 1M list)
  * Insecure redirection trails — 55.0% (512,007/931,135) in the top 1M; 39.1% (3,582/9,159) in the top 10K
      technique: Followed four initial URL trails and marked any HTTP request as attackable. | metric: share of reachable websites
      quote [results]: "The most insecure trail is Attackable (Home Redirect) → HTTP (Home Page), and 512,007 (55.0%) of the reachable websites follow this insecure trail."
  * HTTPS-only pages with attackable redirects — 83.3% (119,102/143,022) in the top 1M; 78.6% (1,779/2,262) in the top 10K
      technique: Compared home-page HTTPS support with protocols used during preceding redirects. | metric: share of HTTPS-only home pages
      quote [results]: "Among the 2,262 websites that support HTTPS-only connection on their home pages, 1,779 (78.6%) still leave the Home Redirect phase attackable."
  * HTTP login submissions — 36.6% (953/2,604) sent login credentials over HTTP
      technique: Filled fictitious credentials and inspected intercepted browser traffic. | metric: share of successful login submissions
      quote [methodology]: "At the same time, the crawler records the traffic sent by the browser and checks whether the username and password can be extracted from the intercepted traffic."
  * Redirection inconsistencies — 20.5% (190,711/931,135) contained at least one inconsistency
      technique: Represented four trails as directed graphs and compared convergence, domains, and configurations. | metric: share of reachable websites
      quote [results]: "Of the 931,135 websites reachable on at least one trail, 190,711 (20.5%) contain at least one inconsistency mentioned below."
  * HSTS misconfiguration — 84.2% (35,008/41,575) of HSTS-setting websites had misconfiguration
      technique: Inspected Strict-Transport-Security headers, protocols, and includeSubDomains settings. | metric: share of websites setting HSTS
      quote [results]: "Even worse, among the 41, 575 websites that set HSTS on at least one trail, only 6,567 (15.8%) correctly implemented HSTS on all four trails that we checked."
  * Redirection-pattern diversity — 9,951 patterns; the 66 most popular covered 85% of reachable websites
      technique: Constructed directed graphs from four common initial URL trails. | metric: number of distinct patterns
      quote [results]: "Among the top 1M websites, 931, 135 are reachable through at least one trail and can be classified into 9, 951 different redirection patterns."
 
2020 CCS — The Cookie Hunter: Automated Black-box Auditing for Web Authentication and Authorization Flaws.
  population[]: 1585964 domains (Alexa Top 1 million)
  * authentication-cookie exposure over HTTP — 12,014 domains (48.43%) initially; 10,921 remained vulnerable after HSTS analysis
      technique: CookieAuditor tests secure flags and replays requests without protected cookies | metric: share of audited domains
      quote [results]: "We find that 12,014 unique domains do not protect their authentication cookies with the secure flag"
  * JavaScript cookie stealing exposure — 5,680 domains (22.9%) lacked httpOnly protection; 5,099 also embedded third-party scripts
      technique: Tests httpOnly protection and embedded third-party scripts executing in the first-party origin | metric: share of audited domains
      quote [results]: "A total of 5,680 domains do not protect them with the httpOnly flag. Our framework's analysis of those domains reveals that 5,099 include at least one embedded 3rd party script"
  * personal-data leakage after cookie hijacking — 9,324 domains according to the abstract; Table 3 reports 9,122 (78%)
      technique: Differential authenticated/logged-out browsing plus source, storage, URL, encoding, and hash inspection | metric: domains exposing supplied user data
      quote [abstract]: "Our system also automatically identifies the privacy loss caused by exposed cookies and detects 9,324 domains where sensitive user data can be accessed by attackers"
  * HSTS deployment errors — 10,495 had no HSTS; 426 had faulty HSTS and remained vulnerable
      technique: Checks preload status and passively captures HTTP-to-HTTPS redirections and HSTS policies | metric: domains by HSTS outcome
      quote [implementation]: "Our module first checks whether the domain is in the Chromium preload list and, if not, uses a passive proxy to capture the target website's redirection flow from its HTTP endpoint to HTTPS."
  * authentication-cookie combinations — 1.21 authentication cookies and 1.1 combinations on average
      technique: Modified partially ordered-set search with cookie-removal and login-state oracles | metric: mean authentication cookies and combinations per susceptible domain
      quote [results]: "Susceptible domains set 1.21 authentication cookies and have 1.1 authentication combinations on average."
 
2022 USENIX — Pre-hijacked accounts: An Empirical Study of Security Failures in User Account Creation on the Web
  population[]: 75 websites (Alexa global website rankings)
  * Account pre-hijacking vulnerabilities — At least 35 of 75 services were vulnerable to one or more attacks.
      technique: Manual testing of account creation and recovery workflows. | metric: vulnerable services
      quote [abstract]: "we analyzed 75 popular services and found that at least 35 of these were vulnerable to one or more account pre-hijacking attacks."
  * Classic-Federated Merge Attack — 13 of 54
      technique: Tested classic and federated account creation and account merging. | metric: vulnerable services among potentially vulnerable services
      quote [results]: "Classic-Federated Merge 54 13"
  * Unexpired Session Attack — 19 of 74
      technique: Tested password resets while retaining prior authenticated sessions. | metric: vulnerable services among potentially vulnerable services
      quote [results]: "Unexpired Session 74 19"
  * Trojan Identifier Attack — 12 of 49
      technique: Tested persistence of attacker-linked identifiers after account recovery. | metric: vulnerable services among potentially vulnerable services
      quote [results]: "Trojan Identifier 49 12"
  * Unexpired Email Change Attack — 11 of 72
      technique: Tested pending email-change capabilities across password resets. | metric: vulnerable services among potentially vulnerable services
      quote [results]: "Unexpired Email Change 72 11"
  * Non-verifying IdP Attack — 1 of 3
      technique: Tested custom and non-verifying identity providers during signup. | metric: vulnerable services among potentially vulnerable services
      quote [results]: "Non-verifying IdP 3 1"
  * Individual vulnerabilities — At least 56 vulnerabilities across 35 services.
      technique: Repeated manual attack tests and documented vulnerable services. | metric: individual vulnerabilities
      quote [results]: "We identified at least 56 individual vulnerabilities across all attack types and services."
 
2023 USENIX — A Large-Scale Measurement of Website Login Policies
  population[]: 2800 domains (Tranco); 1000000 domains (Google Chrome User Experience Report (CrUX))
  * insecure login-page transport — nearly 2K domains served login pages only over HTTP; 21.2K additionally offered HTTP
      technique: Crawled login pages over HTTP and HTTPS; recorded redirects and mixed content. | metric: share of analyzed domains
      quote [results]: "across the 358.9K domains with a login page found, we found nearly 2K domains where the login page was served only over HTTP"
  * login credential copy-paste blocking — 3.2K domains disallowed copy-pasting either username or password
      technique: Used Selenium Actions API to paste test values into username and password fields. | metric: share of login-page domains
      quote [results]: "Out of 358.9K domains with login pages found, we detected 3.2K of the domains disallowed copy-pasting either the email/username or the password field."
  * plaintext password transmission — 2.2K domains could transmit passwords over HTTP
      technique: Inspected login form action attributes for HTTP submission. | metric: share of analyzed login forms
      quote [results]: "we uncovered 2.2K domains that could transmit the password over HTTP"
  * plaintext password disclosure — 570 domains sent an email containing the plaintext password
      technique: Monitored controlled email accounts after registration, verification, and password reset. | metric: domains sending plaintext passwords by email
      quote [results]: "In total, we observed 570 domains that sent an email containing our plaintext password"
  * typo-tolerant password authentication — 273 domains exhibited typo-tolerance
      technique: Attempted six predefined password typos and classified login success. | metric: domains accepting at least one typo
      quote [results]: "we found 273 domains exhibiting typo-tolerance during logins."
  * user enumeration — 5.9K domains (19%) exhibited a user-enumeration vulnerability
      technique: Compared normalized error messages for valid and invalid usernames. | metric: share of analyzed domains
      quote [results]: "We uncovered 5.9K domains (19%) exhibiting some form of user enumeration vulnerability"
  * login rate limiting — 4,335 domains (24%) demonstrated some rate-limiting measure
      technique: Performed 15 rapid invalid logins followed by valid-login attempts. | metric: share of fully evaluated domains
      quote [results]: "Across the 18.0K domains successfully evaluated, we observed 4335 domains (24%) demonstrating some rate limiting measure."
  * third-party scripts on login pages — 296.9K sites (82.7%) had a login page with a third-party script
      technique: Extracted script src attributes and compared script and page domains. | metric: share of login pages with third-party scripts
      quote [appendix]: "In total, 296.9K (82.7%) sites had a login page with a third-party script."
 
2023 CCS — Measuring Website Password Creation Policies At Scale.
  population[]: 2800 domains (Tranco); 1000000 domains (Tranco)
  * website password creation policies — 20,119 domains
      technique: Black-box account signups with systematically varied passwords | metric: successfully evaluated domains
      quote [results]: "This filtering leaves us with 20,119 domains for which we successfully analyze password policies."
  * minimum password length — ∼12% allow single-character passwords
      technique: Testing accepted passwords and binary-searching length bounds | metric: share of evaluated sites
      quote [results]: "we find that a non-trivial fraction of sites (∼12%) allow single-character passwords."
  * unsupported password characters — over 30% do not support spaces, Unicode, or emojis
      technique: Injecting spaces, Unicode, emojis, and special symbols into admissible passwords | metric: share of sites
      quote [results]: "We observe over 30% of sites do not support spaces, Unicode, or emojis in passwords"
  * breached-password acceptance — 88% allow breached passwords
      technique: Testing highest-ranked passwords from a breach dataset | metric: share of signup sites
      quote [results]: "We observe limited deployment of such password blocking though, as 72% of sites permit dictionary words as passwords and 88% allow breached passwords."
  * CAPTCHA solving — 94% correctly solved
      technique: Fingerprinting supported CAPTCHA HTML/JavaScript and submitting to AZcaptcha | metric: CAPTCHA solve rate
      quote [methodology]: "During our full measurement, AZcaptcha correctly solved 94% of all CAPTCHAs we encountered"
 
2024 WWW — The Double Edged Sword: Identifying Authentication Pages and their Fingerprinting Behavior.
  population[]: 100000 domains (Chrome User Experience Report (CrUX)); 10000 websites (Chrome User Experience Report (CrUX)); 5000 web-pages (custom seed list); 998 web-pages (custom seed list)
  * browser fingerprinting — 9.2% of visited pages
      technique: Instrumented API calls for Canvas, WebRTC, Canvas Font, and AudioContext. | metric: share of visited pages
      quote [results]: "Table 5 shows that 9.2% of the pages our crawler visited were flagged as fingerprinting."
  * browser fingerprinting on authentication pages — 10.2% of login and sign-up pages
      technique: Englehardt–Narayanan heuristics applied to instrumented API calls. | metric: share of authentication pages
      quote [results]: "when we consider only login and sign-up pages, the percentage rises slightly to 10.2%"
  * Canvas fingerprinting — 93.10% of fingerprinting homepages
      technique: Detect canvas text rendering and toDataURL use without save, restore, or addEventListener. | metric: share of fingerprinting homepages
      quote [results]: "nearly every homepage that performs fingerprinting engages in canvas fingerprinting (93.10%)."
  * tracking fingerprinting scripts — 50.50% on login pages and 55.65% on sign-up pages
      technique: uBlock Origin Core classifications based on blocklists. | metric: share of fingerprinting scripts
      quote [results]: "home pages have the highest rate of tracking at 61.46%, compared to login pages at 50.50% and sign-up pages at 55.65%."
  * same third-party fingerprinting scripts — 505 of 515 domains (98.06%)
      technique: Compared domains providing scripts on login and sign-up pages. | metric: share of domains fingerprinting on both pages
      quote [results]: "Of these 515 domains, 505 (98.06%) used scripts from the same set of third parties"
  * fingerprinting blocked functionality — Disruptions observed on deezer.com and hepsiburada.com
      technique: Manual inspection with JShelter enabled on 30 websites. | metric: manually inspected websites
      quote [results]: "Due to the scalability challenges, we conducted a manual inspection of 30 websites where fingerprinting attempts were detected on login pages."
 
2024 CCS — Poster: Security of Login Interfaces in Modern Organizations.
  population[]: 100 websites (Fortune report); 73431 web-pages (custom seed list)
  * Login-page vulnerabilities — 9,417,308 vulnerabilities across 52,461 analyzed login-page URLs
      technique: Passive ZAP scanning of collected login pages | metric: vulnerability count and normalized alerts per scanned URL
      quote [results]: "The ZAP scans succeeded on 56k out of the 73.5k login pages, and identified more than 9M vulnerabilities."
  * Eight vulnerability categories — CSP affected 90.18%; Cookie 54.55%; XSS/CSRF 39.34%
      technique: Grouped 73 ZAP alert types and retained high-evidence vulnerabilities | metric: percentage of analyzed login-page URLs
      quote [results]: "We classified the 73 identified vulnerabilities into 8 issues, including the Content Security Policy (CSP) which affects (90.18%) of the 52,461 login page URLs."
  * Hosting-model distribution — 35,809 Cloud, 15,111 External, 13 Hybrid, and 569 On-Premise scanned URLs
      technique: DNS A/AAAA resolution followed by FindIP classification | metric: URLs and vulnerabilities by hosting model
      quote [results]: "# Scanned URLs 35,809 15,111 13 569"
 
2024 CCS — Stealing Trust: Unraveling Blind Message Attacks in Web3 Authentication.
  population[]: 18 websites (DappRadar's Top Decentralized Marketplaces list); 9 websites (Google searches); 29 other (custom seed list)
  * blind message attacks — 75.8% (22/29)
      technique: Injected attack payloads into authentication API requests and analyzed responses. | metric: share of Web3 authentication deployments
      quote [results]: "Web3AuthChecker reports that 75.8% (22/29) of Web3 authentications belonging to 20 websites are vulnerable to Blind Message Attacks."
  * replay attacks — 11 cases
      technique: Repeated AUTH requests and altered, removed, or reused nonce values. | metric: number of vulnerable test cases
      quote [results]: "At the same time, we identified critical risks in two cases, and we have informed the respective vendors. Also, 11 cases are at the risk of Replay Attacks"
  * blind multi-message attacks — 7 cases
      technique: Tested message-body omission, modification, and non-equality verification. | metric: number of vulnerable test cases
      quote [results]: "Overall, these two vulnerabilities could be exploited for blind multi-message attacks, suggesting that all seven websites are at such risk"
  * Web3AuthGuard attack detection — 20 of 25 websites
      technique: Compared test messages against extracted templates using regular-expression matching. | metric: successful detections among user-login cases
      quote [results]: "Web3AuthGuard was effective in detecting Blind Message Attacks on 20 of the 25 tested websites."
 
2024 CCS — Unmasking the Security and Usability of Password Masking.
  population[]: 100 domains (Google CrUX Top 1K domains list); 202 human-participants (Prolific); 600 human-participants (Prolific)
  * browser password masking — All browsers implemented masking without a toggling option.
      technique: Manually observed password entry across eight browser-platform combinations. | metric: share of tested browsers
      quote [results]: "All browsers implemented masking without a toggling option for password input elements."
  * website password masking — All 66 evaluated sites employed password masking by default.
      technique: Manual login-form inspection of sampled domains on PC and mobile. | metric: share of evaluable sites
      quote [results]: "All 66 sites employed password masking by default on their login forms."
  * masking toggle availability — 25 of 66 sites allowed masking to be disabled; 41 did not.
      technique: Manual inspection of login forms and toggle controls. | metric: share of evaluated sites
      quote [results]: "Out of 66 sites, 41 sites did not support a method to toggle off or disable password masking."
  * survey-reported masking usability — Most participants reported occasional issues; mobile participants reported more challenges.
      technique: Closed-ended Likert questions and open-ended responses. | metric: participant-reported frequency and difficulty
      quote [results]: "Overall, we observed that most participants reported occasional issues, although mobile participants reported a higher rate of challenges than PC participants."
  * login usability under masking — Masking had some but ultimately limited impact on login success.
      technique: Telemetry from randomized masking workflows on a study website. | metric: login attempts, entry time, deletions, toggles, and errors
      quote [results]: "Masking has some, but ultimately limited, impact on login success. It does not seem to notably impact password entry timing, character deletions, or the type of typos made."
  * password masking toggle use — 15% of PC static-masking and 14% of PC dynamic-masking participants toggled initially.
      technique: Recorded toggle activations during login attempts. | metric: share of participants using toggle
      quote [results]: "For PC, 15% of Static Masking and 14% of Dynamic Masking participants used the toggle button on their first login."
 
2025 USENIX — Demystifying the (In)Security of QR Code-based Login in Real-world Deployments
  population[]: 100000 websites (Tranco top 100K list); 350 websites (Tranco top 100K list); 153 websites (custom seed list); 109 websites (custom seed list); 200 human-participants (Wenjuanxing)
  * QRLogin deployment prevalence — 350 confirmed QRLogin websites from 611 candidates
      technique: Keyword heuristics, browser navigation, app-market searches, and manual confirmation. | metric: share of Tranco top-100K websites
      quote [results]: "we first automatically collect 611 QRLogin website candidates ... manual verification confirms that 350 of them indeed implement QRLogin."
  * QRLogin implementation flaws — 47 of 109 websites (43%) with 75 total flaws
      technique: Traffic capture, QR-code parsing, component matching, rule-based dynamic testing, and manual confirmation. | metric: share of testable websites and flaw instances
      quote [results]: "Among the 109 testable websites, we find 47 (43%) websites with a total of 75 flaws"
  * Unbound sessionId — 34%
      technique: Comparing cross-session QRLogin polling responses under controlled request replay. | metric: share of testable websites
      quote [results]: "Flaw-1 is relatively pervasive (34%)."
  * QRLogin user engagement — 39.44% use QRLogin every day; 43.89% several times per week
      technique: Questionnaire responses from recruited QRLogin users. | metric: percentage of valid respondents
      quote [results]: "39.44% participants utilize QRLogin every day and 43.89% use it several times per week."
  * QR code leakage risk — 41.67% never or occasionally prevent QR-code exposure
      technique: Questionnaire about protective behavior and willingness to share QR codes. | metric: percentage of valid respondents
      quote [results]: "41.67% of participants never or occasionally take measures to prevent others from obtaining their QR code."
  * QRLogin risk awareness — 15.00% correctly identified QR-code leakage risk
      technique: Questionnaire testing users’ understanding of QR-code contents and risks. | metric: percentage answering correctly
      quote [results]: "only 15.00% answer correctly about the risk of leaking QR codes."
 
2026 USENIX — Inconsistent, Incomplete, and Insecure: A Survey of Account Security Interfaces
  population[]: 100 websites (Tranco list (ID: 7XN5X))
  * account security interfaces — 200 ASIs across 71 services; 29 services had none
      technique: Manual UI discovery and stepthroughs across selected services. | metric: number of distinct ASIs and services
      quote [results]: "We discovered 200 unique ASIs from the 71 remaining services"
  * ASI design types — Seven distinct ASI types
      technique: Deductive and inductive coding followed by clustering and coverage checks. | metric: number of ASI types
      quote [methodology]: "This resulted in seven distinct ASI types (see Figure 2), expanding the 4 from Daffala et al. [14]"
  * ASI navigation complexity — 3.34 clicks on average (SD ±1.4)
      technique: Screenshot-based analysis of recorded manual navigation paths. | metric: mean clicks to reach an on-service ASI
      quote [results]: "finding that an average of 3.34 (SD ±1.4) user clicks were required to reach one from the service landing page"
  * ASI access reporting completeness — At least 39 services could not reveal whether a second device accessed the account
      technique: Compared expected active and inactive sessions with displayed logs and notifications. | metric: services with insufficient access information
      quote [introduction]: "at least 39 services provided insufficient information to determine if a second device has accessed the account"
  * device and location spoofability — 41 of 61 services with device or location descriptions were vulnerable
      technique: Changed clock, VPN location, and HTTP user-agent during attacker sessions. | metric: services vulnerable to spoofing
      quote [abstract]: "of 61 services that offered an ASI to convey device or location descriptions, 41 (67.2%) were vulnerable to spoofing attacks"
 
2026 NDSS — One Email, Many Faces: A Deep Dive into Identity Confusion in Email Aliases
  population[]: 40 other (custom seed list); 28 other (custom seed list); 100 domains (Tranco); 3310406 documents (npm API); 2219000 code-repositories (GitHub repository and query APIs); 304 human-participants (Prolific and graduate-student recruitment)
  * email-provider alias mechanisms — 28 providers tested; 12 supported additional aliasing beyond case variation and backslash handling
      technique: Register base accounts, generate variants, and test inbox delivery. | metric: provider count supporting each alias pattern
      quote [results]: "Excluding these two factors, 12 providers still support additional aliasing behaviors."
  * platform alias acceptance — 9 platforms were completely unable to counter any tested alias mechanisms
      technique: Semi-automated registration tests monitored DOM changes and page transitions. | metric: successful alias registrations across platforms
      quote [results]: "However, 9 platforms were completely unable to counter any of the alias mechanisms from the tested email providers."
  * public alias usage — 310,136 of 2,141,447 addresses (14.48%)
      technique: OriginMail normalized emails extracted from npm and GitHub public data. | metric: share of collected addresses identified as aliases
      quote [results]: "Among the 2,141,447 collected email addresses, we identified 310,136 aliases."
  * alias multiplicity abuse — one base address had 139 alias accounts and published 3,904 packages
      technique: Group alias addresses by extracted base addresses across accounts. | metric: maximum accounts per base address
      quote [results]: "The largest campaign was associated with the base email umekiyanai@gmail.com, which had 139 alias accounts."
  * alias-recognition errors — valid responses achieved 40.07% accuracy
      technique: Participants classified 15 simulated sender addresses against six known contacts. | metric: classification accuracy
      quote [results]: "The accuracy among valid responses was 40.07%, indicating a generally low ability to correctly identify alias emails."
  * phishing susceptibility — 31.65% among participants reporting alias awareness, versus 12.63% without awareness
      technique: Defined susceptibility as misidentifying at least one non-alias as a valid alias. | metric: susceptibility rate
      quote [results]: "the overall phishing susceptibility rate rising from 12.63% to 31.65%."
 
---------- [POSTLOGIN] ----------
 
2015 USENIX — Cookies Lack Integrity: Real-World Implications
  population[]: 961857 domains (Alexa top one million websites); 100000 domains (Alexa top 100,000 domains); 28 domains (custom seed list); 13 domains (custom seed list)
  * HTTPS and full HSTS deployment — 152,679 (15.87%) had valid HTTPS; 1,252 (0.13%) enabled full HSTS
      technique: Scanned Alexa base domains and checked HTTPS certificates and HSTS policies | metric: share of scanned domains
      quote [results]: "While we observed 152,679 (15.87%) domains have deployed HTTPS with valid certificates, we only found 1,252 (0.13%) domains have enabled full HSTS."
  * Shared-domain cookie injection — 12 of 13 tested shared domains; 72KB cookies successfully triggered DoS
      technique: Collected CDN shared domains, signed up, and injected cookies across test URLs | metric: domains vulnerable to injected-cookie DoS
      quote [results]: "For each of the other 12 domains, we successfully launched DoS attack on one test URL by injecting 72KB cookies from another test URL."
  * Secure cookies over HTTP — 152 of 48,039 responding domains (0.32%)
      technique: Crawled Alexa domains over HTTP and HTTPS and inspected returned cookies | metric: domains returning secure cookies over HTTP
      quote [results]: "152 (0.32%) domains returned secure cookies over HTTP; 570 (1.19%) domains responded with cookies that have same name yet different domains and/or paths."
  * Duplicate-name cookies — 570 of 48,039 responding domains (1.19%)
      technique: Inspected cookies returned during Alexa crawl for same names and differing scopes | metric: domains with same-name cookies
      quote [results]: "152 (0.32%) domains returned secure cookies over HTTP; 570 (1.19%) domains responded with cookies that have same name yet different domains and/or paths."
  * Browser cookie implementation flaws — All major browsers exhibited at least some documented inconsistencies or vulnerabilities
      technique: Tested cookie ordering, storage, headers, names, paths, proxies, and HSTS behavior | metric: browser behaviors and vulnerabilities
      quote [methodology]: "Our study pinpointed a number of inconsistent and/or non-conforming behaviors in major browsers, as summarized in Table 4."
  * Real-world cookie injection attacks — Included Google, Amazon, eBay, Apple, Bank of America, BitBucket, and open-source applications
      technique: Black-box penetration tests with test accounts and injected cookies | metric: websites and applications successfully exploited
      quote [results]: "We found cookie injection attacks are possible with very large websites and popular open source applications including Google, Amazon, eBay, Apple, Bank of America, BitBucket, China Construction Bank, China Union-Pay, JD.com, phpMyAdmin, and MediaWiki, among others."
  * Secure-cookie extension compatibility — One broken case among Alexa top 40 websites
      technique: Manually tested Alexa sites with the authors' Chrome extension | metric: domains manually examined
      quote [results]: "We found one broken case: the signing out operation on http://www.bing.com/ results in a request-reply with http://login.live.com/logout.srf which expires several secure session cookies."
 
2022 IEEE-SP — The State of the SameSite: Studying the Usage, Effectiveness, and Adequacy of SameSite Cookies.
  population[]: 500000 websites (Alexa top 500K); 500 websites (Alexa top 500); 1000 websites (Alexa top 1K); 10000 websites (Alexa top 10K); 14 other (MDN); 25 other (GitHub 2020 Octoverse report)
  * SameSite cookie adoption — 18.94% of sites adopted one of the three valid policies by March 2021
      technique: Extracted and counted unique cookie attributes from archived response headers. | metric: share of sites using each policy
      quote [results]: "As of March 2021, 80.7% of the sites rely on the default cookie policy ... whereas 18.94% of them adopted one of the three valid policy."
  * Cross-site functionality breakage — 19% of affected cross-site requests were broken; 77.5% involved advertising networks
      technique: Removed cookies before and after Lax rollout and manually checked functionality. | metric: share of sampled requests broken
      quote [results]: "we observe that the functionalities implemented by 19% of the affected requests are broken. Out of these, 77.5% of the requests are directed to advertisement networks"
  * State-changing GET CSRF — 7 of 264 GET requests were forgeable, affecting four websites
      technique: Detected token-bearing forms, sampled GET requests, and replayed them. | metric: vulnerable sampled requests
      quote [results]: "we discovered that seven out of the 264 GET requests (i.e., 2.6%) are forgeable due to faulty CSRF token verification, affecting four websites"
  * Window-properties and postMessage XS-Leaks — 1,302 vulnerable URLs across 40 distinct websites
      technique: Compared browser observations across logged-in and alternate user states. | metric: vulnerable URLs and websites
      quote [results]: "In total, we discovered 1,302 vulnerable URLs, belonging to a total of 40 distinct websites."
  * SameSite bypass via POST-to-GET — 9 of 602 requests were forgeable, affecting six websites
      technique: Replayed sampled POST requests after changing methods and encoding bodies as query parameters. | metric: vulnerable sampled POST requests
      quote [results]: "In total, we discovered that nine out of the 602 requests (i.e., 1.5%) are forgeable, affecting six popular websites"
  * SSO redirect bypass — Six IdPs enabled bypass across 4,935 sites, over 49% of Alexa top 10K
      technique: Tested 13 IdPs for unauthenticated cross-origin GET re-login and crawled Alexa sites. | metric: affected websites
      quote [results]: "These IdPs are integrated in 4,935 websites, accounting for more than 49% of the top 10K Alexa sites."
  * User-agent SameSite inconsistency — 9,951 websites allowed a policy downgrade in April 2021
      technique: Compared cookie policies across Chrome Desktop and iOS Safari crawls. | metric: vulnerable websites
      quote [results]: "In total, we identified 5,719, 9,215, and 9,951 vulnerable websites that allow a policy downgrade in the three web crawls, respectively."
  * Browser and framework divergence — Seven browser behaviors; 24% of frameworks set None by default
      technique: Ran controlled same-site/cross-site cookie tests and default framework applications. | metric: distinct browser behaviors and framework share
      quote [results]: "none of the 14 tested browsers are fully compliant with the new RFC 6265bis specification"
 
2023 USENIX — Cookie Crumbles: Breaking and Fixing Web Session Integrity
  population[]: 100000 websites (HTTP Archive dataset); 13 other (GitHub metrics)
  * cookie-prefix and nameless-cookie adoption — More than 70% of top-1K origins used Secure cookies; 133 origins used __Host- in 2022 versus 77 in 2021.
      technique: Queries over HTTP Archive/Web Almanac data, excluding third-party cookies. | metric: share of origins
      quote [results]: "Overall, 77 origins used the __Host- prefix in 2021, in contrast to the 133 origins that used it in 2022, which corresponds to a 72% increase in one year."
  * web-framework session-integrity vulnerabilities — 9 of 13 frameworks exposed session-integrity vulnerabilities.
      technique: Toy applications, official libraries, and automated CORF attack routines. | metric: number of frameworks affected
      quote [introduction]: "We performed a systematic security analysis of the top 13 Web frameworks, exposing session integrity vulnerabilities in 9 of them."
  * formal mitigation correctness — The unmitigated property failed on all four models; fixed models were proved valid.
      technique: ProVerif correspondence proofs over four framework models. | metric: property proved or disproved
      quote [results]: "ProVerif confirms that the property does not hold on any of the four models, producing counterexamples that closely resemble the token fixation attack of Fig. 5."
 
2024 IEEE-SP — To Auth or Not To Auth? A Comparative Analysis of the Pre- and Post-Login Security Landscape.
  population[]: 445 websites (Tranco); 5000 websites (CrUX); 4485 websites (Tranco and CrUX); 200 websites (Tranco and CrUX)
  * client-side XSS — 7 unique vulnerable sites; 6 persistent and 1 reflected
      technique: Foxhound taint tracking, exploit generation, and crawl-time verification | metric: vulnerable sites and verified exploits
      quote [results]: "In total we discovered seven unique vulnerable sites. Six are vulnerable in Sauth, and four in Snoauth."
  * security-header deployment — X-Frame-Options appeared on average in 56% of responses
      technique: Playwright response capture and semantic security-header analysis | metric: site-level secure, insecure, or missing headers
      quote [results]: "It is also the most frequently used header, appearing on average in 56% of responses."
  * security-header inconsistency — over 99% of URLs had consistent headers
      technique: Five repeated URL visits compared by semantic equivalence | metric: share of URLs with consistent headers
      quote [results]: "our findings suggest that over 99% of URLs had consistent headers."
  * JavaScript inclusions — 42,437,161 scripts parsed
      technique: Injected API hooks plus CDP Debugger.scriptParsed events | metric: parsed scripts and unique scripts
      quote [results]: "In total, our crawlers parsed 42,437,161 scripts."
  * vulnerable JavaScript libraries — 143 authenticated and 145 unauthenticated sites
      technique: Retire.js identification of libraries and known vulnerabilities | metric: sites containing vulnerable libraries
      quote [results]: "The number of websites that include at least one vulnerable library on at least one crawled URL is similar (143 Sauth, 145 Snoauth)."
  * third-party scripts and tracking — 15.47% more unique tracking entities in Sauth
      technique: Source-URL comparison and Disconnect entity matching | metric: unique third-party scripts and trackers
      quote [results]: "our findings imply ... tracking research ... may suffer from similar limitations as we discovered 15.47% more unique tracking entities in Sauth."
  * postMessage handlers — 899 authenticated versus 493 unauthenticated AST-unique handlers
      technique: PMForce force execution, taint tracking, and exploit verification | metric: AST-unique handlers
      quote [results]: "Considering these AST-unique handlers, the difference is even larger with 493 to 899 handlers, respectively."
  * postMessage vulnerabilities — 2 exploits affecting one authenticated-state site
      technique: Generated exploit candidates verified during crawling | metric: verified exploitable handlers
      quote [results]: "In the end, only two exploits worked, both of which affected a single site in the authenticated state."
 
---------- [OPERATOR] ----------
 
2015 WWW — Secrets, Lies, and Account Recovery: Lessons from the Use of Personal Knowledge Questions at Google.
  population[]: 11000000 other (Google account recovery claims); 1000 human-participants (CrowdFlower); 1000 human-participants (Google Consumer Surveys); 1500 human-participants (Google Consumer Surveys); 32000000 other (RockYou)
  * Secret-answer guessing vulnerability — A single guess yielded 0.8%–19.7% success across questions.
      technique: Computed statistical guessing metrics from answer-frequency distributions. | metric: success rate for β guesses; guessing work for α users
      quote [results]: "Even a single guess can yield between 0.8% to 19.7% success rate."
  * Secret-answer memorability — 40% of US English-speaking users were unable to recall answers when needed.
      technique: Measured successful recovery claims by question, elapsed time, language, and answer length. | metric: account-recovery answer success rate
      quote [abstract]: "40% of our English-speaking US users were unable to recall their answers when needed."
  * Untruthful secret answers — 37% of respondents reported fabricating answers to make them harder to guess.
      technique: Surveyed respondents about whether and why they supplied fake answers. | metric: fraction of respondents
      quote [introduction]: "37% of the 1500 respondents"
  * Recovery-method reliability — SMS 81%, email 75%, and secret questions 61% for US English down to 44% for France French.
      technique: Compared successful account-recovery claims across secret questions, SMS, and email. | metric: recovery success rate
      quote [introduction]: "SMS and email-based account recovery have a significantly higher chance of success: 81% for SMS vs 75% for Email vs 61% (US/English) down to 44% (France/French) for secret questions."
  * Crowdsourced distribution approximation — Crowdsourced distributions achieved at least 75%–80% of ideal efficiency for up to 100 guesses.
      technique: Compared CrowdFlower-derived answer distributions with ideal attacker distributions. | metric: crowdsourced attacker efficiency
      quote [results]: "with up to 100 guesses efficiency is at least 75% as high for the father's middle name distribution and at least 80% as high for the favorite food distribution."
 
2019 WWW — Evaluating Login Challenges as aDefense Against Account Takeover.
  population[]: 400000 other (three existing threat intelligence feeds); 300000 other (Google login traces); 50867 other (Google login traces); 214 other (Google accounts previously identified as victims of targeted attacks); 300000 other (Google sign-in flow); 300000 other (Google login traces)
  * Login challenge prevention of hijacking — Device-based challenges blocked over 94% of phishing-rooted hijacking attempts and 100% of automated attempts.
      technique: Compared challenge outcomes across bot, phishing, and targeted attack traces. | metric: prevention rate
      quote [abstract]: "Device-based challenges provide the best protection, blocking over 94% of hijacking attempts rooted in phishing and 100% of automated hijacking attempts."
  * Overall risk-aware authentication protection — Over 99.99% of automated hijacking attempts and 92% of phishing-rooted attacks were blocked.
      technique: Measured users with any successful hijacker sign-in over repeated attempts. | metric: fraction of users with any successful hijacker sign-in
      quote [results]: "Google's risk analysis engine blocked over 99.99% of automated hijacking attempts by bots and 92% of attacks rooted in phishing."
  * Legitimate-user challenge friction — 97.3% of users who failed login challenges eventually accessed their accounts within one week.
      technique: Analyzed pass, skip, abandonment, and later account-access outcomes. | metric: eventual account-access rate within one week
      quote [results]: "However, over the course of a week, users have an opportunity to regain access to a familiar device or network and thus eventually access their account at rates similar to password-only authentication."
 
2020 USENIX — Empirical Measurement of Systemic 2FA Usability
  population[]: 32366721 other (UCB anonymized 2FA log events); 6467262 other (UIUC anonymized 2FA log events); 17085 documents (UIUC 2FA-related support tickets); 6721 documents (UIUC support tickets analyzed after automated-ticket removal); 38536 other (UIUC student/employee status data)
  * 2FA ceremony errors and abandonment — more than one in twenty 2FA ceremonies
      technique: Aggregated unsuccessful login attempts by failure reason and second-factor class. | metric: share of 2FA ceremonies ending unsuccessfully
      quote [results]: "We observed that more than one in twenty 2FA ceremonies did not end successfully."
  * Device remembrance — 70% (21.1M of 30.0M) of UCB logins were remembered
      technique: Compared remembered-login rates and simulated remembrance windows using six months of UCB login data. | metric: fraction of logins remembered
      quote [results]: "Because 70% (21.1M of 30.0M) of logins at UCB were remembered, tens of thousands of hours of users' time was saved."
  * 2FA error recovery time — average recovery times at both organizations were 10–100 seconds; hours passed for 40% of users
      technique: Measured time from each failed login to the next successful login, counting repeated failures once. | metric: time between failed and subsequent successful login
      quote [results]: "Average recovery times at both organizations were 10-100 seconds. ... Hours pass before 40% of users next successfully log in"
  * Support-ticket issue categories — enrollment and setup issues: 34.40%±5.48% of tickets
      technique: Applied a 13-code manually developed codebook to 500 randomly selected tickets. | metric: estimated category prevalence
      quote [results]: "The highest proportion of all support tickets are related to 2FA enrollment and setup issues (34.40%±5.48%)."
  * Account-recovery bypass use — about 5% of users used a bypass; about 2% used one twice or more
      technique: Counted bypass tokens per unique user ID at each university. | metric: share of users resorting to bypass
      quote [results]: "Only about 5% of users resorted to this bypass, with only about 2% using one twice or more."
  * 2FA learning curve — UCB errors normalized after about a month; UIUC abandonment gradually fell during the first month
      technique: Computed daily error rates for users with recorded enrollment during their first 90 days. | metric: daily error rate since enrollment
      quote [results]: "Figure 7 shows the error rate of users for whom we had 2FA registration information on for each of their first 90 days using the system."
 
2022 USENIX — Gossamer: Securely Measuring Password-based Logins
  population[]: 10000000 network-flows (custom university login systems (U1)); 24000000 network-flows (custom university login systems (U2)); 1300000000 other (breach data used in prior work); 10000 other (remaining 20% of breach dataset)
  * Login requests and user behavior — 34 million login requests from approximately 500 K users
      technique: Instrumented university login servers and recorded sanitized request statistics. | metric: number of login requests
      quote [introduction]: "We observed 34 million login requests (combined) for approximately 500 K users"
  * Breached credential use — 23 users at U1 and 254 at U2 were still using a breached password
      technique: Matched usernames, passwords, and pairs against breach datasets. | metric: share of valid users
      quote [results]: "we find that 23 users (0.01% of valid users) at U1 and 254 users at U2 (0.15% of valid users) were still using a breached password as their actual password."
  * Password tweaking — 0.92% at U1 and 0.34% at U2 were tweaked
      technique: Compared submissions with breached passwords using edit distance, PPSM, and pass2path. | metric: share of submitted passwords
      quote [results]: "We found that at U1, 0.92% of all passwords submitted were tweaked, and 2,164 users (1.22% of valid users) were using a tweaked password. At U2, 0.34%"
  * Password typos — 62% of measured failed U1 requests contained typos
      technique: Tested whether failed submissions were within edit distance two of the actual password. | metric: share of failed requests
      quote [results]: "at U1, 62% of failed requests where we have this measurement contained typos of edit distance two or less"
  * High-volume attacks — Three high-volume attacks were observed
      technique: Inspected request volume, IPs, user agents, breach matches, and outcomes. | metric: number of attack campaigns
      quote [results]: "We observed three high volume attacks during our instrumentation."
  * Login sessions and retries — 51% at U1 and 38% at U2 required more than one attempt
      technique: Grouped attempts by username and IP/user-agent device with a 360-second inactivity threshold. | metric: share of sessions with multiple attempts
      quote [results]: "With this definition, we find that 51% of sessions at U1 required more than one attempt ... For U2, 38% of sessions required more than one attempt"
  * Duo two-factor authentication outcomes — 96.7% successful, 3.2% denied, and fewer than 0.01% fraudulent
      technique: Matched successful logins to Duo pushes within two minutes by user. | metric: share of matched pushes
      quote [results]: "Among the Duo pushes we could successfully match with a login attempt, we found that 96.7% were successful, 3.2% were denied, and only 46 (< 0.01%) were marked as fraud"
  * Password-manager adoption — 25% at U1 and 27% at U2 had at least ten logins without a failure
      technique: Identified users with many successful logins and no failed attempts as a proxy. | metric: share of valid users
      quote [results]: "we found 25% of valid users at U1 and 27% at U2 have at least ten logins and never had a failed login"
 
===== 3. Instruments, folded, with the unmapped residue printed =====
folded names, counted by paper, of 45 population papers:
  Chrome/Chromium                        19  42.2%
  Firefox                                 7  15.6%
  Selenium                                6  13.3%
  participant panel                       6  13.3%
  Puppeteer                               5  11.1%
  CDP (direct)                            4  8.9%
  synthetic-identity generator            4  8.9%
  Playwright                              4  8.9%
  Safari                                  4  8.9%
  mitmproxy                               3  6.7%
  Edge                                    3  6.7%
  registration plumbing (SMS/mail/CAPTCHA)  2  4.4%
  Brave                                   2  4.4%
  Consent-O-Matic                         1  2.2%
  2fa.directory                           1  2.2%
  Tracker Radar Collector                 1  2.2%
 
RESIDUE — 203 distinct tool strings the fold does not map (218 mentions):
Google Search (3); zxcvbn (3); googletrans (2); Chrome extension (2); Python (2); regular expressions (2); NordVPN (2); Opera (2); XDriver (2); scikit-learn (2); XGBoost (2); ScraperAPI (2); AZcaptcha (2); browser add-on we designed (1); semi-automatic vulnerability assessment tools (1); Greasemonkey (1); impersonator tool (1); access token network sniffer (1); attacker.com (1); SSOScan (1); Facebook Single Sign-On APIs (1); browser extension (custom) (1); WebConnect (1); NodeJS (1); Passport (1); automated analysis tool (1); DuckDuckGo (1); network tap logging module (1); OpenID Connect module for Drupal (1); OpenIAM (1); Keycloak (1); Gluu (1); Soffid (1); feKara (1); Distinct (1); Live-Monitor (1); Communication-Inspector (1); Docker (1); NoVNC (1); JavaScript Proxy (1); custom OAuth crawler (1); McAfee's domain categorization API (1); EasyPrivacy (1); The ProgrammableWeb (1); SAAT (1); Chromium Accessibility API (1); GNU Parallel (1); OpenCV (1); Simplabel (1); BigQuery (1); IDB-DETECTOR (1); Whois Lookup (1); GitHub Code Search (1); Tracker Radar Entity List (1); COVScan (1); selenium-wire (1); undetected-chromedriver (1); Chrome WebDriver (1); TDLib (1); KiwiTalk (1); Android Auto Clicker (1); Google Search APIs (1); RetinaFace (1); FaceNet512 (1); Inception-ResNet-v1 (1); MobileNetV3 (1); multi-layer perceptron (MLP) (1); NVivo (1); PHP (1); Google Authenticator (1); k-modes (1); Screencasts (1); HOSIT (1); McAfee's URL Ticketing System (1); Disconnect.me (1); FP-Extractor (1); FP-Spoofer (1); VisibleV8 (1); Emkei's Fake Mailer (1); NRC EmoLex (1); Zoom (1); Chrome's built-in JS debugger (1); Chrome's built-in virtual authenticator (1); FIDO Alliance Metadata Service APIv3 (1); Symantec Sitereview (1); Proof-of-concept Chrome extension (1); PASSKEYS-RADAR (1); PASSKEYS-ATTACKER (1); Browser Use (1); Tracker Radar Entity Map (1); Google BigQuery (1); Google DNS API (1); Namecheap API (1); Chrome built-in translation (1); Google Scholar (1); Touch ID (1); AirDrop (1); iCloud Keychain (1); Google Password Manager (1); Yubico YubiKey (Security Key C NFC) (1); Yubico FIDO2 library (1); Wireshark (1); Node.js (1); Amazon AWS (1); threshold-based classifier (custom) (1); MediaStream API (1); Sitereview (1); custom crawler (1); ChromeDriver (1); Geckodriver (1); Google Translate (1); McAfee URL Ticketing System (1); EmailHarvester (1); modified proxy (1); OneLogin (1); Google (1); Facebook (1); Apple (1); SVM (1); langdetect (1); Translate (1); all-DistilRoBERTa (1); TF-IDF (1); SimilarWeb (1); binary SVM (custom) (1); Google search engine (1); TensorFlow (1); Fathom (1); Priv-Accept (1); uBlock Origin Core (1); JShelter (1); Zed Attack Proxy (ZAP) (1); FindIP API (1); HSQL Database Engine (1); SQLite (1); Python-native DNS resolver (1); QRLChecker (1); custom semi-automated detection pipeline (1); Wenjuanxing (1); Web3AuthChecker (1); FlexRequest (1); curl_cffi (1); curl-impersonate (1); Web3AuthGuard (1); MetaMask (1); Postman (1); Requests (1); GitHub Codespaces (1); ProtonVPN (1); Socket Secure (SOCKS) proxy (1); Google Chrome Extension (1); Account Framework (1); Foxhound (1); Exploit generator by Steffens et al. (1); Retire.js (1); Disconnect Tracker Protection List (1); PMForce (1); esprima (1); Xvfb (1); VNC (1); Bitwarden (1); BrowserStack (1); browser test suite (1); custom Cookie-header fuzzer (1); ProVerif (1); WebSpi (1); Web Platform Tests (WPT) (1); Google Consumer Surveys (1); CrowdFlower (1); Google passive reCAPTCHA (1); Google risk analysis engine (1); Cisco's Duo (1); pattern matching and name lists (1); Gossamer (1); Python Flask (1); Apache (1); MySQL (1); Python Fernet (1); Python Miscreant (1); Hashcat (1); PPSM (1); Pass2Path (1); MaxMind GeoIP2 (1); Blackbox API (1); Qualtrics (1); Samsung Browser (1); OriginMail (1); DrissionPage (1); IPQualityScore (1); Mailmeteor (1); custom SMTP server (1); WebShrinker API (1); EasyList (1); Host BlackList (1); Host BlockList (1); JAW (1); iOS Safari (1); random selection (1); Google search (1); Internet Archive (1); Bro (1); EditThisCookie (1); rst (1)
 
===== 4. Where the population drew its sites from — population[].sourceList, folded =====
  custom / not stated      17 papers  37.8%
  Tranco                   16 papers  35.6%
  Alexa                    11 papers  24.4%
  CrUX                      7 papers  15.6%
  Fortune 1000              2 papers  4.4%
  2fa.directory             2 papers  4.4%
  participant panel         2 papers  4.4%
  Quantcast                 1 papers  2.2%
  Majestic                  1 papers  2.2%
  Similarweb                1 papers  2.2%
  Cisco Umbrella            1 papers  2.2%
  HTTP Archive              1 papers  2.2%
 
RESIDUE — 47 distinct source-list strings unmapped:
Google login traces (3); public dataset from prior work [34] (2); partner RP authentication server logs (2); Google Consumer Surveys (2); Google's Top 1,000 Most-Visited Websites (1); Gmail, Hotmail, Yahoo!, and QQ mail (1); OpenIAM, Keycloak, Gluu, Soffid, and feKara (1); published employee payroll record (1); U.S. universities (1); all reachable websites where the algorithm did not find any OAuth implementation (1); websites requesting non-minimal scopes for at least one IdP (1); GitHub (1); Innocenti et al. dataset (1); Phish-A (1); Phish-B (1); APWG (1); FIDO Alliance's Metadata Service (MDS) (1); community directories (1); PASSKEYS-RADAR merged sources (1); confirmed independent passkey implementations (1); websites selected for full security evaluation (1); relevant academic venues and citation searches (1); FIDO Alliance certified devices (1); FIDO Alliance certified Level 1 hardware authenticators (1); Sitereview (1); Wenjuanxing (1); DappRadar's Top Decentralized Marketplaces list (1); Google searches (1); GitHub metrics (1); Google deployment (1); Google account recovery claims (1); CrowdFlower (1); RockYou (1); three existing threat intelligence feeds (1); Google accounts previously identified as victims of targeted attacks (1); Google sign-in flow (1); UCB anonymized 2FA log events (1); UIUC anonymized 2FA log events (1); UIUC 2FA-related support tickets (1); UIUC support tickets analyzed after automated-ticket removal (1); UIUC student/employee status data (1); breach data used in prior work (1); remaining 20% of breach dataset (1); npm API (1); GitHub repository and query APIs (1); MDN (1); GitHub 2020 Octoverse report (1)
 
ranking list by era (papers naming each, first/last year in this population):
  Alexa            11 papers  2015-2025
  Tranco           16 papers  2022-2026
  CrUX              7 papers  2023-2026
  Majestic          1 papers  2022-2022
  Quantcast         1 papers  2014-2014
  Cisco Umbrella    1 papers  2022-2022
 
===== 5. How big were the site populations — population[].n for website/domain units =====
85 site-unit population entries across 40 papers
largest ten:
   18000000  2026  the-state-of-passkeys-studying-the-adoption-and-security-of-
    1585964  2020  the-cookie-hunter-automated-black-box-auditing-for-web-authe
    1000000  2018  o-single-sign-off-where-art-thou-an-empirical-analysis-of-si
    1000000  2025  only-as-strong-as-the-weakest-link-on-the-security-of-broker
    1000000  2026  the-state-of-passkeys-studying-the-adoption-and-security-of-
    1000000  2022  how-not-to-handle-keys-timing-attacks-on-fido-authenticator-
    1000000  2017  security-implications-of-redirection-trail-in-popular-websit
    1000000  2023  a-large-scale-measurement-of-website-login-policies
    1000000  2023  measuring-website-password-creation-policies-at-scale
     961857  2015  cookies-lack-integrity-real-world-implications
median site-unit n: 872
entries under 500 sites: 39 of 85
 
===== 6. Where this population goes quiet — sentinels, each with its own denominator =====
papers with a crawlConfig object: 23 of 45
 
crawlConfig.authentication  (population 23; stated 19 = 82.6%)
    none                        9
    account-registration        7
    not-stated                  4
    manual-login                3
 
crawlConfig.statefulness  (population 23; stated 7 = 30.4%)
    not-stated                 16
    stateful                    4
    stateless                   2
    both                        1
 
crawlConfig.consentAction  (population 23; stated 8 = 34.8%)
    not-stated                 14
    no-interaction              6
    accept-all                  2
    not-applicable              1
 
crawlConfig.interactionDepth  (population 23; stated 21 = 91.3%)
    landing-plus-subpages      11
    single-target-page          7
    deep-crawl                  2
    not-stated                  2
    landing-page-only           1
 
ethics.reviewOutcome  (population 44; stated 20 = 45.5%)
    none-mentioned             24
    approved                   10
    not-required                4
    sought-outcome-unstated     3
    explicitly-discussed-no-review  2
    exempt                      1
 
ethics.notifiedAffectedParties  (population 44; stated 30 = 68.2%)
    yes                        22
    not-stated                  8
    partial                     6
    not-applicable              6
    no                          2
 
artifacts.availability  (population 41; stated 28 = 68.3%)
    public                     20
    none-mentioned             13
    on-request                  3
    promised-not-yet-available  3
    restricted                  1
    explicitly-withheld         1
 
base rates for the same fields, so a share can be read against something:
  crawlConfig.authentication         population 19/23 = 82.6%          web papers 634/838 = 75.7%          corpus 779/1080 = 72.1%
  crawlConfig.statefulness           population 7/23 = 30.4%           web papers 203/838 = 24.2%          corpus 219/1080 = 20.3%
  ethics.reviewOutcome               population 20/44 = 45.5%          web papers 522/1435 = 36.4%         corpus 1777/4965 = 35.8%
  ethics.notifiedAffectedParties     population 30/44 = 68.2%          web papers 747/1435 = 52.1%         corpus 2552/4965 = 51.4%
  artifacts.availability             population 28/41 = 68.3%          web papers 974/1568 = 62.1%         corpus 3356/5539 = 60.6%
 
===== 6a. Absence claims, printed rather than asserted =====
  OpenWPM: tools[] 0 papers; otherToolsMentioned[] 0 papers
  any off-the-shelf framework (OpenWPM, Tracker Radar Collector, webXray, crawl4ai): tools[] 1 papers (the-double-edged-sword-identif); otherToolsMentioned[] 0 papers
 
===== 7. Hand coding and validation inside this population =====
papers with a humanAnnotation tuple: 38 of 45 (84.4%)
  base rate: 1126 of 1622 web papers = 69.4%
  state an annotator count: 13 of 38 = 34.2%
  state an agreement metric: 7 of 38 = 18.4%
papers with a classification tuple: 42 of 45
    classification.validation manual-validation      28
    classification.validation none-reported          22
    classification.validation not-applicable         12
    classification.validation held-out-test-set      3
    classification.validation comparison-to-other-method 3
    classification.validation cross-validation       2
    classification.method     heuristic-rules        23
    classification.method     manual-labelling       20
    classification.method     curated-database       11
    classification.method     third-party-service    10
    classification.method     dynamic-analysis       5
    classification.method     regex-or-signature     5
    classification.method     blocklist              4
    classification.method     supervised-ml          4
    classification.method     other                  1
    classification.method     unsupervised-ml        1
 
===== 8. Is anyone here using an LLM? (currency check) =====
classification.method == llm: 0 of the 45 population papers; 177 corpus-wide
corpus-wide llm classification by year: 2023:2 2024:27 2025:77 2026:71
 
===== 9. Artifact links released by this population =====
papers stating an availability value: 28 of 45
  2012 CCS      none-mentioned             dataset:http://www.google.com/adplanner/static/top1000/
  2014 USENIX   public                     dataset:quantcast.com
  2017 PETS     public                     source-code:https://github.com/Sparika/WebConnect other:http://www.alexa.com/topsites
  2018 USENIX   public                     dataset:https://www.cs.uic.edu/~sso-study/
  2021 WWW      none-mentioned             dataset:https://data.ny.gov/Transparency/Salary-Information-for-State-Authorities/unag-2p27 dataset:https://booleanstrings.com/wp-content/uploads/2014/01/fortune1000-2012.xls/
  2022 CCS      public                     dataset:https://tranco-list.eu/list/ZGXG
  2023 PETS     public                     source-code:https://anonymous.4open.science/r/oauth_project_code-2003 other:https://github.com/ssut/py-googletrans
  2022 IEEE-SP  on-request                 dataset:https://majestic.com/reports/majestic-million
  2023 IMC      public                     dataset:https://github.com/zakird/cruxtop-lists
  2025 IEEE-SP  public                     dataset:https://tranco-list.eu/list/6Z2X
  2025 USENIX   public                     source-code:https://doi.org/10.5281/zenodo.14677002 project-page:https://mobitec.ie.cuhk.edu.hk/cross-app-oauth-security
  2026 NDSS     none-mentioned             other:https://github.com/tdlib/td other:https://github.com/KiwiTalk/KiwiTalk
  2021 USENIX   none-mentioned             project-page:https://www.usenix.org/conference/usenixsecurity21/presentation/ulqinaku web-demo-or-service:https://login.two-step.online/google.com/index.php?acc=8[..]b
  2023 NDSS     none-mentioned             dataset:https://2fa.directory/ dataset:https://github.com/2factorauth/twofactorauth
  2023 CCS      public                     dataset:https://2fa.directory/int/
  2023 USENIX   none-mentioned             other:https://tranco-list.eu/list/42XX other:https://2fa.directory/
  2022 USENIX   promised-not-yet-available dataset:https://apwg.org/ecx/
  2025 NDSS     none-mentioned             web-demo-or-service:https://emkei.cz/ web-demo-or-service:https://www.prolific.com/
  2023 CCS      none-mentioned             other:https://developer.chrome.com/docs/devtools/webauthn other:https://developer.chrome.com/docs/devtools/javascript
  2026 USENIX   public                     project-page:https://passkeys.tools code-and-data:https://github.com/RUB-NDS/state-of-passkeys-artifacts
  2025 PETS     none-mentioned             dataset:https://www.kaggle.com/datasets/cheedcheed/top1m
  2025 USENIX   public                     code-and-data:https://doi.org/10.5281/zenodo.14745290 other:https://passkeys.directory/
  2022 PETS     public                     code-and-data:https://osf.io/t7dpa/?view_only=c8595da6c6d34fadb87f2f6db7e5d626 other:https://chromium.googlesource.com/chromium/src/+/refs/heads/main/device/fido/get_assertion_task.cc
  2026 NDSS     public                     dataset:https://github.com/XDAuth-security/XDAuth
  2023 USENIX   on-request                 dataset:https://developer.chrome.com/docs/crux/ dataset:https://plaintextoffenders.com/
  2023 CCS      on-request                 dataset:https://github.com/danielmiessler/SecLists/tree/master/Passwords/Common-Credentials dataset:https://xato.net/today-i-am-releasing-ten-million-passwords-b6278bbe7495
  2024 WWW      public                     dataset:https://github.com/asumansenol/double_edged_sword_data dataset:https://developers.google.com/web/tools/chrome-user-experience-report
  2024 CCS      none-mentioned             web-demo-or-service:https://findip.net/ web-demo-or-service:https://www.zaproxy.org/
  2025 USENIX   restricted                 code-and-data:https://doi.org/10.5281/zenodo.14676762 source-code:https://doi.org/10.5281/zenodo.14676842
  2024 CCS      public                     source-code:https://github.com/d0scoo1/Web3AuthChecker source-code:https://github.com/d0scoo1/Web3AuthGuard
  2026 USENIX   public                     dataset:https://tranco-list.eu/list/7XN5X
  2024 IEEE-SP  public                     code-and-data:https://github.com/cispa/login-security-landscape other:https://github.com/SAP/project-foxhound
  2023 USENIX   public                     dataset:https://httparchive.org/ dataset:https://almanac.httparchive.org/
  2019 WWW      none-mentioned             other:https://developers.google.com/recaptcha/docs/v3
  2020 USENIX   explicitly-withheld        project-page:https://www.usenix.org/conference/usenixsecurity20/presentation/reynolds
  2022 USENIX   promised-not-yet-available web-demo-or-service:https://blackbox.ipinfo.app/ other:https://cryptography.io/en/latest/fernet.html
  2024 CCS      none-mentioned             dataset:https://github.com/danielmiessler/SecLists/tree/master/Passwords/Common-Credentials
  2026 NDSS     public                     dataset:https://github.com/Marphownio/RepSEO Classifier/tree/main/RepSEO-package-list/npm
  2022 IEEE-SP  none-mentioned             dataset:https://github.com/alviser/mitch/tree/master/dataset
  2015 USENIX   public                     source-code:https://github.com/seccookie/ExtSecureCookie browser-extension:http://www.editthiscookie.com/
 
===== --wikitable =====
^ Year ^ Venue ^ Paper ^ Measures ^ Largest n in ''population[]'' ^
| 2012 | CCS | //The devil is in the (implementation) details: an empirical analysis of OAuth SSO systems// {[sun2012_devil]} | SSO | 96 websites (Google's Top 1,000 Most-Visited Websites) |
| 2014 | USENIX Sec | //SSOScan: Automated Testing of Web Applications for Single Sign-On Vulnerabilities// {[zhou2014_ssoscan]} | SSO | 20,000 websites (Quantcast) |
| 2015 | USENIX Sec | //Cookies Lack Integrity: Real-World Implications// {[zheng2015_cookies]} | post-login | 961,857 domains (Alexa top one million websites) |
| 2015 | TheWebConf | //Secrets, Lies, and Account Recovery: Lessons from the Use of Personal Knowledge Questions at Google// {[bonneau2015_secrets]} | operator | 32,000,000 other (RockYou) |
| 2017 | PoPETs | //Why can’t users choose their identity providers on the web?// {[corre2017_users]} | SSO | 500 websites (Alexa ranking) |
| 2017 | TheWebConf | //Security Implications of Redirection Trail in Popular Websites Worldwide// {[chang2017_security]} | login surface | 1,000,000 websites (Alexa top 1M list) |
| 2018 | USENIX Sec | //O Single Sign-Off, Where Art Thou? An Empirical Analysis of Single Sign-On Account Hijacking and Session Management on the Web// {[ghasemisharif2018_sso]} | SSO | 1,000,000 websites (Alexa) |
| 2019 | TheWebConf | //Evaluating Login Challenges as aDefense Against Account Takeover// {[doerfler2019_evaluating]} | operator | 400,000 other (three existing threat intelligence feeds) |
| 2020 | CCS | //The Cookie Hunter: Automated Black-box Auditing for Web Authentication and Authorization Flaws// {[drakonakis2020_cookie]} | login surface | 1,585,964 domains (Alexa Top 1 million) |
| 2020 | USENIX Sec | //Empirical Measurement of Systemic 2FA Usability// {[reynolds2020_systemic]} | operator | 32,366,721 other (UCB anonymized 2FA log events) |
| 2021 | USENIX Sec | //Is Real-time Phishing Eliminated with FIDO? Social Engineering Downgrade Attacks against FIDO Protocols// {[ulqinaku2021_real]} | MFA/RBA | 100 websites (Alexa's top 100 websites) |
| 2021 | TheWebConf | //An Investigation of Identity-Account Inconsistency in Single Sign-On// {[liu2021_investigation]} | SSO | 100 websites (Alexa top 1,000 websites) |
| 2022 | CCS | //DISTINCT: Identity Theft using In-Browser Communications in Dual-Window Single Sign-On// {[jannett2022_distinct]} | SSO | 1,000 domains (Tranco) |
| 2022 | IEEE S&P | //Towards Automated Auditing for Account and Session Management Flaws in Single Sign-On Deployments// {[ghasemisharif2022_saat]} | SSO | 100,000 websites (Majestic) |
| 2022 | IEEE S&P | //The State of the SameSite: Studying the Usage, Effectiveness, and Adequacy of SameSite Cookies// {[khodayari2022_state]} | post-login | 500,000 websites (Alexa top 500K) |
| 2022 | PoPETs | //How Not to Handle Keys: Timing Attacks on FIDO Authenticator Privacy// {[kepkowski2022_handle]} | passkey | 1,000,000 domains (Cisco Umbrella set) |
| 2022 | USENIX Sec | //Phish in Sheep's Clothing: Exploring the Authentication Pitfalls of Browser Fingerprinting// {[lin2022_sheep]} | MFA/RBA | 173,269 websites (APWG) |
| 2022 | USENIX Sec | //Pre-hijacked accounts: An Empirical Study of Security Failures in User Account Creation on the Web// {[sudhodanan2022_hijacked]} | login surface | 75 websites (Alexa global website rankings) |
| 2022 | USENIX Sec | //Gossamer: Securely Measuring Password-based Logins// {[bohuk2022_gossamer]} | operator | 1,300,000,000 other (breach data used in prior work) |
| 2023 | CCS | //"We've Disabled MFA for You": An Evaluation of the Security and Usability of Multi-Factor Authentication Recovery Deployments// {[klivan2023_disabled]} | MFA/RBA | 1,303 websites (2fa.directory) |
| 2023 | CCS | //Evaluating the Security Posture of Real-World FIDO2 Deployments// {[kuchhal2023_evaluating]} | passkey | 100,000 domains (Tranco) |
| 2023 | CCS | //Measuring Website Password Creation Policies At Scale// {[alroomi2023_password]} | login surface | 1,000,000 domains (Tranco) |
| 2023 | IMC | //The Prevalence of Single Sign-On on the Web: Towards the Next Generation of Web Content Measurement// {[ardi2023_prevalence]} | SSO | 10,000 websites (Chrome UX Report (CrUX)) |
| 2023 | NDSS | //A Systematic Study of the Consistency of Two-Factor Authentication User Journeys on Top-Ranked Websites// {[lyastani2023_systematic]} | MFA/RBA | 120 websites (Tranco) |
| 2023 | PoPETs | //Everybody's Looking for SSOmething: A large-scale evaluation on the privacy of OAuth authentication on the web// {[dimova2023_ssomething]} | SSO | 100,000 websites (Chrome User Experience Report (CrUX)) |
| 2023 | USENIX Sec | //A Study of Multi-Factor and Risk-Based Authentication Availability// {[gavazzi2023_multi]} | MFA/RBA | 5,000 websites (Tranco) |
| 2023 | USENIX Sec | //A Large-Scale Measurement of Website Login Policies// {[alroomi2023_login]} | login surface | 1,000,000 domains (Google Chrome User Experience Report (CrUX)) |
| 2023 | USENIX Sec | //Cookie Crumbles: Breaking and Fixing Web Session Integrity// {[squarcina2023_cookie]} | post-login | 100,000 websites (HTTP Archive dataset) |
| 2024 | CCS | //Poster: Security of Login Interfaces in Modern Organizations// {[tchokodeu2024_poster]} | login surface | 73,431 web-pages (custom seed list) |
| 2024 | CCS | //Stealing Trust: Unraveling Blind Message Attacks in Web3 Authentication// {[yan2024_stealing]} | login surface | 18 websites (DappRadar's Top Decentralized Marketplaces list) |
| 2024 | CCS | //Unmasking the Security and Usability of Password Masking// {[hu2024_unmasking]} | login surface | 100 domains (Google CrUX Top 1K domains list) |
| 2024 | IEEE S&P | //To Auth or Not To Auth? A Comparative Analysis of the Pre- and Post-Login Security Landscape// {[rautenstrauch2024_auth]} | post-login | 5,000 websites (CrUX) |
| 2024 | TheWebConf | //The Double Edged Sword: Identifying Authentication Pages and their Fingerprinting Behavior// {[senol2024_double]} | login surface | 100,000 domains (Chrome User Experience Report (CrUX)) |
| 2025 | IEEE S&P | //"Only as Strong as the Weakest Link": On the Security of Brokered Single Sign-On on the Web// {[innocenti2025_only]} | SSO | 1,000,000 websites (Tranco) |
| 2025 | NDSS | //”Who is Trying to Access My Account?” Exploring User Perceptions and Reactions to Risk-based Authentication Notifications// {[wei2025_trying]} | MFA/RBA | 251 websites (Tranco) |
| 2025 | NDSS | //Was This You? Investigating the Design Considerations for Suspicious Login Notifications// {[sahin2025_this]} | MFA/RBA | 100 websites (Tranco) |
| 2025 | PoPETs | //SoK: Web Authentication and Recovery in the Age of End-to-End Encryption// {[blessing2025_authentication]} | passkey | 300 websites (Alexa Top 1M dataset) |
| 2025 | USENIX Sec | //Universal Cross-app Attacks: Exploiting and Securing OAuth 2.0 in Integration Platforms// {[luo2025_universal]} | SSO | 24 other (custom curated list of integration platforms) |
| 2025 | USENIX Sec | //A Framework for Abusability Analysis: The Case of Passkeys in Interpersonal Threat Models// {[daffalla2025_framework]} | passkey | 200 websites (Tranco) |
| 2025 | USENIX Sec | //Demystifying the (In)Security of QR Code-based Login in Real-world Deployments// {[zhang2025_qrcode]} | login surface | 100,000 websites (Tranco top 100K list) |
| 2026 | NDSS | //Connecting the Dots: An Investigative Study on Linking Private User Data Across Messaging Apps// {[kang2026_connecting]} | SSO | 85,053 web-pages (custom seed list of authentication webpages) |
| 2026 | NDSS | //Anchors of Trust: A Usability Study on User Awareness, Consent, and Control in Cross-Device Authentication// {[zhang2026_anchors]} | passkey | 100 websites (Tranco top site list) |
| 2026 | NDSS | //One Email, Many Faces: A Deep Dive into Identity Confusion in Email Aliases// {[wu2026_email]} | login surface | 100 domains (Tranco) |
| 2026 | USENIX Sec | //The State of Passkeys: Studying the Adoption and Security of Passkeys on the Web// {[jannett2026_passkeys]} | passkey | 18,000,000 websites (CrUX 18M) |
| 2026 | USENIX Sec | //Inconsistent, Incomplete, and Insecure: A Survey of Account Security Interfaces// {[bhattacharya2026_asi]} | login surface | 100 websites (Tranco list (ID: 7XN5X)) |

References

The same shared bibliography as the content page; this log adds no entries of its own.

[1]
Sun, San-Tsai; Beznosov, Konstantin (2012): "The devil is in the (implementation) details: an empirical analysis of OAuth SSO systems", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)
[2]
Jannett, Louis; Mladenov, Vladislav; Mainka, Christian; Schwenk, Jörg (2022): "DISTINCT: Identity Theft using In-Browser Communications in Dual-Window Single Sign-On", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)
[3]
Ghasemisharif, Mohammad; Kanich, Chris; Polakis, Jason (2022): "Towards Automated Auditing for Account and Session Management Flaws in Single Sign-On Deployments", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)
[4]
Luo, Kaixuan; Wang, Xianbo; Fung, Pui Ho Adonis; Lau, Wing Cheong; Lecomte, Julien (2025): "Universal Cross-app Attacks: Exploiting and Securing OAuth 2.0 in Integration Platforms", in: Proceedings of the USENIX Security Symposium. (Link)
[5]
Khodayari, Soheil; Pellegrino, Giancarlo (2022): "The State of the SameSite: Studying the Usage, Effectiveness, and Adequacy of SameSite Cookies", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)
[6]
Zheng, Xiaofeng; Jiang, Jian; Liang, Jinjin; Duan, Haixin; Chen, Shuo; Wan, Tao; Weaver, Nicholas (2015): "Cookies Lack Integrity: Real-World Implications", in: Proceedings of the USENIX Security Symposium. (Link)
[7]
Hu, Yuqi; Alroomi, Suood; Sahin, Sena; Li, Frank (2024): "Unmasking the Security and Usability of Password Masking", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)
[8]
Wu, Mengying; Hong, Geng; Chen, Jiatao; Liu, Baojun; Liu, Mingxuan; Yang, Min (2026): "One Email, Many Faces: A Deep Dive into Identity Confusion in Email Aliases", in: Proceedings of the Network and Distributed System Security Symposium. (Link)
[9]
Senol, Asuman; Ukani, Alisha; Cutler, Dylan; Bilogrevic, Igor (2024): "The Double Edged Sword: Identifying Authentication Pages and their Fingerprinting Behavior", in: Proceedings of the ACM Web Conference 2024. (DOI)
[10]
Kepkowski, Michal; Hanzlik, Lucjan; Wood, Ian; Kaafar, Mohamed Ali (2022): "How Not to Handle Keys: Timing Attacks on FIDO Authenticator Privacy", in: Proceedings on Privacy Enhancing Technologies. (DOI)
[11]
Jannett, Louis; Mayer, Andreas; Westers, Maximilian; Mladenov, Vladislav; Mainka, Christian; Schwenk, Jörg (2026): "The State of Passkeys: Studying the Adoption and Security of Passkeys on the Web", in: Proceedings of the USENIX Security Symposium. (Link)
[12]
Lassak, Leona; Pan, Elleen; Ur, Blase; Golla, Maximilian (2024): "Why Aren't We Using Passkeys? Obstacles Companies Face Deploying FIDO2 Passwordless Authentication", in: Proceedings of the USENIX Security Symposium. (Link)
[13]
Wang, Rui; Chen, Shuo; Wang, XiaoFeng (2012): "Signing Me onto Your Accounts through Facebook and Google: A Traffic-Guided Security Study of Commercially Deployed Single-Sign-On Web Services", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)
[14]
Sahin, Sena; Al-Roomi, Suood Abdulaziz; Poteat, Tara; Li, Frank (2023): "Investigating the Password Policy Practices of Website Administrators", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)
[15]
Brandão, Luís T. A. N.; Christin, Nicolas; Danezis, George; Anonymous, (2015): "Toward Mending Two Nation-Scale Brokered Identification Systems", in: Proceedings on Privacy Enhancing Technologies. (DOI)
[16]
Corre, Kevin; Barais, Olivier; Sunyé, Gerson; Frey, Vincent; Crom, Jean-Michel (2017): "Why can't users choose their identity providers on the web?", in: Proceedings on Privacy Enhancing Technologies. (DOI)
[17]
Doerfler, Periwinkle; Thomas, Kurt; Marincenko, Maija; Ranieri, Juri; Jiang, Yu; Moscicki, Angelika; McCoy, Damon (2019): "Evaluating Login Challenges as a Defense Against Account Takeover", in: Proceedings of the ACM Web Conference. (DOI)
[18]
Wei, Tongxin; Wang, Ding; Li, Yutong; Wang, Yuehuan (2025): ""Who is Trying to Access My Account?" Exploring User Perceptions and Reactions to Risk-based Authentication Notifications", in: Proceedings of the Network and Distributed System Security Symposium. (Link)
[19]
Nsieyanji Tchokodeu, Kevin; Schulmann, Haya; Sobol, Gil; Waidner, Michael (2024): "Poster: Security of Login Interfaces in Modern Organizations", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)
[20]
Gavazzi, Anthony; Williams, Ryan; Kirda, Engin; Lu, Long; King, Andre; Davis, Andy; Leek, Tim (2023): "A Study of Multi-Factor and Risk-Based Authentication Availability", in: Proceedings of the USENIX Security Symposium. (Link)
[21]
Kuchhal, Dhruv; Saad, Muhammad; Oest, Adam; Li, Frank (2023): "Evaluating the Security Posture of Real-World FIDO2 Deployments", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)
[22]
Ardi, Calvin; Calder, Matt (2023): "The Prevalence of Single Sign-On on the Web: Towards the Next Generation of Web Content Measurement", in: Proceedings of the ACM Internet Measurement Conference. (DOI)
[23]
Chang, Li; Hsiao, Hsu-Chun; Jeng, Wei; Kim, Tiffany Hyun-Jin; Lin, Wei-Hsi (2017): "Security Implications of Redirection Trail in Popular Websites Worldwide", in: Proceedings of the ACM Web Conference. (DOI)
provenance/security/authentication.txt · Last modified: by karel.kubicek.claude