Fact-checked by Grok 2 weeks ago

Public Suffix List

The Public Suffix List () is a community-maintained, cross-vendor catalog of all known public suffixes in names, which are the portions of a under which users can directly register names, such as .com, .co.uk, or pvt.k12.ma.us. Initiated by in 2007 as a resource for manufacturers to handle boundaries accurately, the PSL has evolved into a broader community effort involving registries and volunteers to ensure it remains current and comprehensive. Its primary purpose is to enable software, particularly web s like , , , , and , to distinguish between registrable s and their subdomains, thereby preventing privacy vulnerabilities such as supercookies that could track users across unrelated sites. The list addresses the challenge that no universal algorithm can reliably identify public suffixes due to varying policies among (TLD) registries, so it provides an explicit, updatable set of rules in a simple text format. Maintained through submissions from TLD operators and hosted on , the PSL is updated frequently—often multiple times per month—to reflect new TLDs, policy changes, and exceptions, with software developers encouraged to integrate dynamic update mechanisms rather than static copies. Beyond cookie scoping, the supports key web functionalities including domain name highlighting in address bars for better user interface clarity, intelligent sorting of browser history by rather than individual pages, and validation in standards like for and the guidelines for certificate issuance. Libraries such as libpsl in C and regdom-libs for multiple languages facilitate its integration into diverse applications, underscoring its role as a foundational tool for secure and user-friendly navigation. Discussions and amendments are coordinated via a public Google Group, ensuring transparency and collaboration across the ecosystem.

Background

Definition and Purpose

The Public Suffix List (PSL) is a community-maintained, machine-readable catalog of rules that identifies known public suffixes—such as .com, .co.uk, and github.io—which delineate the boundaries for domain name registration managed by independent organizations like domain registries. These public suffixes represent the portions of domain names that are not under the direct control of individual registrants but are instead governed by policies from top-level domain (TLD) operators or other authorities. The list serves as a standardized reference to parse domain hierarchies accurately, addressing the absence of a universal algorithm for determining registrable boundaries in the (DNS). The primary purpose of the PSL is to enhance web and by defining the scope of user-controlled domains, thereby preventing issues like overly broad scoping that could allow malicious sites to set across unrelated domains. For instance, it ensures that set on example.co.uk cannot be scoped to the entire .co.uk suffix, limiting potential tracking or risks, unlike simpler TLDs like .com where second-level domains are the registrable unit. Beyond , the PSL supports features such as accurate site grouping in browser address bars, URL highlighting to distinguish domain parts, and subdomain restrictions in policies. A key distinction in the PSL framework is between public suffixes, which any entity can register under according to registry rules (e.g., registering under the suffix), and registrable domains, which are the specific, user-controlled portions like that sit atop a public . This separation helps applications identify the "eTLD+1" (effective plus one level), enabling precise handling of domain ownership. Initiated by in the mid-2000s as a cross-vendor resource to standardize domain parsing in , the is distributed under the version 2.0 to facilitate broad adoption.

History and Development

The Public Suffix List originated in 2007 as an initiative by the to enhance Firefox's cookie handling mechanisms and mitigate security risks associated with domain spoofing, particularly for top-level domains with multi-level registration policies. This effort addressed inconsistencies in earlier heuristic-based approaches to determining registrable domain boundaries, replacing them with an explicit, maintainable list. The first public version of the list was released in March 2007, marking the beginning of its evolution from a browser-specific tool to a broader community resource. Key milestones in the PSL's development include its integration into other major web browsers, such as and , by 2010, which expanded its adoption beyond Firefox for consistent domain boundary enforcement. In 2011, the list was formally split into public and private sections to accommodate non-registry-controlled suffixes like blogspot.com, following the addition of the first private entry (operaunite.com) in 2009 and aligning with RFC 6265's recommendation for standardized use in cookie scoping. This expansion reflected growing recognition of private operators' needs in domain management. By 2014, the project transitioned to daily automated updates incorporating ICANN's TLD data, improving timeliness amid the proliferation of new generic top-level domains (gTLDs). The PSL's maintenance has been volunteer-driven since its inception, hosted on GitHub at github.com/publicsuffix/list, where community contributions are coordinated through the publicsuffix-discuss Google Group. Primary contributors include volunteers, with significant collaboration from ICANN's Office of the (OCTO) and the Security and Stability Advisory Committee (SSAC), as evidenced by efforts starting in 2011 and the 2015 SSAC advisory SAC070 on suffix list usage. Registries submit amendments for review, ensuring the list remains accurate without centralized control. In recent years, the PSL faced a notable surge in submission requests in 2021, triggered by Apple's 14.5 privacy updates, which prompted marketers and platforms like to seek additions for platform-specific domains to navigate new tracking restrictions. This led to temporary freezes on certain approvals to maintain the list's integrity. As of November 2025, development continues without major overhauls, focusing on regular incorporations of new gTLDs and ongoing community vetting, with the list updated as recently as May 2025 to reflect evolving DNS structures. In May 2025, an update addressed concerns regarding subdomain setups on platforms like , reinforcing the PSL's guidelines for submissions.

