Pith. sign in

REVIEW 3 major objections 5 minor 45 references

Least Privilege Access for Persistent Storage Mechanisms in Web Browsers

T0 review · 3 major / 5 minor · reviewed 2026-08-12 · deepseek-v4-flash

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

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

desk verdict Useful new measurement of third-party storage access, but the label enforcement has an unspecified overwrite path that undercuts the security claim. read the letter →

arxiv 2411.15416 v1 pith:JJGIGAPM submitted 2024-11-23 cs.CR

Gayatri Priyadarsini Kancherla , Dishank Goel , Abhishek Bichhawat This is my paper · ORCID
classification cs.CR
keywords third-partyscriptscookieslocalStorageIndexedDBleastprivilegeaccesscontrolbrowsersecuritywebmeasurement
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

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

What carries the argument

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

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

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

Reading between the lines

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

  • 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.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 5 minor

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.

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 (3)
  1. [Section 4] 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.
  2. [Sections 5.1 and 5.2] 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.
  3. [Section 5.6] 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.
minor comments (5)
  1. [Section 1] 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.
  2. [Section 6.2] There is a typo in the last sentence: 'firs-party storage' should be 'first-party storage'.
  3. [Tables 3 and 4] 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.
  4. [Section 5.2] 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.
  5. [Appendix Table 7] The entry 'notion_check _cookie_consent' appears to be split across two columns or wrapped incorrectly; please check the table formatting.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the measurement percentages are empirical outputs and the label-based enforcement is an ordinary policy mechanism evaluated against an external baseline.

full rationale

The paper's central claims are empirical measurements and a prototype enforcement mechanism, neither of which reduces to its own inputs. The prevalence percentages (89.84%, 90.98%, 72.49% in Section 4) are obtained by instrumenting getCookie/setCookie, getItem/setItem, and IDBObjectStore.get/put; no parameter is fitted to the reported percentages, and the stated completeness assumption ('As all requests to read and modify storage objects are handled by these APIs (or their variants), our approach is able to record all storage object accesses') is an untested coverage assumption, not a circular reduction. The enforcement claim that the label mechanism 'effectively blocks scripts from other domains, which are not allowed access based on these labels' follows by construction from the access check defined in Section 5.1, but this is the normal definition of a policy enforcement mechanism, and the paper's actual evaluation compares the instrumented browser against the unmodified Firefox browser on 100 websites (Section 5.5-5.6, Table 6), an external baseline. There is no load-bearing self-citation chain: the references cited for background and related work are external works (e.g., the decentralized label model [37] and cookie integrity [45]), and no central premise is justified only by the present authors' prior work. The skeptic's concern about cookie overwrites (whether replacing an existing labeled cookie checks the old Writer label) is a potential security correctness issue, not a form of circularity, and is therefore outside this pass. No circular step satisfies the quote-and-reduction standard, so the score is 0.

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

The central claims rest on measurement and design choices that are not independently established: the completeness of API instrumentation, the reliability of script-origin attribution, the definition of object ownership via first access, and the chosen default of empty read/write label sets. No numerical parameters are fitted to data, but the default label policy is an ad hoc design decision with direct impact on the breakage results.

free parameters (1)
  • Default label policy = empty read/write sets ({}, {})
    Chosen by the authors as the secure default; it determines which scripts may access unlabeled objects, and is the main cause of the reported functionality breakage (Section 5.1, 5.6).
assumptions (6)
  • domain assumption All storage accesses are captured by instrumenting getCookie/setCookie, getItem/setItem, and IDBObjectStore.get/put.
    Stated in Section 4, paragraph 1; other JS paths such as the Cookie Store API are not instrumented, so the completeness claim is unverified.
  • domain assumption The origin of a script is reliably extracted from the URL it was loaded from.
    Section 4 says the domain is 'extracted based on the URL from where the script was loaded'; dynamic injection or loaders can obscure actual execution origin.
  • domain assumption The first script to access a storage object is treated as its creator/owner.
    Section 4 classifies objects by 'the domain of the script which access the cookie for the first time'; objects set by HTTP responses before JS runs may be misclassified.
  • domain assumption Labels persist across sessions until object expiry or manual deletion.
    Section 5.1 states labels are stored across sessions; this assumes the browser's persistent storage keeps the extra metadata.
  • ad hoc to paper The default empty label blocks all third-party scripts except the creator and the host domain.
    Section 5.1 defines this default; it is a design choice, not an external standard, and it drives the functionality breakage reported in Section 5.6.
  • ad hoc to paper Website developers will adopt the new Set-Cookie attributes and JS labeling APIs.
    The approach's effectiveness depends on sites explicitly labeling objects; the paper's own evaluation shows default behavior breaks consent management and analytics (Section 5.6).
