Tracking trend in submissions - re-opening

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.

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.

Late last year, Meta updated our tooling to alter how we detect and manage subdomains for advertising, which negated any value that being on the Public Suffix List brought for that scenario. As such, Meta should not be considered as a valid reason to pursue PSL addition, and we do not recommend this course of action.There may be other reasons, however, such as assuring cookie separation, which we will leave to the discretion of the applicants and PSL volunteers to manage.

Meta’s updated guidance around Aggregated Events Measurement can be found here: https://www.facebook.com/business/help/721422165168355?id=1877298665783613

@dnsguru @simon-friedberger @weppos please note that I will still keep an eye on PSL pull requests and confirm the above, however feel completely free to outright refuse requests that do not follow your other guidelines already in place.