New interaction between IOS 14.5 PCM and Facebook Pixel causing increase in PSL inclusion requests

[dnsguru]

(Day 60+ Update, Added June 4, 2021)

TL;DR: Here to fix an issue w Facebook Pixel? Click here for their guidance.

Facebook has updated their support info to route people to this page with more info for their Facebook Pixel customers and issue with PCM since IOS 14.5, This includes a form to aid in determining if it is appropriate to make a request to the PSL.

We have added to our PR form here some additional acceptance elements, and want to caution requestors that rollbacks have delays in downstream PSL integrators that are beyond the control of the project volunteers here to do anything about. Additionally, new requests for additions are prioritized ahead of rollback requests.

Most of the time it is not appropriate to request a PSL entry to fix the Pixel issue and people have been nerfing their primary URL in the process of making minimal-effort cut-paste type requests, so this updated guidance and intake form will hopefully cut down the time wasted for all involved.

==============

(Original issue, Opened March 24, 2021)

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"
https://www.facebook.com/business/help/331612538028890?id=428636648170202

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.

[dnsguru]

Tracking trend in submissions - re-opening

[dnsguru]

Update:

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.

[dnsguru]

Appreciate that this has some eyes on it within webkit privacycg/private-click-measurement#78 , as the net result of this issue and our rejection policy is that folks may have just opted to re-submit without mention of FB reference.

When other projects, services, companies, etc. direct folks that PSL inclusion (or lack thereof) is a gating factor on how their stuff will work, it has some consequences for the PSL team and it may not be an appropriate way to decline things cleanly before punting the customer elsewhere.

The primary concerns from PSL maintainers on having other projects identify PSL as means of addressing their issue is that this is not a scalable or appropriate solution.

1. Security or Vetting is illusory on this with respect to names in the PSL Private Section - it is a matter of submitting a PR with a competent rationale, and then verifying administrative authority by adding a _PSL txt record into the affected zone(s), and those matching.

2. We're mindful of file size bloat - the PSL is a static file, growing in size. It is really widely used and incorporated, downloaded hundreds of millions of times. File size modesty is important. Also, submitters tend to set and forget their entries once established.

3. PSL is maintained by volunteers. While it is an honor to contribute time towards the interoperability benefits that the PSL provides, it is unpleasant to get that donation taken advantage of. The concern of resource cycles is less a factor than the previous, but it is worth counting. We are hoping to not drown in the additional requests, especially those which could have been avoided with different implementation, customer service flows or FAQ at the referring origin.

4. [Updated April 23, 2021] A large number of requests are coming in for services that subdomain from their primary domain name, and their requests would potentially break the primary URL cookie or other functionality, so requests are even more time consuming than typical requests.

5. [Updated April 23, 2021] Listing into the PSL does not obligate updates within downstream systems that incorporate or use it - some browsers take a snapshot from time to time and release it with updates at their own cadence, so there is a time-delay that the volunteers here at PSL do not have ANY control over.

6. [Updated April 23, 2021] 4 and 5 together can create a very large problem for a requesor. Should a requestor's PR get approved with a change that could inadvertently break their core domain, which they would not detect until too late, and that breakage would remain until browser/os refreshed in a later system update.