Structure and Maintenance

Format and Rules

The Public Suffix List (PSL) is distributed as a plain-text file named public_suffix_list.dat, consisting of a series of lines each representing a single rule, with comments prefixed by // for metadata such as source URLs or section delimiters. The file is divided into two main sections: the ICANN section, which covers official top-level domains (TLDs) managed by the (ICANN), such as .com and country-code TLDs like .uk; and the private section, which includes suffixes controlled by private entities or registrars, such as *.github.io for GitHub-hosted sites. Rules follow a simple syntax where each line specifies a domain suffix without a leading dot, using exact matches for precise suffixes (e.g., com for the .com TLD), wildcards denoted by an (*) at the beginning to cover all subdomains of a multi-level suffix (e.g., *.ck for any subdomain under the TLD), and exceptions prefixed by an (!) to exclude specific subdomains from wildcard rules (e.g., !www.ck to treat www.ck as a registrable domain rather than part of the public suffix). The list supports internationalized domain names (IDNs) by including representations (e.g., xn--11b4c3d for .कॉम) alongside labels in comments for clarity. As of November 2025, the PSL contains over 10,000 rules, reflecting the growing number of TLDs and private suffixes, and it lacks built-in static validation mechanisms, necessitating dynamic updates for accuracy in applications. To determine the public suffix for a given , the parsing traverses the components from right to left, splitting the by dots (e.g., www.example.co.uk becomes ["www", "example", "co", "uk"]), and matches against the to find the longest applicable rule, prioritizing exceptions over wildcards and wildcards over exact matches. If a wildcard like *.co.uk matches, the identifies the preceding to define the registrable ; for an exact match like co.uk, the suffix ends there, excluding any further leftward extension. This process ensures the registrable (or effective) is isolated, such as identifying example.co.uk as the boundary for -specific operations like scoping. For instance, in the domain sub.example.co.uk, the algorithm matches the rule co.uk as the public suffix, resulting in example.co.uk as the registrable domain, which permits set on example.co.uk to apply to sub.example.co.uk but not to unrelated sites under .uk.

Update Process and Submissions

The Public Suffix List (PSL) maintains its currency through a combination of automated and manual processes. The section, covering official top-level domains (TLDs), is automatically generated from 's IANA root zone database and delegated TLD lists, with updates incorporated periodically into the repository and the hosted version refreshed daily from . Manual additions, particularly for private-use suffixes in the PRIVATE section, are handled through community-driven contributions via pull requests to the project's repository. Proposals for new suffixes are submitted using the online form at publicsuffix.org/submit, which guides users toward creating a pull request with required details such as rationale, example domains, and evidence of authenticity. Discussions and reviews occur on the publicsuffix-discuss Group, where submitters must provide proof of a public registration policy, such as official registry rules or administrative control verification via methods like RFC 8553 TXT records in DNS. Criteria emphasize security implications, rejecting entries intended to circumvent tracking protections, experimental projects, or those without long-term public availability (typically requiring over two years of registration). The review workflow is managed by community volunteers, primarily coordinated by , who validate submissions for format compliance, DNS accuracy, and policy adherence over a period that can range from days to several weeks, depending on complexity and availability. Automated tests via tools like Actions assist in initial checks, but final approval requires manual oversight to prevent abuse. Rejections are common for speculative or non-public requests; for instance, in 2021, a surge of submissions triggered by iOS privacy changes led to a temporary halt and widespread denials of proposals aimed at evading Apple's App Tracking rules. Updated versions of the list are distributed via the repository, with mirrors hosted at publicsuffix.org for easy access in formats like public_suffix_list.dat. Implementing software and services are advised to fetch the list periodically, such as weekly, to mitigate risks from outdated versions that could affect domain parsing accuracy. As of , the process continues to prioritize rigorous validation to address vulnerabilities exposed by past incidents, handling a steady stream of proposals while maintaining a low-volume, volunteer-led operation.

