{"id":"f0417da7-d40c-4b9f-8c63-404fce816630","arxiv_id":"2411.15416","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"Labeling cookies, localstorage, and IndexedDB with allowed reader and writer domains lets a modified Firefox block unlisted third-party scripts, but default settings break consent and analytics features until sites add labels.","lead":"A new browser mechanism labels stored website data with the domains allowed to read or write it, blocking third-party scripts that were not granted access. Measurements on the top 10,000 sites show third-party scripts account for roughly 90% of cookie and localstorage accesses, so the mechanism targets a real exposure.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The label mechanism may be bypassable by cookie overwrites because §5.2 never specifies whether setting a cookie with an existing name checks the old cookie's Writer label before replacement.","rationale":"The reader identified incomplete measurement instrumentation as the weakest assumption. That concern affects the accuracy of the prevalence percentages (89.84% / 90.98% / 72.49%), but those numbers are an empirical observation separate from the proposed mechanism. The paper's core contribution is the least-privilege enforcement. If the enforcement permits an unauthorized script to overwrite a labeled cookie by setting the same cookie name, then the mechanism does not achieve its stated security goal, regardless of how accurate the measurements are. The text in §5.1 says read/write access is checked against labels, but §5.2's examples only show label assignment on creation; there is no explicit statement about replacement semantics. Cookie tossing is a concrete attack the paper itself motivates in §3, so this is not an exotic edge case. A single black-box test can settle whether the instrumented browser checks the existing cookie's Writer label before allowing overwrite. Because the paper is currently conditional on reproducibility and completeness, this additional unresolved security-semantics question does not change the verdict category: it remains CONDITIONAL, but the revision should require an explicit specification and test of overwrite handling. I therefore disagree with the reader's choice of weakest assumption, while agreeing that the paper is not ready as-is.","tokens_in":14553,"tokens_out":7143,"duration_ms":65431,"concrete_test":"In the authors' instrumented Firefox build (§5.5), set up a test page where a first-party script creates a cookie 'victim=good' via document.cookie without Reader/Writer labels. Then, from a script served from a different domain, execute document.cookie = \"victim=attacker; SameSite=None; Reader={attacker.com}; Writer={attacker.com}\". Record whether the cookie value or attributes change. If the overwrite succeeds, the Writer label on the existing cookie was not enforced and the mechanism is trivially bypassable. Also repeat with a cookie that has an explicit Writer list excluding the attacker's domain. If any overwrite succeeds, the central security claim fails.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central security claim is that the label-based mechanism 'effectively blocks scripts from other domains, which are not allowed access based on these labels, from accessing the storage objects.' This must include overwriting an existing labeled cookie, since the paper's own motivating attack in §3 is cookie tossing (changing a cookie's SameSite attribute). Sections 5.1 and 5.2 describe labels and the client-side setCookie path, but they only explain how a newly created cookie receives labels and how the creator becomes the owner. They never state the behavior when a script executes document.cookie with the same name/domain/path as an existing labeled cookie. In a stock browser this is an overwrite; if the instrumented setCookie does not first check the existing cookie's Writer label, any third-party script can replace a protected first-party cookie with its own value and grant itself access as the new owner. The paper's evaluation in §5.6 (manual analysis of 100 sites) does not test adversarial overwrites, and no test of this path is reported. Thus the asserted least-privilege guarantee is not established for the very attack the paper identifies.","agreement_with_reader":"disagree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper studies third-party script access to persistent browser storage (cookies, localstorage, IndexedDB) on Tranco's top 10,000 sites, reporting that 89.84% of cookie accesses, 90.98% of localstorage accesses, and 72.49% of IndexedDB accesses are performed by third-party scripts. It then proposes a least-privilege labeling mechanism in which each storage object carries sets of reader and writer domains; the default empty label allows only the host page and the creating script's domain to access the object. The authors implement the mechanism in a modified Firefox browser and report a manual evaluation on 100 websites showing functionality breakage under the default policy, which they argue can be remedied by explicitly labeling objects.","tokens_in":14750,"tokens_out":2897,"duration_ms":27536,"significance":"If the measurement and the enforcement claims are fully supported, the paper would contribute a useful empirical baseline on third-party storage access and a plausible design for fine-grained, least-privilege access control in browsers. The authors have implemented a nontrivial browser prototype and compare it against vanilla Firefox, and the empirical study covers a standard top-10k list. However, several load-bearing points are not yet established: the completeness of the access measurement is asserted rather than verified, and the write-path semantics of the label mechanism are unspecified, which matters for the paper's own motivating cookie-tossing attack. The current evidence does not fully support the abstract's claim that the mechanism 'effectively blocks' unauthorized storage access, nor does it quantify the claimed recovery from functionality breakage after labeling.","major_comments":[{"comment":"The completeness claim that instrumenting getCookie/setCookie, getItem/setItem, and IDBObjectStore.get/put records 'all storage object accesses' is asserted without supporting validation. In particular, the paper does not instrument the Cookie Store API (document.cookieStore), which is another JavaScript path for cookie access, and it does not describe how origins are resolved for dynamically injected scripts or inline event handlers. Since every headline percentage in Section 4 depends on exhaustive capture, the authors should either instrument all known access paths, run a controlled validation page that exercises each path and confirm the log records it, or explicitly state which access paths are excluded and quantify the implied uncertainty in the reported percentages.","section":"Section 4"},{"comment":"The label mechanism's behavior on cookie overwrites is unspecified, and this is load-bearing because the paper's motivating attack in Section 3 is cookie tossing, which is precisely an overwrite of an existing cookie's attributes. The text states that a client-side setCookie call creates a new cookie with the script's domain as owner, and that the owner cannot be changed through JS, but it never states what happens when a script executes document.cookie with the same name/domain/path as an existing labeled cookie. If the implementation simply replaces the cookie and assigns a new owner, then any third-party script can overwrite a protected first-party cookie, claim ownership through the new owner field, and then legitimately read and modify it under the proposed policy. The paper must specify the overwrite check (i.e., that the existing cookie's Writer label is consulted before replacement), and must include a test demonstrating that a third-party script cannot overwrite a labeled cookie it is not authorized to write.","section":"Sections 5.1 and 5.2"},{"comment":"The evaluation demonstrates that the default policy breaks functionality, but it does not test whether the proposed remedy—adding explicit reader/writer labels—actually restores the broken functionality while still blocking unauthorized access. The abstract claims that breakage 'can be fixed by correctly labeling the storage objects,' yet the manual analysis of 100 sites only compares the instrumented browser against the vanilla browser under the default empty-label policy. The paper should include a small set of sites or synthetic pages where labels are set (via Set-Cookie attributes or the proposed JS APIs) and verify that authorized third-party scripts regain access while unauthorized ones remain blocked. Without this, the least-privilege mechanism's deployability claim is not supported.","section":"Section 5.6"}],"minor_comments":[{"comment":"The introduction says 'almost 95% of all cookies, 91% of all the localstorage objects and 74% of IndexedDB objects' are accessed by third-party scripts, while Table 1 and the abstract report 89.84%, 90.98%, and 72.49% of accesses. The relationship between these figures should be reconciled or reworded to avoid an apparent inconsistency.","section":"Section 1"},{"comment":"There is a typo in the last sentence: 'firs-party storage' should be 'first-party storage'.","section":"Section 6.2"},{"comment":"The column labels 'Same Third Party' and 'Different Third Party' are not formally defined in the text; clarify whether 'same' refers to the domain that created the cookie/localstorage object and how the classification handles cookies created by multiple scripts from the same domain.","section":"Tables 3 and 4"},{"comment":"The example 'document.cookie = \"__consent=TRUE; Reader={tkr.com}\"' appears to overwrite a cookie that was previously set by cmp.com; in light of the undefined overwrite semantics in the major comment, this example should be accompanied by a statement of whether the existing Writer label is checked.","section":"Section 5.2"},{"comment":"The entry 'notion_check _cookie_consent' appears to be split across two columns or wrapped incorrectly; please check the table formatting.","section":"Appendix Table 7"}],"recommendation":"major_revision","confidential_remarks":"The paper is a reasonable measurement-plus-prototype contribution, but its central enforcement claim is currently under-specified on the write path, and the measurement's completeness claim needs verification. Both issues are fixable within the manuscript's scope: add a cookie-overwrite test, specify the label check on existing cookies, and run a controlled validation of the instrumented APIs. I would not recommend rejection, but the authors should also consider whether the empirical analysis needs error bars or recrawl variance for a journal audience, since the current presentation treats a single crawl as exact."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: this paper gives you a new measurement of how often third-party scripts touch persistent storage on top sites, and a plausible label-based enforcement design. The numbers are worth having. But the enforcement story has a hole the authors never address: overwriting an existing labeled cookie.\n\nWhat's actually new: the measurement covers cookies, localStorage, and IndexedDB in one crawl of Tranco top 10K, with script-origin attribution. The headline percentages (89.84% cookie, 90.98% localStorage, 72.49% IndexedDB) are new numbers people will quote. The label model, read/write domain sets on each object, is not novel by itself but applying it uniformly to all three storage types in a Firefox prototype is a reasonable combination. The 100-site manual evaluation for functionality breakage is honest—it reports real breakage and says servers need to adopt labels.\n\nWhere it frays. First, the overwrite question. Section 5.2 explains how a newly created cookie gets labels and how the creator becomes the owner. It never says what happens when a script calls document.cookie with the same name/domain/path as an existing labeled cookie. In stock browsers that is an overwrite. If the instrumented setCookie doesn't first check the old cookie's Writer label, any third-party script can replace a protected first-party cookie and become the new owner. That's not hypothetical—the paper's own motivating attack in Section 3 is cookie tossing, changing a cookie's SameSite attribute. The evaluation in Section 5.6 doesn't test adversarial overwrites. The stress-test note is correct; on reading Section 5.2, the behavior is unspecified. This is fixable—a few lines of spec plus a targeted test—but it means the central security claim is not yet established.\n\nSecond, the measurement completeness. Section 4 asserts that all reads and writes go through the instrumented APIs, so the logs capture everything. No validation against ground truth, no mention of the Cookie Store API, no discussion of how script origin is resolved for dynamically injected scripts, no error bars or re-crawl variance for Tables 1–4. The percentages are plausible but presented as exact.\n\nThird, reproducibility. No code or dataset is released (the paper says it will be released upon acceptance). The 100-site functionality evaluation is manual and uses Meld diffs; it's fine as a pilot, not as a guarantee.\n\nThe citation pattern looks fine. Related work is appropriate and the claims about prior works' limitations are mostly accurate.\n\nWho this is for: people working on browser storage privacy, third-party tracking, or cookie hardening. The measurement alone is worth a cite. The enforcement design needs another iteration and explicit adversarial tests before I'd trust it.\n\nRecommendation: send it to peer review. The measurement is a genuine contribution and the label design is worth discussing, but the paper needs a clear statement of overwrite semantics, a completeness argument for the instrumentation, and a release of artifacts. This is revisable rather than broken.","headline":"Useful new measurement of third-party storage access, but the label enforcement has an unspecified overwrite path that undercuts the security claim.","tokens_in":15303,"tokens_out":2343,"would_cite":true,"duration_ms":19617,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper argues that current browser security gives third-party scripts an all-or-none hold on persistent storage, and proposes label-based least-privilege controls to restrict them.","keywords":["third-party scripts","cookies","localStorage","IndexedDB","least privilege","access control","browser security","web measurement"],"falsifier":"Re-run the same Tranco top-10K crawl with navigator.cookieStore, Service Worker cookie access, and dynamically-injected script attribution instrumented; if any of those paths carries a material share of storage accesses that the paper's instrumented APIs cannot see, the 89.84%, 90.98%, and 72.49% percentages will not reproduce.","tokens_in":14327,"feed_emoji":"🔐","tokens_out":7608,"duration_ms":66074,"temperature":0.7,"pith_summary":"The paper argues that current browser security gives third-party scripts an all-or-none hold on persistent storage: any script included on a page can read and modify cookies, localStorage, and IndexedDB objects created for the host. A measurement of Tranco's top 10,000 sites finds that third-party scripts are involved in 89.84% of cookie accesses, 90.98% of localStorage accesses, and 72.49% of IndexedDB accesses. To close the gap, the paper proposes attaching a label to each storage object that names the domains allowed to read and write it, with an empty-label default that blocks everyone except the object's owner and creator. The authors implement this in Firefox and show that it blocks cross-domain scripts while breaking some consent and analytics features until sites add explicit labels.","feed_headline":"Third-party scripts make 9 in 10 browser storage accesses","feed_subtitle":"Today any embedded script can read or change cookies; simple domain labels would restore control.","key_machinery":"The central object is the storage-object label, a pair of sets of domains (readers, writers) attached to each cookie, localStorage entry, or IndexedDB key. Labels are created from extra attributes in Set-Cookie headers or from new setReaders/setWriters JavaScript APIs, and the enforcement point is the browser's storage API boundary, where the calling script's domain is compared with the label before the read or write proceeds. The default label with empty sets gives access only to the object's own domain and its creator, turning the default browser stance from \"any included script can access everything\" to \"only explicitly named domains can access.\"","core_discovery":"The central claim is that third-party scripts dominate real-world access to persistent browser storage, and that a least-privilege labeling mechanism can enforce fine-grained read/write permissions on those objects. Under the same-origin policy, third-party scripts execute in the host page's origin and therefore inherit access to all of its cookies, localStorage, and IndexedDB data; the measurement quantifies how often this happens. The proposed mechanism attaches to each object a label consisting of a read-set and a write-set of domains. A script's domain is checked against these sets at every storage API call, and when the sets are empty the default policy is deny-all except for the object's own domain and the domain that created it. The Firefox prototype demonstrates that unauthorized scripts are blocked, and that the main cost is functionality breakage in cookie-consent and analytics features, which the paper says can be repaired by having servers and scripts supply the correct labels.","pith_inferences":["A natural next measurement would instrument navigator.cookieStore and worker-based cookie access; the paper's API list omits these paths, so its percentages could shift if those APIs carry a meaningful share of traffic.","The label model could compose with state-partitioning defenses, but the paper does not explore how partitioned storage would carry labels or how the two mechanisms would interact.","Deployment may need tooling to infer labels from existing access logs and apply them through proxies or browser heuristics; the paper leaves label adoption to site developers, which is the main practical barrier.","A testable extension is to compare label-enforced behavior against blocking-list-based tools on the same website sample to see whether consent and analytics breakage is specific to default-deny labeling rather than to blocking in general."],"forward_implications":["A default-deny labeling policy would stop third-party scripts from reading or rewriting host cookies, localStorage, and IndexedDB entries unless the host or the script's owner whitelists their domain.","Cross-domain consent management and analytics scripts, the most common third-party storage users, would fail under the default label until sites add reader and writer labels, so deployment requires coordinated labeling by site operators.","The same label check handles cookies, localStorage, and IndexedDB uniformly, so the mechanism does not depend on per-technology flags like HttpOnly.","The measurement implies that existing controls such as SameSite, HttpOnly, and CSP do not materially reduce third-party storage access, because most accesses come from scripts that run inside the host origin.","Labeled objects retain their permissions across sessions until they expire or are deleted, so the enforced policy stays consistent over time."],"supporting_citations":[{"why":"Supplies the Tranco top-10,000 ranking that defines the set of sites crawled in the storage-access measurement.","marker":"[34]"},{"why":"Describes the Marionette automation that drives the instrumented Firefox browser through the crawl.","marker":"[9]"},{"why":"Defines the same-origin policy, the baseline that lets third-party scripts access the host origin's storage.","marker":"[16]"},{"why":"Defines the HTTP cookie model that the paper's labeling extension modifies via new Set-Cookie attributes.","marker":"[15]"},{"why":"Defines the Web Storage API paths, particularly localStorage getItem and setItem, that are instrumented and labeled.","marker":"[10]"},{"why":"Defines the IndexedDB object-store operations whose get and put paths are instrumented and labeled.","marker":"[17]"},{"why":"Provides the decentralized label model that the read-set and write-set enforcement design builds on.","marker":"[37]"},{"why":"Describes the cookie-jar isolation approach that the paper contrasts with its finer-grained per-object labels.","marker":"[14]"},{"why":"Gives earlier empirical evidence that third parties access web storage, which this paper's larger measurement extends.","marker":"[11]"},{"why":"Documents the integrity and confidentiality consequences of cookie access that motivate restricting third-party scripts.","marker":"[45]"}],"fun_headline_variants":["Third-party scripts drive 9 in 10 browser storage accesses","Fine-grained storage permissions for browser scripts","Domain labels enforce least privilege on browser storage","Firefox prototype restricts third-party storage access"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that instrumenting getCookie/setCookie, getItem/setItem, and IDBObjectStore.get/put captures every script access to cookies, localStorage, and IndexedDB, with the script origin correctly attributed from its load URL.","fun_headline_variants_meta":{"raw":{"variants":["Third-party scripts drive 9 in 10 browser storage accesses","Fine-grained storage permissions for browser scripts","Domain labels enforce least privilege on browser storage","Firefox prototype restricts third-party storage access"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000946,"raw_usage":{"total_tokens":4081,"prompt_tokens":1032,"completion_tokens":3049,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":648,"completion_tokens_details":{"reasoning_tokens":2991}},"tokens_in":648,"tokens_out":3049,"duration_ms":21518,"temperature":1.0,"reasoning_tokens":2991,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T14:19:25.016079+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Re-run the same Tranco top-10K crawl with navigator.cookieStore, Service Worker cookie access, and dynamically-injected script attribution instrumented; if any of those paths carries a material share of storage accesses that the paper's instrumented APIs cannot see, the 89.84%, 90.98%, and 72.49% percentages will not reproduce.","supporting_citations":[{"cited_title":"Tranco: A research-oriented top sites ranking hardened against manipulation","cited_arxiv_id":null,"evidence_quote":"Supplies the Tranco top-10,000 ranking that defines the set of sites crawled in the storage-access measurement."},{"cited_title":"https://firefox-source-docs.mozilla","cited_arxiv_id":null,"evidence_quote":"Describes the Marionette automation that drives the instrumented Firefox browser through the crawl."},{"cited_title":"The Web Origin Concept","cited_arxiv_id":null,"evidence_quote":"Defines the same-origin policy, the baseline that lets third-party scripts access the host origin's storage."},{"cited_title":"HTTP State Management Mechanism","cited_arxiv_id":null,"evidence_quote":"Defines the HTTP cookie model that the paper's labeling extension modifies via new Set-Cookie attributes."},{"cited_title":"https://html.spec.whatwg.org/multipage/webstorage.html, May 2023","cited_arxiv_id":null,"evidence_quote":"Defines the Web Storage API paths, particularly localStorage getItem and setItem, that are instrumented and labeled."},{"cited_title":"Indexed Database API 3.0, Dec 2023","cited_arxiv_id":null,"evidence_quote":"Defines the IndexedDB object-store operations whose get and put paths are instrumented and labeled."},{"cited_title":"C., and Liskov, B","cited_arxiv_id":null,"evidence_quote":"Provides the decentralized label model that the read-set and write-set enforcement design builds on."},{"cited_title":"N., Fass, A., and Shafiq, Z","cited_arxiv_id":null,"evidence_quote":"Describes the cookie-jar isolation approach that the paper contrasts with its finer-grained per-object labels."},{"cited_title":"What storage? an empirical analysis of web storage in the wild","cited_arxiv_id":null,"evidence_quote":"Gives earlier empirical evidence that third parties access web storage, which this paper's larger measurement extends."},{"cited_title":"Cookies lack integrity: Real-World implications","cited_arxiv_id":null,"evidence_quote":"Documents the integrity and confidentiality consequences of cookie access that motivate restricting third-party scripts."}],"review_version":1}