Steven Hé (Sīchàng)

browser privacy and multilingual accessibility (authored by agents unless marked 🧑)

research direction

• recommendation: study what happens during real user tasks, rather than count headers or suspicious scripts alone
  • useful outcomes: a task still works, unnecessary access disappears, and a privacy tool does not wrongly exclude its user
  • proposals below are hypotheses, not established new contributions
• scope: browser permissions, shared cookies, fingerprinting, and language support for screen readers
  • related web measurement studies and web trust studies cover adjacent questions
• reading status: selected methods, evaluation, and limitations from eleven full papers
  • checked on 7 October 2026
  • searches found relevant earlier work and limitations, but do not establish exhaustive coverage or novelty

permissions: allowing an API is different from granting user consent

• Fernandez-de-Retana, Rautenstrauch, Santos-Grueiro, and Stock, A Permissions Odyssey, IMC 2025, §§2–6
  • authors’ qualification: “the browser still decides whether to prompt the user or not”
  • Permissions-Policy headers and iframe allow attributes determine whether a document can use particular browser features
    • a camera policy can block a request before any user prompt
    • delegation can make a request possible without automatically granting consent
  • method: Playwright instrumentation records API calls, scripts, headers, and embedded documents
    • July 2024 CrUX top-million origins, crawled once from one German server between 23 August and 1 September 2024
    • waits after loading, with scrolling for lazy iframes but no other interaction
    • 817,800 successful visits; additional incomplete-frame filtering affects particular analyses
    • §4 switches comparisons from the original website list to collected documents, including redirects
  • finding: headers are uncommon, some syntax is invalid, and some delegated permissions have no observed use
    • authors’ careful wording: “potentially over-permissioned”
    • absence during this crawl cannot show that an interactive feature never needs permission
  • existing contribution includes policy recommendation tools based on observed usage
    • another tool that merely removes unobserved permissions would repeat this idea
  • browser support statements describe the paper’s measurement period
    • a new experiment must record exact browser versions and test enforcement rather than assume identical support

proposal: permission reduction with a measured task failure rate

• question: can interactive task evidence reduce unnecessary delegation without breaking legitimate camera, location, or media features?
• hypothesis: recommendations from several complete tasks will cause fewer failures than recommendations from a landing-page crawl
• first experiment: reproduce the authors’ observation-based recommendation on a small controlled collection
  • include a video meeting, support widget, map, and nested embedded content
  • tasks have explicit success checks, such as receiving a camera stream after consent
  • compare original policy, the paper’s recommendation, and recommendations learned from task execution
  • run the same task with fresh sessions, consent granted or denied, and each tested browser version
• measure blocked unwanted API requests, permission requests retained, task failures, and additional measurement time
  • report both document-level and site-level counts
  • hold out tasks and sites when evaluating recommendations
• stop if interactive evidence provides no reliable improvement, or existing tools already perform this evaluation
  • a successful result would support a bounded task-specific policy, not proof that unseen workflows will work

cookies: embedded scripts share the visited page’s authority

• Nikkhah Bahrami, Fass, and Shafiq, CookieGuard, IMC 2025, §§5–8
  • authors’ scope warning: “we do not perform any authenticated logins during the crawl”
  • a remotely hosted script executing in the main page can access that page’s JavaScript-readable cookies
    • the script’s hosting domain does not give it a separate cookie jar
  • prototype intercepts cookie operations and groups script ownership by registrable domain, eTLD+1
    • example: subdomains of example.com belong to the same group
    • §6.1 grants scripts from the visited site’s domain group access to all cookies
    • this is domain-group isolation, not separate authority for every individual script
  • measurement scrolls and follows three random links per site
    • it does not generate authentication cookies or enter personal information
    • HttpOnly cookies are inaccessible to these JavaScript operations
  • evaluation identifies functionality costs, especially login through another service
  • §8 identifies attribution limits in asynchronous callbacks, self-hosted scripts, and concealed hosting domains
    • warning: the section first describes inline scripts as first-party, then says the implemented conservative policy denies them cookie access
    • implementation reproduction must resolve that distinction rather than assume one rule from the prose
  • the paper already proposes authenticated replay and behavior-based script attribution
    • neither idea alone is a new contribution
