Similar to other third party systems (CA's, Cloudflare, etc) using PSL as a ETLD+1 quality sieve, Facebook / Apple interaction between iOS 14 and the Facebook Business Pixel tracker for hosted names has introduced a new interdependancy.
We are seeing an increased number of PSL requests due to a new way Apple iOS 14 changes stuff with Facebook Pixels.
Upon some research, I found the following in the FB for business Pixel documentation.
From "How Apple’s iOS 14 Release May Affect Your Ads and Reporting"
If you plan to deliver ads optimized for conversion events that occur on your business’s website:
You may need to verify your website’s domain to help avoid any future disruption of your website campaigns. Domain verification must be done for the effective top level domain plus one (eTLD+1). For example, for www.books.jasper.co.uk, books.jasper.co.uk and jasper.co.uk the eTLD+1 domain is jasper.co.uk.
Additionally, we will support domains included in the Public Suffix List. This would enable businesses to verify their eTLD+1 domains if the hosting domain (eTLD) is registered in the Public Suffix List. For example, if ‘myplatform.com’ is a registered domain to the Public Suffix List, then an advertiser ‘jasper’ with the subdomain ‘jasper.myplatform.com’ would be able to verify ‘jasper.myplatform.com.’
Domain verification should be prioritized for domains with pixels used by multiple businesses or personal ad accounts. This will enable you to configure pixel conversion events when Aggregated Event Measurement becomes available.
I am going to reference this issue in PR that cite FB Pixel to track this and save our volunteers some time on repeating themselves about
The primary things that should be noted are:
- PSL inclusion is not intended to be used as a workaround for ANY security measures or increased user experience / protections that individual providers should / might be doing.
- PSL is maintained by volunteers and there should be zero expectation of turnaround times on PR (and a respect for the labor burden shifted onto them by orgs using PSL as a bozofilter)
- Getting an entry in the PSL does not in any way guarantee or oblige any action by parties who are using it or including it, nor the timing of when they might.
This was linked to pull requestsMar 24, 2021
This was linked to pull requestsMar 30, 2021
This project is receiving increasing volume of requests to add or update entries to create a workaround to the interop issue with Facebook Pixel and IOS14.
The primary issue is security, but resourcing is also a factor.
Rather than continue to process PR that Facebook is directing folks to submit PR entries to PSL as remedy, we will immediately close tickets submitted citing FB / IOS14 fix as "wontfix"
It is inappropriate for presence or absense in PSL to be used by Facebook as a means to include or reject entries due to the IOS14 change, as PSL is not any form of security screen whatsoever, and the volunteer team maintaining the PSL is receiving the burden of being a sieve for the changes on interaction between those systems, which is taxing our resources.
The ONLY validation performed by PSL volunteers and Github process to add listing in the PSL is to check that a DNS entry is added by the domain administrator that can be tied to, and this can be completely illusory and lite in reality in contrast to perhaps the deisred level of security that had been intended between Facebook Pixel and Apple.
We are freezing the approval of new submissions that cite the FB / IOS 14 interop issue in order to provide Facebook or Apple, with a much more robust set of resources, the opportunity to sort this out amongst/betwixt themselves.
This was referencedApr 1, 2021