Applications

In Web Browsers

Web browsers integrate the Public Suffix List (PSL) primarily to enforce secure boundaries for domain-related features, ensuring that user data and permissions are scoped appropriately to prevent unauthorized cross-site access. A key application is in cookie scoping, where browsers such as , , , and use the PSL to restrict cookies to registrable domains rather than public suffixes. For instance, this prevents a cookie set with a domain attribute like ".co.uk" from applying to all sites under the , thereby mitigating risks of broad tracking or data leakage across unrelated sites. The also supports elements and mechanisms in browsers. In Chrome's omnibox and , it identifies the registrable domain (eTLD+1) for visual grouping and highlighting, such as treating "example.co.uk" as a single entity distinct from its public suffix ".co.uk" to aid of site ownership. Similarly, leverages the PSL in its Enhanced Tracking Protection to define site isolation boundaries, blocking cross-site trackers and cookies that could span multiple registrable domains, enhancing overall privacy controls. Implementation varies across browsers but centers on embedding or fetching the PSL for real-time domain parsing. bundles an up-to-date version of the PSL directly into its releases, parsing it to determine effective top-level domains during runtime operations like validation. and , being Chromium-based, include a pre-compiled of the PSL in each build, sourced from Mozilla's repository and mirrored by , with updates propagating through browser release cycles every 6 to 12 weeks to balance security and performance. Historically, adopted partial PSL-like functionality through third-party domain lists and basic RFC-compliant rules for scoping, though it lacked full native integration until its deprecation. incorporates the PSL via WebKit's domain parsing for features like tracking prevention, aligning with cross-vendor standards. Since its widespread adoption around 2010, the PSL has significantly contributed to reducing cross-site attacks by enforcing stricter domain boundaries, preventing "super cookies" that exploit public suffixes for unauthorized tracking. As of November 2025, all major browsers—collectively holding over 95% global , including (approximately 73%), (13%), (5%), and Firefox (2%)—rely on the PSL, with updates synchronized via regular release channels to maintain efficacy against evolving threats. A practical example illustrates this scoping: for domains like "user.github.io," the PSL lists "github.io" as a private public suffix under the "io" top-level domain, treating "github.io" as the boundary rather than just "io." This ensures cookies set by one user's repository (e.g., on "alice.github.io") cannot scope to ".github.io" and affect another user's site (e.g., "bob.github.io"), isolating data to individual registrable domains and protecting against cross-repository tracking.

In Software Libraries and Services