• Munir et al., CookieGraph, CCS 2023, full paper, §§5.1–5.5
  • authors’ mechanism: “detect first-party tracking cookies”
  • learns which cookies serve tracking from measured behavior, rather than giving every script a separate jar
  • important baseline for avoiding needless breakage when blocking cookies
  • graph records scripts, storage, requests, and observed identifier flows
    • includes localStorage; matches raw values and four selected encodings
    • limits classification to values at least eight characters long
  • random-forest evaluation separates websites across ten folds
    • labels combine filter-list behavior, self-declared Cookiepedia purposes, and propagation across matching setting scripts
    • reported 90.18% accuracy depends on that imperfect ground truth
  • two reviewers tested functionality on 50 sampled sites using Chrome extensions
    • no major SSO breakage with CookieGraph; one major preference-cookie failure prevented navigation
    • absence of login breakage in that sample does not establish general login compatibility
  • inference: classification of tracking purpose differs from identifying which script is authorized to read a cookie
    • value transformations outside the modeled encodings can hide flows
    • cross-site test splits do not establish generalization to unseen tracking vendors
  • artifact separates customized OpenWPM collection, feature extraction, label propagation, and classification
    • instructions inspected; classifier and login tests not executed here
• Demir, Theis, Urban, and Pohlmann, Towards Understanding First-Party Cookie Tracking in the Field, 2022 full paper, §§3.1–3.4 and limitations
  • authors examine “DNS CNAME cloaking” across 15,000 websites
  • a third party can appear under the visited site’s hostname
  • hostname-based attribution therefore needs a clearly stated trust assumption
  • Firefox/OpenWPM visits up to 30 internal pages per site from one EU research network
    • four configurations cross third-party-cookie blocking with uBlock Origin
    • fresh cookie jars, synthetic scrolling, no consent-banner interaction, and no failed-visit retries
  • detects candidate identifiers with string heuristics and observed transmission to other parties
    • requires lifetime above 90 days, at least eight bytes, and run-to-run value variation
    • URL decoding and delimiter splitting can miss transformed values
    • identifier-like strings alone do not prove persistent identification of a person
  • observes browser DNS results and substitutes resolved hostnames for tracker-list matching
    • excludes original/resolved hostnames with more than 70% string similarity
    • tracker lists, company mapping, and DNS stability shape classification
  • authors: “CNAME cloaking is not a problem per se”
    • ordinary content delivery can use the same DNS mechanism
  • inference: keep responsible code, observed endpoint, and endpoint ownership as separate labels

proposal: test whether asynchronous attribution actually preserves isolation

• question: does the protection follow the responsible script through promises, timers, event handlers, and script-created callbacks?
• first experiment: a controlled page with two scripts and synthetic cookies
  • each script sets a distinct cookie and attempts access through direct and delayed calls
  • include inline code, code hosted under the page’s domain, and explicit legitimate sharing
  • record the implementation’s assigned owner and the known responsible script
• baselines: unchanged browser, reproduced CookieGuard, and an implementation that records responsibility across asynchronous scheduling
  • CookieGraph is a separate behavior-based blocking baseline if its artifact is reproducible
    • reproduce its storage-flow instrumentation and freeze the trained classifier before test cases
    • do not interpret a tracking label as evidence of an unauthorized cross-script access
• measure unauthorized reads or writes, attribution errors, legitimate sharing failures, and overhead
  • test login continuity using synthetic accounts on controlled services
  • keep actual authentication secrets out of the measurement dataset
• research uncertainty: CookieGuard explicitly leaves asynchronous flows open
  • extending its implementation may be useful engineering without a sufficient research contribution
  • continue only if the experiment reveals a general failure class or a useful protection-versus-breakage result absent from prior work

fingerprinting: detecting a recognizable image does not establish its purpose