invented entities (1)
  • Reader/Writer domain label sets on storage objects
    purpose: Attached to cookies, localstorage, and IndexedDB entries to specify which script domains may read or write the object.
    Introduced in Section 5.1 as new metadata; no external or standalone evidence validates the labeling scheme or its security properties.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Least Privilege Access for Persistent Storage Mechanisms in Web Browsers." pith.science (2026). https://pith.science/paper/JJGIGAPM

@misc{pith2026241115416,
  author       = {Pith},
  title        = {Pith review of: Least Privilege Access for Persistent Storage Mechanisms in Web Browsers},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/JJGIGAPM}},
  note         = {Machine review of arXiv:2411.15416}
}
read the original abstract

Web applications often include third-party content and scripts to personalize a user's online experience. These scripts have unrestricted access to a user's private data stored in the browser's persistent storage like cookies, localstorage and IndexedDB, associated with the host page. Various mechanisms have been implemented to restrict access to these storage objects, e.g., content security policy, the HttpOnly attribute with cookies, etc. However, the existing mechanisms provide an all-or-none access and do not work in scenarios where web applications need to allow controlled access to cookies and localstorage objects by third-party scripts. If some of these scripts behave maliciously, they can easily access and modify private user information that are stored in the browser objects. The goal of our work is to design a mechanism to enforce fine-grained control of persistent storage objects. We perform an empirical study of persistent storage access by third-party scripts on Tranco's top 10,000 websites and find that 89.84% of all cookie accesses, 90.98% of all localstorage accesses and 72.49% of IndexedDB accesses are done by third-party scripts. Our approach enforces least privilege access for third-party scripts on these objects to ensure their security by attaching labels to the storage objects that specify which domains are allowed to read from and write to these objects. We implement our approach on the Firefox browser and show that it effectively blocks scripts from other domains, which are not allowed access based on these labels, from accessing the storage objects. We show that our enforcement results in some functionality breakage in websites with the default settings, which can be fixed by correctly labeling the storage objects used by the third-party scripts.

Figures

Figures reproduced from arXiv: 2411.15416 by the authors.