The Public Suffix List (PSL) is integrated into various software libraries and tools to enable accurate domain parsing and validation outside of browser environments. A prominent example is libpsl, a C library designed to handle PSL data for identifying public suffixes, verifying domains, and processing internationalized domain names (IDNs) in and formats. This library is thread-safe and compresses the PSL dataset to approximately 32 kB using a (DAFSA), making it efficient for embedded use. It powers domain handling in command-line tools such as , which employs it for cookie scoping to prevent overly broad domain settings, and , which uses it for domain checks during file retrievals. Bindings extend libpsl's functionality to other languages, including Python's publicsuffixlist package, a pure-Python implementation compliant with official PSL test data that supports public and private suffix extraction for IDNs. Similarly, psl.js provides parsing for and browsers, breaking down domains into subdomains, second-level domains, and top-level domains while validating against the PSL. Beyond core libraries, the PSL supports domain policy enforcement in online services for security and compliance. , an automated , relies on the PSL to limit wildcard certificate issuance to registrable domains, preventing certificates for public suffixes like ".co.uk" and ensuring subdomains such as "customer-one.apps.mydomain.com" are treated as independent for if listed in the private PSL section. incorporates the PSL into its DNS and zone management to restrict zone creation, blocking unauthorized broad wildcards like ".example.co.uk" to mitigate abuse and enforce on potentially exploitable hierarchies. The Tranco ranking service, used by security researchers for top-site analysis, applies the PSL to aggregate and normalize domain listings from sources like , , and , ensuring consistent identification of registrable domains across datasets. The PSL also underpins key standards for domain-related protocols. In DMARC email authentication, it defines organizational domains by identifying the registrable boundary (e.g., distinguishing "example.co.uk" from subdomains), enabling anti-spam policies as outlined in RFC 7489. The CA/Browser Forum's Baseline Requirements recommend consulting the PSL to avoid over-broad wildcard certificates, advising regular updates to align with current suffixes for validation during issuance. For web standards, the PSL informs cookie attributes by setting inheritance boundaries, restricting cookies to the registrable domain to enhance privacy against cross-site tracking. As of 2023 measurements, the is implemented or depended upon in over 270 open-source projects, with bindings available in most modern programming languages, reflecting its broad adoption for domain compliance. In web services, misconfigurations tied to outdated PSL usage affect thousands of domains across popular hosts, underscoring its role in approximately 25% of analyzed projects for production decisions.

Challenges and Alternatives

Technical and Policy Issues

One significant technical challenge with the Public Suffix List (PSL) arises from outdated versions, which can lead to improper scoping of cookies and enable leakage across unintended domain boundaries. For instance, if a new top-level domain (TLD) such as .xyz is not promptly incorporated into the PSL, software relying on an obsolete list may treat it as a registrable domain rather than a public suffix, allowing cookies set on xyz.example to be accessible by subdomains under xyz, potentially exposing user data to unauthorized parties. A 2023 study by McQuistin et al. analyzed 273 open-source projects on GitHub and found that 24.9% embedded static, outdated PSL versions with a median age of 825 days, resulting in misclassification of privacy boundaries for 1,313 effective TLDs and affecting 50,750 domains, including security tools like Bitwarden. No major data breaches directly attributed to these issues have been reported, but the vulnerabilities underscore the risks of delayed updates. Parsing the PSL introduces additional edge cases, particularly with Internationalized Domain Names (IDNs) and wildcard rules. The list includes IDN ccTLDs in Punycode format (e.g., xn--p1ai for .), requiring parsers to handle normalization to avoid mismatches that could incorrectly group domains. Wildcards, denoted by *, cover broad patterns like *.ck for all subdomains under .ck, while exceptions prefixed with ! (e.g., !www.ck) override them to treat specific labels as registrable, complicating real-time matching algorithms in browsers and libraries. These features ensure accurate boundary detection but demand robust implementation to prevent errors in domain decomposition. Performance overhead is another concern, as real-time matching against the PSL—comprising thousands of rules—can impose computational costs in high-volume environments like web servers or proxies. The Security and Stability Advisory Committee (SSAC) noted in that large static lists may introduce delays in low-overhead transactions, prompting recommendations for optimized data structures like tries or compiled binaries in libraries such as publicsuffix-go. Policy tensions in PSL maintenance revolve around balancing stringent security measures against usability demands from domain operators. Restrictive rules prevent broad cookie setting but can hinder legitimate multi-tenant platforms; for example, in 2021, submissions from entities like were rejected to avoid undermining Apple's 14.5 App Tracking Transparency framework, frustrating ad measurement on shared domains and highlighting conflicts between privacy enforcement and business needs. This incident exacerbated review backlogs, as the post- 14.5 surge in inappropriate submissions—aimed at bypassing tracking limits via Pixel verification—overwhelmed volunteer reviewers, with issue #1245 emphasizing the labor burden and prioritization delays. Privacy concerns stem from broad suffixes and private entries in the . Entries like *.amazonaws.com, listed in the section, designate AWS S3 buckets as non-registrable to restrict cross-subdomain tracking, but misconfigurations could enable service-wide that aggregate user activity across tenants. Similarly, private suffixes intended for internal use (e.g., corporate intranets) risk exposing organizational structures if inadvertently revealed in public contexts, as outdated or incomplete lists fail to enforce proper isolation, per the 2023 McQuistin et al. analysis of suffixes like digitaloceanspaces.com. Ongoing challenges in the community-driven maintenance model arise from manual review processes and submission volumes. To mitigate these issues, experts recommend that software automatically fetch and apply PSL updates at least weekly, as implemented in , to minimize exposure from staleness while reducing parser overhead through incremental diffs.