• Luo, Ritter, Savage, and Voelker, Canvassing the Fingerprinters, IMC 2025, §§3–4
  • authors’ scope: “our prevalence results represent a lower bound on canvas fingerprinting”
  • canvas fingerprinting renders an image whose output can depend on the browser and device
  • study groups extracted images to recognize shared services across popular and less-popular sites
  • 2,067 of 16,276 successfully crawled popular sites had a fingerprintable canvas, compared with 1,715 of 17,260 tail sites
    • these are different samples, not a controlled estimate of historical growth
  • filtering excludes lossy image formats, very small images, and scripts using selected animation methods
    • manual checks found no problematic exclusion among 200 sampled filtered images and two false positives among 300 included images
  • homepage-only visits miss inner pages and interactive triggers
    • bot detection may also change what the crawler sees
  • canvas extraction alone does not prove cross-site tracking, fraud detection, or malicious intent
• Venugopalan et al., FP-Inconsistent, September 2025 version, §§7–8
  • authors’ finding: “FP-Inconsistent detected all requests from Tor browser as bots”
  • rules find incompatible fingerprint values within a request or across requests
  • experiment bought traffic from 20 services and tested it against DataDome and BotD on a controlled website
  • held-out requests from the same collection test request-level generalization
    • they do not establish generalization to unseen bot suppliers or future versions
  • real-user check uses 2,206 requests from university students, with a 96.84% true-negative rate
  • privacy-browser check covers a small device and configuration collection
    • Tor false positives and some Brave temporal inconsistencies defeat an unrestricted claim of compatibility with privacy protection
  • additional persistent identifiers can improve detection while harming privacy

proposal: measure the cost paid by legitimate privacy users

• question: which consistency rules reject real users because their privacy software, network, or device changes?
• hypothesis: evaluating only ordinary browser defaults understates this cost
• use a controlled service with known human and automated sessions
  • vary browser privacy settings, shared networks, VPN exit locations, time-zone changes, and browser updates
  • retain participants’ privacy settings and record only the attributes needed for each rule
  • split evaluation by device configuration and session, not random individual requests
• compare original rules, rules that omit location consistency, and rules that treat a changed attribute as uncertain rather than automatically hostile
  • include adaptive bots that maintain internally consistent attributes
• report detection at a fixed human rejection rate, repeated challenge burden, and requested fingerprint information
  • count inaccessible challenges as failed service access, rather than assuming a CAPTCHA solves rejection
• overlap: coordinate bot-measurement methods with the web measurement group
  • candidate contribution is the privacy-user cost and its reduction, not a general bot detector
  • novelty remains unconfirmed

accessibility: a correct language label is only one step toward understandable speech

• Bhuiyan, Varvello, Zaki, and Staicu, Not All Visitors are Bilingual, August 2025 preprint, §§2–4

  • authors’ intervention: “verify whether the description is written in the same language as the page’s visible content”
  • LangCrUX selects 120,000 popular sites across 12 language-country pairs with substantial non-Latin content
    • Puppeteer crawls through country-specific VPNs to collect localized pages
    • eligibility requires enough CrUX-listed sites; smaller language communities can be excluded
  • Kizuki extends Lighthouse’s image alternative-text check with language agreement
  • evaluation covers 10,000 Bangladeshi and Thai sites, excluding those already failing the original missing-alternative-text check
  • lower scores under the new rule establish that the audit changes
    • they do not directly measure whether blind users understand the output or finish their task
    • intentional bilingual descriptions and names need contextual judgment
  • the paper identifies earlier multilingual screen-reader and localization studies
    • language disagreement itself is already a studied problem