Figure 1
Figure 1. Cookie access policies in Web browsers scripts from example.com to be executed while any other dynami￾cally loaded script shall not be executed: Content-Security-Policy: script-src https://example.com/; Although CSP allows more fine-grained policies to be specified, it also allows an all-or-none access only, i.e., either all scripts from https://example.com/ will be executed or none of them will. Thus, any third-par… view at source ↗
Figure 2
Figure 2. Cookie tossing by malicious third-party script [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

45 extracted references · 44 canonical work pages

  1. [1]

    https:// portswigger.net/burp

    Burp suite - application security testing software - portswigger. https:// portswigger.net/burp

    work page

  2. [2]

    https: //developer.chrome.com/en/docs/privacy-sandbox/chips/

    Cookies having independent partitioned state (chips) - chrome developers. https: //developer.chrome.com/en/docs/privacy-sandbox/chips/

    work page

  3. [3]

    https://easylist- downloads.adblockplus.org/easylist_noadult.txt

    https://easylist-downloads.adblockplus.org/easylist_noadult.txt. https://easylist- downloads.adblockplus.org/easylist_noadult.txt

    work page

  4. [4]

    https://my.onetrust.com/s/topic/ 0TO1Q000000ItRyWAK/cookie-consent?language=en_US

    Myonetrust | cookie consent articles. https://my.onetrust.com/s/topic/ 0TO1Q000000ItRyWAK/cookie-consent?language=en_US. (Accessed on 09/01/2024)

    work page 2024

  5. [5]

    https://www

    Rfc 6265: Http state management mechanism - third party cookies. https://www. rfc-editor.org/rfc/rfc6265#section-7.1

    work page

  6. [6]

    https://owasp.org/www-community/ controls/SecureCookieAttribute

    Secure cookie attribute | owasp foundation. https://owasp.org/www-community/ controls/SecureCookieAttribute

    work page

  7. [7]

    https://gitlab.gnome.org/GNOME/meld, 2023

    Meld - visual diff and merge tool. https://gitlab.gnome.org/GNOME/meld, 2023

    work page 2023

  8. [8]

    https://dev.to/rdegges/please- stop-using-local-storage-1i04, 2023

    Please stop using local storage - dev community. https://dev.to/rdegges/please- stop-using-local-storage-1i04, 2023

    work page 2023

Show all 45 references
  1. [9]

    https://firefox-source-docs.mozilla

    Testing — firefox source docs documentation. https://firefox-source-docs.mozilla. org/testing/marionette/Testing.html, 2023

    2023

  2. [10]

    https://html.spec.whatwg.org/multipage/webstorage.html, May 2023

    Web storage api. https://html.spec.whatwg.org/multipage/webstorage.html, May 2023

    2023

  3. [11]

    What storage? an empirical analysis of web storage in the wild

    Ahmad, Z., Casarin, S., and Calzavara, S. What storage? an empirical analysis of web storage in the wild. In Proceedings of the Workshop on Measurements, Attacks, and Defenses for the Web (MADWeb) 2022 (April 2022)

    2022

  4. [12]

    An empirical analysis of web storage and its applications to web tracking

    Ahmad, Z., Casarin, S., and Calzavara, S. An empirical analysis of web storage and its applications to web tracking. ACM Trans. Web 18, 1 (Oct. 2023)

    2023

  5. [13]

    Curated hostfile to block trackers and advertisements

    Anudeep. Curated hostfile to block trackers and advertisements. https://github. com/anudeepND/blacklist

  6. [14]

    N., Fass, A., and Shafiq, Z

    Bahrami, P. N., Fass, A., and Shafiq, Z. Poster: Cookieguard: Isolating first party cookies using cookieguard. IEEE Symposium on Security and Privacy (2024)

    2024

  7. [15]

    HTTP State Management Mechanism

    Barth, A. HTTP State Management Mechanism. RFC 6265, Apr. 2011

    2011

  8. [16]

    The Web Origin Concept

    Barth, A. The Web Origin Concept. RFC 6454, Dec. 2011

    2011

  9. [17]

    Indexed Database API 3.0, Dec 2023

    Bell, J. Indexed Database API 3.0, Dec 2023

    2023

  10. [18]

    I know what you did last summer: New persistent tracking mechanisms in the wild

    Belloro, S., and Mylonas, A. I know what you did last summer: New persistent tracking mechanisms in the wild. IEEE Access 6 (2018), 52779–52792

    2018

  11. [19]

    Cookies: HTTP State Management Mechanism draft-ietf-httpbis-rfc6265bis-15

    Bingler, S., West, M., and Wilander, J. Cookies: HTTP State Management Mechanism draft-ietf-httpbis-rfc6265bis-15. RFC 6265, July 2024

    2024

  12. [20]

    Omnicrawl: Comprehensive measurement of web tracking with real desktop and mobile browsers

    Cassel, D., Lin, S.-C., Buraggina, A., W ang, W., Zhang, A., Bauer, L., Hsiao, H.-C., Jia, L., and Libert, T. Omnicrawl: Comprehensive measurement of web tracking with real desktop and mobile browsers. Proc. Priv. Enhancing Technol. 2022, 1 (2022), 227–252

    2022

  13. [21]

    Cookie swap party: Abusing first-party cookies for web tracking

    Chen, Q., Ilia, P., Polychronakis, M., and Kapravelos, A. Cookie swap party: Abusing first-party cookies for web tracking. In Proceedings of the Web Confer- ence 2021 (New York, NY, USA, 2021), WWW ’21, Association for Computing Machinery, p. 2117–2129

    2021

  14. [22]

    Mitigating cross-site scripting with http-only cookies

    Corporation, M. Mitigating cross-site scripting with http-only cookies. http: //msdn.microsoft.com/en-us/library/ms533046(VS.85).aspx, 2002

    2002

  15. [23]

    Cutler, D. J. Cookies Having Independent Partitioned State specification, Nov. 2022

    2022

  16. [24]

    Towards understanding first-party cookie tracking in the field

    Demir, N., Theis, D., Urban, T., Pohlmann, N., and Pohlmann, N. Towards understanding first-party cookie tracking in the field. InGI SICHERHEIT 2022, Ed.: C. Wressnegger (2022), vol. P-323 of Lecture Notes in Informatics (LNI), Proceedings - Series of the Gesellschaft fur Info...

    2022

  17. [25]

    Docs, M. W. Client-side storage, 2024

    2024

  18. [26]

    The cookie hunter: Automated black-box auditing for web authentication and authorization flaws

    Drakonakis, K., Ioannidis, S., and Polakis, J. The cookie hunter: Automated black-box auditing for web authentication and authorization flaws. InProceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security (New York, NY, USA, 2020), CCS ’20, Associatio...

    2020

  19. [27]

    Tcf – transparency & consent framework - iab europe

    Europe, I. Tcf – transparency & consent framework - iab europe. https:// iabeurope.eu/transparency-consent-framework/

  20. [28]

    Directive 2002/58/EC of the european parliament and of the council, 2002

    European Parliament, and Council of the European Union . Directive 2002/58/EC of the european parliament and of the council, 2002

    2002

  21. [29]

    Regulation (EU) 2016/679 of the European Parliament and of the Council, 2016

    European Parliament, and Council of the European Union . Regulation (EU) 2016/679 of the European Parliament and of the Council, 2016

    2016

  22. [30]

    Cross site request forgery (csrf)

    Foundation, O. Cross site request forgery (csrf). https://owasp.org/www- community/attacks/csrf

  23. [31]

    Mea- suring the privacy vs

    Jueckstock, J., Snyder, P., Sarker, S., Kapravelos, A., and Livshits, B. Mea- suring the privacy vs. compatibility trade-off in preventing third-party stateful tracking. In Proceedings of the ACM Web Conference 2022 (New York, NY, USA, 2022), WWW ’22, Association for Computing...

    2022

  24. [32]

    The state of the samesite: Studying the usage, effectiveness, and adequacy of samesite cookies

    Khodayari, S., and Pellegrino, G. The state of the samesite: Studying the usage, effectiveness, and adequacy of samesite cookies. In 2022 IEEE Symposium on Security and Privacy (SP) (2022), pp. 1590–1607

    2022

  25. [33]

    Thou shalt not depend on me: Analysing the use of outdated javascript libraries on the web

    Lauinger, T., Chaabane, A., Arshad, S., Robertson, W., Wilson, C., and Kirda, E. Thou shalt not depend on me: Analysing the use of outdated javascript libraries on the web. arXiv preprint arXiv:1811.00918 (2018)

    2018 arXiv

  26. [34]

    Tranco: A research-oriented top sites ranking hardened against manipulation

    Le Pochat, V., V an Goethem, T., Tajalizadehkhoob, S., Korczyński, M., and Joosen, W. Tranco: A research-oriented top sites ranking hardened against manipulation. In Proceedings of the 26th Annual Network and Distributed System Security Symposium (Feb. 2019), NDSS 2019

    2019

  27. [35]

    Cookiegraph: Measuring and countering first-party tracking cookies

    Munir, S., Siby, S., Iqbal, U., Englehardt, S., Shafiq, Z., and Troncoso, C. Cookiegraph: Measuring and countering first-party tracking cookies. arXiv preprint arXiv:2208.12370 (2022)

    2022 arXiv

  28. [36]

    Scriptprotect: mitigating unsafe third-party javascript practices

    Musch, M., Steffens, M., Roth, S., Stock, B., and Johns, M. Scriptprotect: mitigating unsafe third-party javascript practices. In Proceedings of the 2019 ACM Asia Conference on Computer and Communications Security (2019), pp. 391–402

    2019

  29. [37]

    C., and Liskov, B

    Myers, A. C., and Liskov, B. Protecting privacy using the decentralized label model. ACM Trans. Softw. Eng. Methodol. 9 , 4 (oct 2000), 410–442

    2000

  30. [38]

    Session- shield: Lightweight protection against session hijacking

    Nikiforakis, N., Meert, W., Younan, Y., Johns, M., and Joosen, W. Session- shield: Lightweight protection against session hijacking. In International Sympo- sium on Engineering Secure Software and Systems (2011), Springer, pp. 87–100

    2011

  31. [39]

    Journey to the center of the cookie ecosystem: Unraveling actors’ roles and relationships

    Sanchez-Rola, I., Dell’Amico, M., Balzarotti, D., Vervier, P.-A., and Bilge, L. Journey to the center of the cookie ecosystem: Unraveling actors’ roles and relationships. In 2021 IEEE Symposium on Security and Privacy (SP) (2021), pp. 1990–2004

    2021

  32. [40]

    Don’t trust the locals: Investigating the prevalence of persistent client-side cross-site scripting in the wild

    Steffens, M., Rossow, C., Johns, M., and Stock, B. Don’t trust the locals: Investigating the prevalence of persistent client-side cross-site scripting in the wild. In 2019 Network and Distributed System Security (NDSS) Symposium (01 2019)

    2019

  33. [41]

    Adguard content blocking filters

    Team, A. Adguard content blocking filters. https://github.com/AdguardTeam/ AdGuardFilters

  34. [42]

    Cookie consent management software and tool

    TrustArc. Cookie consent management software and tool. https://trustarc.com/ products/consent-consumer-rights/cookie-consent-manager/

  35. [43]

    Same-Site Cookies, June 2016

    West, M., and Goodwin, M. Same-Site Cookies, June 2016

    2016

  36. [44]

    Content security policy level 3

    West, M., and Sartori, A. Content security policy level 3. https://w3c.github. io/webappsec-csp/, 2023

    2023

  37. [45]

    Cookies lack integrity: Real-World implications

    Zheng, X., Jiang, J., Liang, J., Duan, H., Chen, S., W an, T., and Weaver, N. Cookies lack integrity: Real-World implications. In 24th USENIX Security Sympo- sium (USENIX Security 15) (Washington, D.C., Aug. 2015), USENIX Association, pp. 707–721. Conference’17, July 2017, Was...

    2015

Pith tools

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