Add com.free to Public Suffix List

[websitesDev]

Public Suffix List (PSL) Submission

Checklist of required steps

• Description of Organization

• Robust Reason for PSL Inclusion

• DNS verification via dig

• Each domain listed in the PRIVATE section has and shall maintain at least two years remaining on registration, and we shall keep the _psl TXT record in place in the respective zone(s).

Submitter affirms the following:

• We are listing any third-party limits that we seek to work around in our rationale such as those between IOS 14.5+ and Facebook (see Issue #1245 as a well-documented example)

• Cloudflare
• Let's Encrypt
• MAKE SURE UPDATE THE FOLLOWING LIST WITH YOUR LIMITATIONS! REMOVE ENTRIES WHICH DO NOT APPLY AS WELL AS REMOVING THIS LINE!

• This request was not submitted with the objective of working around other third-party limits.

• The submitter acknowledges that it is their responsibility to maintain the domains within their section. This includes removing names which are no longer used, retaining the _psl DNS entry, and responding to e-mails to the supplied address. Failure to maintain entries may result in removal of individual entries or the entire section.

• The Guidelines were carefully read and understood, and this request conforms to them.
• The submission follows the guidelines on formatting and sorting.

• A role-based email address has been used and this inbox is actively monitored with a response time of no more than 30 days.

Abuse Contact:

• Abuse contact information (email or web form) is available and easily accessible.

  URL where abuse contact or abuse reporting form can be found:

---

For PRIVATE section requests that are submitting entries for domains that match their organization website's primary domain, please understand that this can have impacts that may not match the desired outcome and take a long time to rollback, if at all.

To ensure that requested changes are entirely intentional, make sure that you read the affectation and propagation expectations, that you understand them, and confirm this understanding.

PR Rollbacks have lower priority, and the volunteers are unable to control when or if browsers or other parties using the PSL will refresh or update.

(Link: about propagation/expectations)

• Yes, I understand. I could break my organization's website cookies and cause other issues, and the rollback timing is acceptable. Proceed anyways.

---

Description of Organization

Websites.co.in is a mobile-first website builder platform that allows individuals and businesses to create simple, functional websites without needing coding knowledge. The platform provisions and hosts user-generated sites, including assigning unique subdomains for each user.

Websites.co.in manages the com.free domain, which is used to generate user sites such as businessname.com.free.

Organization Website: : https://websites.co.in

Reason for PSL Inclusion

The com.free domain is operated by Websites.co.in to provision isolated website instances for users, with each user receiving a dedicated URL such as businessname.com.free. While Websites.co.in fully manages the subdomain creation and DNS configuration, each user independently controls the content, settings, and behavior of their own site. Because these sites are operated by different users, they must be treated as distinct origins to prevent unintended sharing of cookies or other browser storage.

Inclusion in the Public Suffix List ensures that browsers and security mechanisms correctly isolate user sites from one another. Without PSL listing, unrelated *.com.free sites may share cookies, authentication data, or session information, which could introduce privacy and cross-site security issues.

Number of users this request is being made to serve: Approximately 2.4 million sites currently hosted under com.free

DNS Verification

dig +short TXT _psl.com.free
"https://github.com/publicsuffix/list/pull/2678"

[fakeboboliu]

Approximately 2.4 million sites currently hosted under com.free

Consider Creation Date: 2025-06-07, that's insane, you've made a fantasy work.

But:

• Expiry Date: 2026-06-07, please maintain it >2yr.
• All the subdomains seems sharing the same IPs (from Cloudflare), are you hosting all the subdomains on your server and serving them through Cloudflare?

For more requirements, read the Guideline and please read the PR template again, with your mind.

[groundcat]

Approximately 2.4 million sites currently hosted under com.free

Consider Creation Date: 2025-06-07, that's insane, you've made a fantasy work.

But:

• Expiry Date: 2026-06-07, please maintain it >2yr.
• All the subdomains seems sharing the same IPs (from Cloudflare), are you hosting all the subdomains on your server and serving them through Cloudflare?

For more requirements, read the Guideline and please read the PR template again, with your mind.

@fakeboboliu There is really no need for this aggressiveness, condescension, and adopting a presumptive adversarial stance in your comments.

Just to clarify a few points: The PSL doesn't have requirements around creation dates, only that domains maintain sufficient registration time remaining. Also, the shared IP pattern is typical for SaaS platforms using CDNs - Cloudflare, Fastly, and similar providers commonly serve many subdomains from the same (set of) edge IPs.

[fakeboboliu]

Approximately 2.4 million sites currently hosted under com.free

Consider Creation Date: 2025-06-07, that's insane, you've made a fantasy work.
But:

• Expiry Date: 2026-06-07, please maintain it >2yr.
• All the subdomains seems sharing the same IPs (from Cloudflare), are you hosting all the subdomains on your server and serving them through Cloudflare?

For more requirements, read the Guideline and please read the PR template again, with your mind.

@fakeboboliu There is really no need for this aggressiveness, condescension, and adopting a presumptive adversarial stance in your comments.

Just to clarify a few points: The PSL doesn't have requirements around creation dates, only that domains maintain sufficient registration time remaining. Also, the shared IP pattern is typical for SaaS platforms using CDNs - Cloudflare, Fastly, and similar providers commonly serve many subdomains from the same (set of) edge IPs.

You are right, I apologize that my recent statements have been generally somewhat aggressive: perhaps I've consumed too few vitamin B6. (Or just too few sleep)

Regarding the creation time, I'm not being sarcastic (even if it might look like it), considering India's huge market and the free and ease-of-use nature of the product itself, this is indeed feasible, but if it can really be achieved, it can still be called a great achievement.

When I mentioned shared (static&controlled dynamic) hosting, I actually wanted to remind that other methods can be used to control cookies, but I forgot before replying.

Bringing the focus back to the service itself, I noticed the user numbers could be somewhat real. It appears they redirected every "websites.co.in" site to "com.free". And the "com.free" now appears in the "websites.co.in" sitemap. This indicates it's likely a full migration of the "websites.co.in" service, which happens to be an ancient zero code site builder in India.

[clou4843]

@fakeboboliu Sir, please mind your language. Your comment calling our fellows hard work a "fantasy" and describing our platform as "ancient" builder in India is deeply disrespectful and shows a very poor understanding of the vibrant digital ecosystem here. I have been using their platform for many years.

[fakeboboliu]

@fakeboboliu Sir, please mind your language. Your comment calling our fellows hard work a "fantasy" and describing our platform as "ancient" builder in India is deeply disrespectful and shows a very poor understanding of the vibrant digital ecosystem here. I have been using their platform for many years.

I believe I have already clarified what I meant by 'fantasy' in the comment where the word 'ancient' was used.

Regarding 'ancient,' I used it hyperbolically to describe something with a long history—specifically in the sense of 'having lasted for a very long time.' I hope this clears up the misunderstanding between us.

Beyond the semantics, I owe you and the PR submitter a sincere apology. When I noticed the account had only 'Joined 2 weeks ago,' and my preliminary checks (of com.free) on Google (no meaningful pages found rather than the site itself) and Similarweb (which showed data N/A) raised red flags, I rushed to judgment using an aggressive tone . I apologize for the aggressive tone of my previous response.

[simon-friedberger]

As @fakeboboliu was saying, if you are hosting the sites please enforce host-only cookies. This provides much better protection than the PSL.

[websitesDev]

Thanks everyone for taking the time to review and comment. Let me respond point by point to the issues raised so far.

1. Domain creation and expiry dates

The creation date reference in the PR was only meant to explain the migration timeline from *.websites.co.in to *.com.free, not to claim that all usage happened in a few months.

2. Subdomains sharing Cloudflare IPs

Yes, we are using Cloudflare as our CDN and edge network. This means all the *.com.free subdomains are handled from the same Cloudflare IP ranges, which is expected for a multi-tenant SaaS platform behind a CDN. Origin traffic is then routed and isolated at the application level on our side. So the shared IP pattern is a property of Cloudflare’s edge, not a sign that everything is being served as one flat site.

3. Host-only cookies and isolation model

Thanks @simon-friedberger for calling this out. We do already enforce host-only cookies and per-site storage boundaries for user sites we host. That is our primary isolation mechanism. The reason we are requesting PSL inclusion for com.free is to add a browser-level boundary on top of that, so that unrelated *.com.free tenants cannot accidentally share cookies or other storage if any integration or third-party script misbehaves. In other words, PSL is an extra safety layer, not a replacement for application-side isolation.

4. User count (~2.4M sites)

The “approximately 2.4 million sites” figure refers to the total number of Websites.co.in user sites provisioned over the years that have been mapped or migrated to *.com.free. It is a cumulative provisioned-sites number, not “2.4M new sites created since June 2025”. A large part of this base came from the legacy *.websites.co.in namespace being redirected into *.com.free, as some of you already noticed from the sitemap and redirects.

5. Abuse prevention and operational controls

Abuse handling is something we take seriously, especially at this scale. Our policy is publicly documented here: https://websites.co.in/abuse-policy

In practical terms:

• Every new site and content change passes automated checks before going live.
• We monitor for known patterns of spam, malware, and phishing across *.com.free.
• Each user-generated site exposes a “Report Website” form that feeds into a moderation queue.
• Reported or detected abuse is reviewed by our team and sites are limited, suspended, or removed in line with the policy and applicable law.

These controls are already active on the com.free namespace and will remain in place.

6. Tone and earlier misunderstandings

Thank you @fakeboboliu for your follow-up clarification and apology. That is appreciated. We understand that reviewers have to be skeptical and run quick reputation checks, and we value the guidance that came after the initial comments. Our intent with this PR is to align with the PSL guidelines and provide the right isolation semantics for a multi-tenant service, not to work around any third-party limitations.

[fakeboboliu]

Yes, we are using Cloudflare as our CDN and edge network. This means all the *.com.free subdomains are handled from the same Cloudflare IP ranges, which is expected for a multi-tenant SaaS platform behind a CDN.

My point is, given the current operation of your platform (managed site building system), you effectively have direct control and decision-making power over how all code and cookies are filtered and processed.
If the issue is limited to cookies, it would be better to implement filtering at your application gateway.

Solving this with the PSL comes with several side effects, such as issues with spam detection for root domain emails and delegated management. For example, your domain com.free would be treated as a root domain by Cloudflare, which might prevent it from being correctly added and managed as a standard zone.
If you can handle this internally, you would avoid these side effects while gaining greater flexibility.

[websitesDev]

1. On Internal Filtering vs. PSL Purpose
You are absolutely right that our platform gives us full control over execution. We already enforce strict internal policies: all user sites are rendered through a controlled environment, and no raw user scripts are allowed to run.
However, PSL is not being requested as a security filter. It is requested for browser-level cookie scoping.
Internal filtering cannot prevent a browser from treating *.com.free as a single origin. We need the PSL to ensure that siteA.com.free cannot read cookies set by siteB.com.free. This is a client-side boundary that server-side filtering cannot replicate.

2. On Operational Side Effects (Cloudflare/DNS)
We appreciate the warning regarding Cloudflare and root domain handling, but we have verified that these side effects do not impact our current architecture:

• We manage routing via a simple wildcard A record pointing to our infrastructure.
• We do not use delegated management or auto-detection features that would be broken by the PSL entry.

[groundcat]

• Expiration (Note: Must STAY >2y at all times)
  • com.free expires 2026-06-07
  • @websitesDev Action Required: Domain must be renewed to expire no earlier than December 2027 before this PR can proceed.
• Reasoning/Organization description
  • Organization website is functional and matches PR description
  • Use case (cookie isolation for multi-tenant SaaS) is valid for PSL inclusion
  • Claim of ~2.4M sites represents migration from *.websites.co.in to *.com.free
  • Not attempting to bypass third-party limits (explicitly confirmed in PR responses)
  • Note: User count is substantial and service appears legitimate despite recent domain registration (June 2025)
• Non-personal email address
  • Uses hi@com.free which is role-based
• Abuse contact

[groundcat]

@websitesDev I noticed that you are using hi@com.free as an email address.

Advisory for PSL Requestors with Email at Suffix Level:

If you operate email services at the suffix level (e.g., admin@yourregistry.tld rather than admin@example.yourregistry.tld), please note that this configuration violates RFC 7489 Section 3.2. Public suffixes cannot be "Organizational Domains" and therefore cannot properly support SPF, DKIM, or DMARC email authentication, critical security measures that protect against phishing and spoofing. While your suffix entry may still be accepted in the Public Suffix List, we strongly recommend migrating your email infrastructure to operate under a registered organizational domain (e.g., registry.yourregistry.tld) to ensure proper email authentication, maintain domain reputation, and avoid deliverability issues with major email providers who increasingly enforce DMARC policies.

[websitesDev]

• Expiration (Note: Must STAY >2y at all times)

  • com.free expires 2026-06-07
  • @websitesDev Action Required: Domain must be renewed to expire no earlier than December 2027 before this PR can proceed.

• Reasoning/Organization description

  • Organization website is functional and matches PR description
  • Use case (cookie isolation for multi-tenant SaaS) is valid for PSL inclusion
  • Claim of ~2.4M sites represents migration from *.websites.co.in to *.com.free
  • Not attempting to bypass third-party limits (explicitly confirmed in PR responses)
  • Note: User count is substantial and service appears legitimate despite recent domain registration (June 2025)

• Non-personal email address

  • Uses hi@com.free which is role-based

• Abuse contact

We would like to clarify that com.free is a premium, high-value domain unlike standard domains that can be renewed for $10–$15 per year. Because of this, we are unable to extend the renewal several years in advance at this moment.

That said, we want to reassure the team of our complete commitment to maintaining this domain long-term. Our business and more than 2.4 million active user websites rely on com.free, so ensuring uninterrupted renewal is critically important for us. We will continue to renew the domain year-by-year well before the expiration date, ensuring that validity is always maintained.

We hope this practical approach is acceptable, and we are happy to provide updated renewal confirmations as they occur.

[simon-friedberger]

The reason we require at least 2y of domain validity is to avoid a lot of requests from short-lived projects which cause a lot of churn. If your argument is that you don't want to renew the domain because it is too expensive that does not exactly inspire confidence. What does the renewal cost?

[groundcat]

Renewing com.free because it’s considered a “premium” domain seems to cost around $3,019 USD. However, I don’t think PSL should make an exception just because a domain is too expensive to renew. The only valid reason to exempt a suffix from the 2Y policy is when the g/ccTLD registry only allows a 1-year registration/renewal period.

If your company is already committed to using .com.free for the long term, it would be necessary to renew it at some point regardless, even if the renewal fees are high.

[hiifeng]

We would like to clarify that com.free is a premium, high-value domain unlike standard domains that can be renewed for $10–$15 per year. Because of this, we are unable to extend the renewal several years in advance at this moment.

I hope the explanation below is helpful.
The PSL guidelines do require that a domain always maintain at least a two-year registration period. In my view, the main reason for this rule is to prevent domains that are already included in the PSL from expiring and being resold. Since PSL updates and propagation can take a long time, this kind of situation could create unexpected issues for a new domain owner.

I also understand that com.free is a high-value domain with renewal costs that are significantly higher than those of typical domains, and that you intend to keep renewing it long-term. However, from the perspective of maintaining PSL stability and minimizing impact on end users, this requirement is still reasonable.

[websitesDev]

Thank you @simon-friedberger , @groundcat , and @hiifeng for the explanation. We appreciate the explanation regarding the 2-year validity requirement and its role in maintaining PSL stability.

To clarify the financial aspect: as @groundcat noted, the renewal fee is significant. To satisfy the PSL requirement (extending validity to ensure it remains >2 years at all times), we are looking at an immediate upfront investment of approximately $6,038 or $9,057.

We are prepared to make this investment to demonstrate our long-term commitment to com.free and the ecosystem. However, given the substantial amount involved, we strictly request confirmation that the domain expiration date is the only remaining blocker for this request.

If the maintainers can confirm that our application otherwise meets all checks (technical, validation, usage, etc.) and will be accepted upon proof of extended validity, we will proceed with the multi-year renewal immediately.

[simon-friedberger]

Otherwise it's fine except for some details:

1. Your email is on the public sufifx. This violates the DMARC spec. It shouldn't stop you from receiving our emails but we might not be able to get your response.
2. The entry is currently in the ICANN section but it belongs in the PRIVATE section.

[websitesDev]

Thank you for the clarifications.

We’ve now addressed the remaining points raised:
The entry has been moved from the ICANN section to the PRIVATE section.
The submitter contact email has been updated from the public suffix to an organizational subdomain (robinson@website.com.free).

From a process perspective, I’m a developer on the project, and proceeding with a multi-year renewal requires explicit management approval due to the significant upfront cost involved.
Before we move ahead with extending the domain validity to ensure it remains greater than two years at all times, we would appreciate explicit confirmation that the domain expiration date is the only remaining blocking concern for this PR.
The suffix is actively used in our platform, operated at https://com.free.

Once confirmed, we will proceed immediately with the renewal and provide proof of extended validity.
Thank you for your time and guidance.

[hiifeng]

I understand your question.

Based on the review so far, everything looks reasonable, and the domain expiration date is indeed a blocking issue at this point.

That said, as the Public Suffix List is a community-driven project, if other volunteers identify new substantive issues during further review, the PR could still be delayed or blocked until those are addressed.

In addition, I’d like to flag two newly identified concerns related to domain reputation and abuse signals, which will likely need to be investigated and resolved before this PR can move forward:

VirusTotal currently indicates that com.free is marked as Suspicious by Gridinsoft
https://www.virustotal.com/gui/domain/com.free?nocache=1

Spamhaus currently lists com.free on its blocklist
https://check.spamhaus.org/results?query=com.free