• García Garcinuño and Torres-del-Rey, Multilingual Accessibility in Human-Screen Reader Interaction, 2024 full paper, §§5–6

  • authors use “qualitative analysis tools such as thematic coding”
  • analyzes multilingual screen-reader behavior using enhanced test pages and categories of translation and localization problems
  • a new proposal needs to distinguish itself from this existing behavioral evaluation
  • 14 combinations cross seven browser/screen-reader pairs with English and Spanish interface and initial-voice settings
    • JAWS, NVDA, VoiceOver, and TalkBack use selected synthesizers
    • two controlled pages contain dictionary, translation-tool, date, currency, and interactive examples
  • researchers transcribe recorded speech and annotate content language, element descriptions, HTML, and reading mode
    • qualitative compatibility evaluation, not a recruited-user task-completion experiment
  • authors: “subject to user studies”
    • context: whether language mismatches impair people seeking the gist in continuous reading
  • continuous reading and element-by-element navigation can produce different language switching
    • translated content, interface labels, and spoken element names can follow different settings
  • inference: a warning’s effect depends on navigation mode and voice configuration, as well as markup
    • English/Spanish compatibility findings do not establish results for every language

• Era, Ime, and Islam, Bangladesh accessibility/usability preprint, January 2026, §§3–4

  • authors: “The survey aimed to capture user perceptions”
  • combines automated website audits with 103 survey respondents
    • 80.6% students; 95.1% aged 20–35
    • selected 20 commonly used websites for reported experiences
  • asks about navigation, task ease, visible accessibility features, and security perceptions
    • this is self-report rather than observed controlled task completion
    • participant section does not specify a recruited screen-reader-user sample
  • automated sample counts differ within the paper
    • general methods say 212 sites; survey-selection paragraph says 218
    • WAVE successfully analyzes 180; blocked and inaccessible pages remain excluded
  • implication: combining automated audits with user feedback already exists
    • this does not isolate effects of language-label or translation repairs on screen-reader comprehension
  • reading limit: selected full sampling, survey, and audit-result sections inspected
    • recruitment, source data, and measurement artifacts not independently verified

proposal: connect automated language warnings to task outcomes

• question: which language warnings predict misunderstanding, and which changes help a screen-reader user?
• pilot: select mixed-language pages with an image or button needed to complete a task
  • compare existing markup, language-label repair, translated descriptions, and both repairs
  • keep screen reader, voice package, browser, and page content versions fixed and recorded
    • cross continuous reading with element navigation and record interface-language settings
  • use bilingual reviewers to identify intentionally mixed content and incorrect translations
• evaluate with speakers of the page’s language who use screen readers
  • outcomes: task completion, misunderstood labels, repeated listening, and time
  • automated score is a predictor, not the outcome
• compare against Kizuki and earlier multilingual test-page methods
  • distinguish controlled observed task completion from general user-experience surveys
  • use the 2024 study’s different content and element-name languages as controlled compatibility cases
  • separate correction of speech-language switching from comprehension of a translation
  • stop if findings merely reproduce known language-label failures
  • pursue only a reproducible mismatch between audit recommendations and actual task benefit, with a narrower improved rule
• limitation: recruitment and language expertise are needed for a valid user study
  • an automated replay alone can support a compatibility report, not a claim about human comprehension

tracking geography: a contacted server is not the final storage location

• Singh, Ricci, and Gamero-Garrido, Where in the World Are My Trackers?, IMC 2025, §§3–5 and discussion
  • authors’ qualification: “not a definitive map of where companies store their data”
  • Gamma records browser requests and network measurements from the same volunteer machine
    • latency, traceroutes, and reverse DNS constrain server geolocation
    • co-located observations avoid assuming a remote network probe reaches the same server as the browser
  • 22 volunteers cover 23 countries, using local connections
    • recruitment through personal networks, social media, and referrals shapes coverage
    • countries and networks are not a random sample of their populations
  • country-specific website lists include regional and government sites
    • each homepage is visited once without interaction
  • reported endpoints include content-delivery and edge servers
    • unseen downstream forwarding remains outside direct browser observation
  • tracker lists and geolocation misses make the observed tracking set incomplete
    • discussion limits findings to a point in time and one ISP per country
  • contribution already includes volunteer measurement and geographically constrained server inference
    • proposing the same collection in more countries alone is an extension, not a new mechanism
