Add Sika.com to public_suffix_list.dat

[acidcooler]

• Description of Organization

• Reason for PSL Inclusion

• DNS verification via dig

• Run Syntax Checker (make test)

• Each domain listed in the PRIVATE section has and shall maintain at least two years remaining on registration.

Description of Organization

Organization Website: https://www.sika.com

Sika is a specialty chemicals company with a leading position in the development and production of systems and products for bonding, sealing, damping, reinforcing and protecting in the building sector and motor vehicle industry. Sika has subsidiaries in 100 countries around the world and manufactures in over 300 factories. Its 25,000 employees generated annual sales of CHF 7.88 billion in 2020. At the end of 2019, Sika won the Swiss Technology Award for an innovative new adhesive technology.

Reason for PSL Inclusion

• Cookie Security
• Subdomain registration on Facebook.

"To that end, businesses that host their websites on platforms that have already registered their domain in the Public Suffix List can now verify associated subdomains for the purpose of event configuration. For example, a business that hosts their website on jasper.myplatform.com will now be able to verify this domain and configure their top 8 events for use in conversion optimization and will no longer be required to host their domain separately or transition to link click or landing page view optimization.

Additionally, multi-national or regional businesses that have already registered their domain (for example, jaspersmarket.com) in the Public Suffix List can now verify the subdomains (for example, uk.jaspersmarket.com and us.jaspersmarket.com) and configure their top 8 events for use in conversion optimization."

DNS Verification via dig

dig +short TXT _psl.sika.com
"https://github.com/publicsuffix/list/pull/1294"

make test

make test - Done - All PASS, no Errors.

Extra info

sika.com domain is auto extended on a yearly basis, with no end date applied, therefore, it doesn't show a remaining expiring date bigger than 2 years. This is maintained by sika registrar supplier CSC.

Domain status: ACT
Registration date:
Registration Expiry Date:29-Jul-2021
Paid Until Date:31-Dec-2999

[dnsguru]

Please see #1245

[bedfordsean]

Hi @acidcooler,

The Facebook help center guidance was updated a week ago: https://www.facebook.com/business/help/331612538028890?id=428636648170202

In the reasoning you paste above, there is one important call out:

To that end, businesses that host their websites on platforms that have already registered their domain in the Public Suffix List

The relevant snippet from the new, clarified documentation is this:

Our current efforts are designed to support clients with pre-existing Public Suffix List domain registrations or eTLDs. This support is in line with Apple's recent private click measurement update. There are other technical implications if a domain is registered as a Public Suffix that a business should consider (for example, the domain that is registered on the Public Suffix List cannot have its own cookies) and as such, we do not recommend that clients register their domains on the Public Suffix List specifically for Facebook event configuration.

In this particular scenario. why is Sika (a multibillion CHF company) not able to own and run individual domains per subsidiary?

[acidcooler]

Hi @bedfordsean

As a multibillion CHF company present in more than 100 subsidiaries, we have too many local entities try to define up to 8 Facebook/pixel custom conversion events per subdomain, which facebook requires TXT validations on our parent sika.com subdomain. This would require almost a thousand TXT records to make such verifications, and the local entities have no privilege to manage this on the DNS level. Therefore, for such a large company, it seems to be recommended to add the parent domain "sika.com" to PSL.

Besides, we also have an additional requirement for cookie security, which is not related to the IOS 14 upgrade, but instead to isolate our public subdomains vulnerable to CSRF, as we run web subdomain pages (i.e https://fra.sika.com, aus.sika.com, etc) per each subsidiary country.

Best regards,
Sergio Fernandes

[bedfordsean]

Thanks @acidcooler for the clarification.

Our primary intended use case for PSL additions (if at all as per our clarified guidance) is for large platforms that host on behalf of other businesses to provide a transition path to allow those individual, discrete, separate business entities to continue to advertise.

In this case here it seems to me like Sika is a multinational that just happens to have their geographical subsidiaries hosted underneath one eTLD+1 rather than using the existing country TLDs (e.g. https://sika.fr instead of https://fra.sika.com).

You could achieve this same cookie security separation by using country TLDs as designed (and supported in every major browser). I understand this is probably not the most straightforward switch, but it would remove your reliance on the PSL.

Note that browsers do not update the PSL on any sort of regular cadence and you won't actually get cookie assurances until those browsers do update their lists.

[acidcooler]

Hi @bedfordsean

Yes, Sika strategy changed in the last few years. Before we used to have country TLDs for all our subsidiary business, but due to the additional efforts of maintaining more than 500 TLDs and Security certificates, it was decided to move into an eTLD+1 approach. Therefore you can still find TLDs like http://sika.fr which are just a forward to https://fra.sika.com, but we are not going back to TLDs for each subsidiary country again.

As for the browser's PSL update, we do understand this unregular cadence.

Best regards,
Sergio Fernandes

[bedfordsean]

Clear. Thanks @acidcooler!

@dnsguru over to you to determine how to proceed here. From the above conversation the primary motivation for this appears to be cookie segregation, which would have been an issue irrespective of any iOS/Facebook related activities

[dnsguru]

This sounds like the request is exectly seeking to do what we decline in the case of Let's Encrypt limits, only for Facebook instead. Am I reading this wrong?

[acidcooler]

Hi @dnsguru

I would rather prefer to focus on the Cookie Security request, in order to isolate our public subdomains vulnerable to CSRF, as we run web subdomain pages (i.e https://fra.sika.com, aus.sika.com, etc) per each subsidiary country.

Best regards,
Sergio Fernandes

[sleevi]

Given both the content and that these subdomains are, in fact, the same entity, I’m concerned this is an attempt to try to bypass the prohibition. On the one hand, kudos for trying, but on the other hand, no concrete examples have been given, and these are subdomains are all operated by the same (collective) legal entity.

The risk we’re asked to believe is relevant here is the French subsidiary attacking the American subsidiary, even as the websites themselves appear otherwise identical and likely the result of a CMS managed by a single entity.

Perhaps you can be clearer on the purpose, both with examples and with an explanation of the threat model? Although I’d also support WontFix if @dnsguru is so inclined, just as we have done for those with LE rate limits.

[sleevi]

Actually, given autorenewed is not compliant with the policies, not the same, and not something we can verify, I’m going ahead and closing as WontFix for now.

[benjaminsavage]

Therefore, for such a large company, it seems to be recommended to add the parent domain "sika.com" to PSL.

I agree with @sleevi that this is not an appropriate use of the PSL. A large company should not be adding itself to the PSL simply because it has multiple subsidiaries.

Given both the content and that these subdomains are, in fact, the same entity, I’m concerned this is an attempt to try to bypass the prohibition.

I agree. This is all the same entity. The limitations on ad measurement are definitely regrettable, but these restrictions all derive ultimately from Apple's decision to limit the amount of entropy in PCM reports to 4 bits of "trigger_data" on websites. Apple is giving each business this entropy budget to decide for themselves how to spend. They are not making exceptions for large, multi-national companies, giving them more because they are comprised of multiple subsidiaries.

I empathize with your plight, and I'm trying to propose alternative privacy-proposing alternatives to Apple through the W3C, but at this time this is the limitation.