Emerging Proposals

One notable proposal to address the static limitations of the Public Suffix List (PSL) is the Domain Boundaries (DBOUND) initiative, an IETF draft from 2020 to 2023 that advocates for DNS-based discovery of domain boundaries using dedicated resource records. This approach would enable dynamic identification of administrative control differences between related DNS names, such as distinguishing between example.com and its subdomains, thereby reducing reliance on manually maintained static lists like the PSL. The proposal, authored by Suzanne Woolf, Craig Pearce, and Tim Wicinski, emerged from renewed interest following an informal IETF 115 side-meeting in 2022, building on an earlier working group that concluded without consensus in 2017. The original BOF request was last updated in February 2023. As of November 2025, work continues with a new individual Internet-Draft (draft-yao-dbound-identify-dns-boundary-01), authored by Jiankang Yao and Hongbin Luo, published on September 7, 2025, and currently in ISE review. Another significant extension is Google's First Party Sets (FPS), later renamed Related Website Sets (RWS) in 2023, introduced as part of the Privacy Sandbox initiative from 2022 to 2025 to facilitate cross-site grouping of related domains—such as google.com and youtube.com—without necessitating expansions to the PSL. This mechanism allows affiliated sites to declare shared ownership through a canonical JSON list and the Storage Access API, preserving functionalities like sign-in and analytics amid third-party cookie restrictions, while limiting sets to five domains plus variants to mitigate abuse. Rolled out in Chrome origin trials starting with version 89 and reaching stable implementation in Chrome 117, it faced criticism for potential centralization risks due to Google's oversight of submissions and the static nature of the approved sets list. By November 2025, however, RWS was deprecated alongside much of the Privacy Sandbox, following low adoption and regulatory hurdles, with the repository archived on November 7, 2025. Additional ideas under discussion include dynamic TLD feeds coordinated by to automate updates beyond manual submissions, registry-signed manifests for handling private domains more securely, and deeper integration with DNSSEC to enable verifiable suffix discovery. A practical example of the latter is the Public Suffix List DNS Query Service proposed in 2021, which hosts data under query.publicsuffix. as PTR and records, allowing clients to query public suffixes dynamically with authenticity guaranteed by DNSSEC signatures. This service supports standard suffixes, wildcards, and exceptions without requiring local list maintenance, addressing scalability by leveraging existing DNS infrastructure. As of November 2025, no consensus has emerged on full replacements for the , with RWS limited to trials before and broader alternatives facing hurdles across browsers. Community discussions continue through IETF working groups and Mozilla's involvement, emphasizing solutions that enhance and without fragmenting standards. These proposals collectively target the PSL's static nature by promoting dynamic, verifiable mechanisms, though adoption barriers persist due to the need for cross-browser coordination and DNS ecosystem changes.