• Prasad et al., RegTrack, MADWeb 2026 work in progress, methods and §V
  • authors’ scope: “we measure tracking behavior rather than legal compliance”
  • jointly varies browser, visitor location, hosting location, and consent state
  • synchronized evaluation reports 743 sites, eight vantage points, four browsers, and two consent states
    • limitations mention an initial 1,005-site collection; distinguish that from the analyzed sample
  • domain-level tracker classification can disagree with URL-level browser blocking
    • a domain being present does not establish that a browser failed to block its tracking URL
  • GeoIP errors, content-delivery networks, and anycast complicate endpoint-country inference
    • anycast routes one address to different physical servers
  • associations between country and tracking do not alone identify regulatory causation

proposal: quantify uncertainty in cross-border endpoint claims

• question: how often does a country label change when the observer, network, browser, or repetition changes?
• pilot: repeat matched pages from two local networks and a VPN in each selected country
  • record the actual contacted IP, request purpose, and consent state
  • compare database-only labels with Gamma’s latency and route constraints
  • retain unresolved endpoints as unknown, rather than assigning a convenient country
• outcomes: label disagreement, confidently supported foreign endpoints, missing coverage, and collection cost
  • report contacted endpoints separately from organization headquarters and unobserved storage
• nearest baselines: Gamma and RegTrack already address geography and collection bias
  • contribution would require a useful uncertainty bound or repeatable failure mechanism beyond their stated limitations
  • stop if results simply show that different observers contact different content-delivery servers

LLM app privacy: a declared input is different from an observed disclosure

• Wu, Jaff, Yang, Zhang, and Iqbal, An In-Depth Investigation of Data Collection in LLM App Ecosystems, IMC 2025, §§3–4 and §6
  • authors’ methodological qualification: “infer the data collected by Actions without necessarily executing them”
  • May 2024 collection includes 119,274 GPT apps and 4,592 Actions
    • third-party directories provide most app discovery
    • this describes a historical dataset, not present platform behavior or policy
  • framework maps natural-language input descriptions to 24 categories and 145 data types
    • taxonomy starts from 1,000 sampled descriptions, Android categories, and iterative review by three human coders
  • privacy-policy comparison extracts relevant sentences and classifies disclosures as clear, vague, or omitted
    • inference quality depends on both classifier errors and ambiguous descriptions
  • large-scale counts concern declared input types and inferred disclosure consistency
    • selected examples additionally examine interactions
    • they do not turn every specification-level classification into a measured runtime transfer
  • §6 acknowledges runtime-dependent collection can escape specification analysis
  • shared-context exposure and isolation are already motivations in the paper
    • the AI agents study covers tool enforcement and allowed data flows

proposal: compare declared inputs with controlled runtime disclosures

• question: which data reaches each tool when its specification asks for a narrow input but surrounding context contains unrelated information?
• first experiment: controlled tool endpoints and synthetic conversations
  • task-relevant details and unrelated marker strings have known ground truth
  • log actual requests received by each endpoint
  • vary explicit fields, free-text fields, multiple tools, and untrusted tool replies
• baselines: the paper’s specification classification and existing isolation or allowed-data-flow enforcement
  • compare observed disclosure against a manually defined task requirement
  • test whether removing unrelated context preserves successful task completion
• outcomes: excess fields, unrelated marker disclosure, missed declared fields, classifier mistakes, and task failures
  • freeze the model, tool definitions, and execution environment
  • synthetic controlled results cannot estimate prevalence across today’s app ecosystem
• novelty remains unconfirmed
  • dynamic collection and tool isolation are existing directions
  • pursue only a repeatable specification-versus-runtime failure class or a demonstrated improvement beyond existing enforcement

next reading before choosing a project

• reproduce the CookieGuard artifact and inspect its exact inline-script and asynchronous attribution behavior
• reproduce CookieGraph’s classifier and selected login cases before claiming compatibility
• follow Canvassing’s authentication-page references before proposing another crawl of login-triggered fingerprinting
• check later multilingual user studies and reproduce selected 2024 test-page cases
• review each proposal against current browser implementations and later papers
  • this page identifies testable questions; it does not claim the questions are unanswered everywhere

Last edited: 2026-10-08