remove secaas.hk

[wdhdev]

Domain was added in #1138, in 2020, however the registration date for the domain is 07-05-2024, it is clear it is no longer controlled by the original registrant and should be removed.

The current registrant is shown to be YMHC CHARITABLE FOUNDATION, which is a completely different organisation. This domain should be safe to remove.

[groundcat]

Hey, this is actually me :) A few months ago, I noticed this domain had expired (after being re-registered by someone who got it after the original requestor let it expire, and then it was expired again). I tried to register it myself, but I do not think the registration went through due to registry WHOIS contact issues.

My purpose was to test cookie separation behavior - specifically to understand how cookie settings work between subdomains (for example, whether setting cookies on foo.example.com affects example.com cookies). However, I have not had the chance to revisit this attempt.

I can check with the registrar about the domain's status and see if I can regain DNS control. Once I complete the testing, I will submit a pull request to remove it!

[wdhdev]

Hmm, would it be worth moving this to a new block, so people don't get the false assumption that Hong Kong Productivity Council is still operating the domain, even if it is a for a short while?

[groundcat]

I just checked my registrar account and the registration was successful, but the nameservers were still set to the old ones. I have updated the Nameservers and should have DNS control shortly to do testing. Now that I have control of the domain, I will update the contact information in the block to avoid any confusion.

In the meantime, if any maintainers or volunteers are interested in conducting any sort of testing during this period - whether it is browser behavior testing or other test cases - please reach out and I can modify the DNS settings for you. For example, to test the scenario in #2241 @simon-friedberger

[wdhdev]

Ignore my last comment, I completely forgot I could just delegate myself subdomains on one of my domains already listed on the PSL 🤣

[groundcat]

No problem! I just sent you an email with the information. I was thinking that instead of using a newly added PSL entry, which would require a long propagation period (over 90 days) across multiple applications, it would be better to use an existing entry that has been in the PSL for years. This would probably produce more representative test results.

[wdhdev]

I've got around ~10 entries on the PSL, some of which were added early 2024, some added late 2024, however most places that actively use the PSL have updated at least to include the early 2024 entries. Recently, I managed to get Cloudflare to update their copy of the PSL, as it was out of date by multiple months, which was helpful, especially considering we have been removing a lot of debris from the PSL.

[wdhdev]

I've just replied to your email as well regarding the DNS of the domain.

[wdhdev]

I'll leave this in draft until we are ready to remove this domain.

[groundcat]

@wdhdev I have just set up a cookie tester at https://secaas.hk to test cookie behavior in Firefox and Chromium,

Feel free to experiment with it - you can switch between subdomains and third-level domains using the top bar.

Observations:

1. As Simon mentioned in Cookie documentation #2241, we can indeed set cookies on a public suffix. The claim that cookies cannot be set on public suffixes is not true.
2. As expected, subdomain1.secaas.hk and subdomain2.secaas.hk cannot set cookies on each other.
3. subdomain1.secaas.hk can set cookies on sub.subdomain1.secaas.hk; but sub.subdomain1.secaas.hk cannot set cookies on subdomain1.secaas.hk
4. As expected, subdomain1.secaas.hk and secaas.hk cannot set cookies on each other.

The documentation's current wording suggests that the PSL prevents cookie-setting entirely on public suffixes, when in reality it only prevents cookie sharing/inheritance between separate registrable domains under that public suffix. This is an important distinction that the documentation fails to make clear. A more accurate description would explain that the PSL helps prevent cookies set on one domain from being accessible to other domains under the same public suffix.

---

Anyways, this domain secaas.hk can be removed from the PSL now!

$ dig +short TXT _psl.secaas.hk
 "https://github.com/publicsuffix/list/pull/2335" 

[wdhdev]

sub.subdomain2.secaas.hk cannot seem to set cookies for subdomain2.secaas.hk, however subdomain2.secaas.hk can set cookies for sub.subdomain2.secaas.hk. I'm using Chrome mobile.

[groundcat]

sub.subdomain2.secaas.hk cannot seem to set cookies for subdomain2.secaas.hk, however subdomain2.secaas.hk can set cookies for sub.subdomain2.secaas.hk. I'm using Chrome mobile.

You are right! Just fixed the comments above.

[wdhdev]

@groundcat Nameservers for Cloudflare are:

• coco.ns.cloudflare.com
• javier.ns.cloudflare.com

Cloudflare support took a little while to add the zone because they needed to confirm some stuff.

However as the domain's already been removed from the PSL do we still need Cloudflare? If not I'll just delete the zone.