References

  1. [1]
    Public Suffix List
    The Public Suffix List is a list of all known public suffixes. The Public Suffix List is an initiative of Mozilla, but is maintained as a community resource.The List · Submit Amendments · Learn MoreMissing: official | Show results with:official
  2. [2]
    Learn more about the Public Suffix List
    The Public Suffix List is a cross-vendor initiative to provide an accurate list of domain name suffixes, maintained by the hard work of Mozilla volunteers.
  3. [3]
    View the Public Suffix List
    Feb 8, 2022 · View the Public Suffix List. The list is kept in source code control on Github. You can read more information on the format the list uses below.
  4. [4]
    Submit amendments to the Public Suffix List
    In order to make the Public Suffix List (PSL) as current and accurate as possible, we request that Top-Level Domain (TLD) registries put in place processes to ...
  5. [5]
    Public Suffix List - Mozilla Wiki
    Nov 19, 2020 · The Public Suffix List (PSL) is an attempt to build a database of Top-Level Domains (TLDs) including the respective registry's policies on ...
  6. [6]
    public_suffix_list.dat - Public Suffix List
    Pulling from any other URL is not guaranteed to be supported. // Instructions on pulling and using this list can be found at https://publicsuffix.org/list/.
  7. [7]
    [PDF] A First Look at the Privacy Harms of the Public Suffix List | Brave
    Oct 26, 2023 · The public suffix list groups domains into organizations. Outdated versions cause privacy harms, affecting cookie access and making incorrect ...
  8. [8]
  9. [9]
  10. [10]
    [PDF] PUBLIC SUFFIX LIST - ICANN
    OTHER USES. ▫ LET'S ENCRYPT AND OTHER CA – AVOID WILDCARD CERT FOR ETLD, PRESENCE ON PSL WORKS AROUND LIMITS PER CERT.
  11. [11]
    publicsuffix/list: The Public Suffix List - GitHub
    The Public Suffix List is a list of all known public suffixes. See https://publicsuffix.org/ and the Wiki link above for more information.
  12. [12]
    Apple's pending privacy clampdown drives desperate marketers to ...
    Apr 9, 2021 · The Public Suffix List (PSL) is a Mozilla-founded, community-run project to provide a list of domain suffixes, from .com and .co.uk to things ...Missing: 2010 2011 2014<|control11|><|separator|>
  13. [13]
    Security Considerations · publicsuffix/list Wiki - GitHub
    Oct 28, 2024 · The PSL adheres to the ICP-3 "A Unique, Authoritative Root for the DNS", and includes and enhances the ICANN/IANA Public Suffix List.<|separator|>
  14. [14]
    Format
    ### Summary of File Format, Rule Syntax, Wildcards, Exceptions, and Sections
  15. [15]
    [PDF] The Public Suffix List: A Guide for TLD Administrators - icann
    May 18, 2020 · The Public Suffix List (PSL) is a machine-readable list of domain names that support subdomains operated by unaffiliated organizations.
  16. [16]
    Guidelines
    ### Summary of Guidelines from https://github.com/publicsuffix/list/wiki/Guidelines
  17. [17]
    psl-discuss - Google Groups
    Groups. Search. Clear search. Close search. Main menu. Google apps. Groups ... This group is low-traffic and ... publicsuffix-discuss@. unread,. Firefox PSL ...
  18. [18]
    Pull requests · publicsuffix/list
    ### Merged Pull Requests per Year (2020–2025)
  19. [19]
    Cookies and the Public Suffix List | Heroku Dev Center
    Apr 30, 2024 · This list is used in recent versions of several browsers, such as Firefox, Chrome and Opera, to limit how broadly a cookie may be scoped. In ...
  20. [20]
    Tracking Prevention in WebKit
    A registrable domain is a website's eTLD+1 or effective top-level domain plus one label. Effective top-level domains are defined in the Public Suffix List.
  21. [21]
    How often is Public Suffix List updated? - Google Groups
    The timeframe often communicated is between 6 - 18 months for new additions to propagate through, and longer for removals.
  22. [22]
    Browser Market Share Worldwide | Statcounter Global Stats
    This graph shows the market share of browsers worldwide from Oct 2024 - Oct 2025. Chrome has 73.17%, Safari has 13.27% and Edge has 4.62%.United States Of America · Desktop · India · North AmericaMissing: Public Suffix
  23. [23]
  24. [24]
    rockdaboot/libpsl: C library for the Public Suffix List - GitHub
    libpsl - C library to handle the Public Suffix List. A Public Suffix List is a collection of Top Level Domains (TLDs) suffixes.
  25. [25]
    publicsuffixlist - PyPI
    The Public Suffix List maintained by the Mozilla Foundation is licensed under the Mozilla Public License 2.0. The PSL testcase dataset is in the public ...
  26. [26]
    psl - NPM
    Dec 2, 2024 · The Public Suffix List is a cross-vendor initiative to provide an ... Unpacked Size. 712 kB. Total Files. 14. Last publish. a year ago ...
  27. [27]
    Limits in Public Suffixes List - Help - Let's Encrypt Community Support
    Jul 28, 2020 · Hello, I would to clarify about the way how Let's Encrypt interacts with public domains that belongs to Public Suffixes List.
  28. [28]
    Information About the Public Suffix List (PSL) and Cloudflare ...
    May 28, 2025 · The Public Suffix List is not a Cloudflare-specific tool or workaround for account limitations. It's a global internet infrastructure resource ...
  29. [29]
    M3AAWG Calls for Coalition to Support Public Suffix List - DMARC.org
    And the PSL is used for much more than DMARC. It was created to help browsers make decisions about which HTTP cookies a given website could create or read.
  30. [30]
    Latest Baseline Requirements | CA/Browser Forum
    Current best practice is to consult a “public suffix list” such as the Public Suffix List (PSL), and to retrieve a fresh copy regularly. If using the PSL, a ...Baseline · Baseline Requirements · Certificate Contents · FAQ for Baseline...
  31. [31]
    Public Suffix Lookups Without Parsing the PSL
    In order to decide how exactly cookie scoping should be restricted across domains, browsers determine public suffixes.Missing: web | Show results with:web
  32. [32]
    New interaction between IOS 14.5 PCM and Facebook Pixel ...
    Mar 24, 2021 · Additionally, we will support domains included in the Public Suffix List. This would enable businesses to verify their eTLD+1 domains if the ...Missing: 2010 2011
  33. [33]
    sleevi/psl-problems - Public Suffix List - GitHub
    A collection of thoughts from a maintainer of the Public Suffix List (PSL) about the importance of avoiding new Web Platform features, security, or privacy ...Missing: risks | Show results with:risks
  34. [34]
    How does Chrome or any other browser use Public Suffix List?
    May 12, 2020 · Both Chrome and Firefox include a copy of the Public Suffix List in each build. You can find this for Chromium here, and for Firefox here.How is SameSite defined for domains which are not on the public ...public suffix list: why isn't wordpress.com listed there? - Stack OverflowMore results from stackoverflow.com
  35. [35]
    Domain Boundaries (DBOUND) - IETF Datatracker
    Feb 23, 2023 · Any protocols or practices that already exist in this space: Public Suffix List (PSL) - https://publicsuffix.org/; Which (if any) ...
  36. [36]
    the new name for First-Party Sets in Chrome 117 - Privacy Sandbox
    Aug 31, 2023 · Related Website Sets (RWS) is the new name for First-Party Sets. It also brings increased flexibility in defining sets.Missing: PSL 2022-2025
  37. [37]
    WICG/first-party-sets - GitHub
    This document proposes a new web platform mechanism to declare a collection of related domains as being in a Related Website Set.Missing: PSL 2022-2025
  38. [38]
    Related Website Sets - The Chromium Projects
    Navigate to chrome://flags/#use-first-party-set. Enable the First-Party Set flag. For the flag value, enter a comma-separated list of domains. (Note that all ...Missing: PSL 2022-2025
  39. [39]
    Update on Plans for Privacy Sandbox Technologies
    Oct 17, 2025 · In this October 2025 announcement, the Privacy Sandbox team shares updates on plans for Privacy Sandbox technologies.
  40. [40]
    None
    ### Summary of Public Suffix List DNS Query Service Proposal
  41. [41]
    The Present and Future of the Public Suffix List - M3AAWG |
    May 23, 2023 · The PSL includes the names of all the domains under which new (private) domains can be directly registered.<|control11|><|separator|>