New interaction between IOS 14.5 PCM and Facebook Pixel causing increase in PSL inclusion requests
dnsguru opened this issue · comments
(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.
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.
-
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.
-
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.
-
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.
-
[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.
-
[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.
-
[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.
@sleevi doesn't Let's Encrypt have some form of request process for exceptions on their hard rule of PSL listing on a name limiting their subdomain quantity?
I am getting increasing and emboldened number of requests that are spilling out of band of github - and rather aggressive (like cel phone call yelling aggrssive) and somewhat visceral, because FB is dead-end referring to PSL entries as the solution, so folks are at their wits end.
Should we recommend to FB that they need some exception handling solution similar to what LE did, if it would work? They should be aware of exceptions as a responsible tech company, and be able to self-manage that process.
It is a regrettable situation, I have sympathy, but diminishing patience.
@sleevi doesn't Let's Encrypt have some form of request process for exceptions on their hard rule of PSL listing on a name limiting their subdomain quantity?
They do, see the Overrides section at https://letsencrypt.org/docs/rate-limits/#a-id-overrides-a-overrides
Should we recommend to FB that they need some exception handling solution similar to what LE did, if it would work? They should be aware of exceptions as a responsible tech company, and be able to self-manage that process.
It is totally reasonable that FB would maintain their own custom version of allowed list, based on whatever is their acceptance criteria.
Thanks @weppos - I keep saying FB but might perhaps mean to be saying Apple on this one. The FB Pixel thing is a symptom, and we may see others.
So, yeah, over the weekend someone reached out to me via the contact form on my personal blog, which had me concerned it was starting to escalate beyond the github issue or PRs... I am not a snowlake or anything but I got a rather ire call on my cel this morning 'who t.f. do you think you folks are to not allow us to fix this with an entry?!?' that I could have done without.
Hopefully that is not the start of a trend. Just concerned that it is going to escalate.
I've just replied on the privacy-cg thread here: privacycg/private-click-measurement#78 (comment)
The issue with maintaining our own allow list is that it doesn't provide the guarantees that the PSL does in terms of cookie separation (since that is enforced by the browser and not by us). We're happy to explore this issue as well as if there's a better way to manage this. In the short term, @dnsguru I've sent you an email to start a conversation
The issue with maintaining our own allow list is that it doesn't provide the guarantees that the PSL does in terms of cookie separation (since that is enforced by the browser and not by us).
As mentioned initially in this issue by @dnsguru:
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.
And as seemingly proved by @jonrburns as he mentioned in privacycg/private-click-measurement#78 (comment) and reported to WebKit in https://bugs.webkit.org/show_bug.cgi?id=224467 – that the version of the PSL on Apple devices lags behind the PSL repo.
This is to be expected I think. My perception is that the PSL from the very beginning as the Mozilla TLD List was about documenting an existing state of public suffixes, not about being an authoritative registry for creating new public suffixes. Hence there could be an expectation that the state of the data would be fairly static and not needed to be updated very often.
Regarding updates the Public Suffix pretty much only says that you can do so if you like:
If you wish to make your app download an updated list periodically, please use this URL and have your app download the list no more than once per day. (The list usually changes a few times per week; more frequent downloading is pointless and hammers our servers.)
And there are very much libraries and projects that comes with a built in copy of the database, like: https://github.com/rockdaboot/libpsl
So any change to the PSL will only eventually trickle down to more and more users of the PSL, but probably never reach all users of the PSL – especially as some users just use it to catch worldwide .co.uk style domains, not eg Shopify subdomains.
So any perception that the PSL is some evergreen resource when used in clients feels a bit misguided to me.
So: Facebook can’t maintain a list that lives in Apples code.
And: PSL can’t change a list that lives in Apples code.
But: Apple can pull changes from the PSL and ultimately it’s up to Apple when and how they do it (and my impression is that it on eg. iOS happens at an OS-level rather than a browser level, though that it can update itself independently of OS-updates).
All in all: If changes needs to propagate quickly to Apple software, then no one else than Apple can control that, so ideally Apple would then be the recipient of such submissions and then upstream or publish those submissions for a likely inclusion into the PSL. No?
This is to be expected I think. My perception is that the PSL from the very beginning as the Mozilla TLD List was about documenting an existing state of public suffixes, not about being an authoritative registry for creating new public suffixes. Hence there could be an expectation that the state of the data would be fairly static and not needed to be updated very often.
Just a note: there was a nuance to this that I wanted to make a clarification to, which I bolded and italicized, because it sometimes confuses people regarding 'creating new public suffixes'.
This does not mean someone can come in and add a blockchain or alt-root TLD to the PSL. I realize that is a little obtuse to the discussion at hand, but due to the type of calls I am now getting from security folk about the matter, I want all eyes that see this issue chain to understand that PSL complies with ICP-3 (one root) and the only exceptions are strings that have been vetted by the IETF through RFC process or via the Internet Architecture Board.
(Update April 26. 2021)
Our default action remains to close these pull requests as wontfix in order to allow Facebook to put in place whatever remedies or solutions that they develop, including walkthrough text.
The volunteers here have been patiently in discussion with Facebook to obtain some guidance to their customers so that they are not forcing the problem/solution (and visceral customer emotional engergy) onto the volunteers here of the PSL.
The latest guidance from FB clarifies the use of PSL
"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."
While requests are being closed that cite facebook workarounds, please be advised that there are people from Facebook that are reviewing closed PR, and on a case by case basis they may request a PR be re-opened after walking their client through the process of ensuring the request for PSL inclusion is being made in a manner that will not break something else.
So mentioning Facebook in your PR about cookie isolation is a wise path, vs leaving out that information.
Updated wiki - have not added FB furnished text yet.
Appropriate expectations on derivative propogation wiki page now includes some images that show the cascade timing and how getting a wrong first request would impact the requestor, and the PSL volunteers cannot control any of that.
#1322 was submitted with a link to Facebook's Domain Validation page, which seems to have yet to be updated to include
"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."
https://www.facebook.com/business/help/126789292407737?id=1205376682832142 < This is the up to date help centre article in relation to PSL. I'll ensure this other link gets updated too
OK @bedfordsean I had to brush the dust off my facebook account to get access to the form in question.
Here is the current wording of the intro:
Please complete this form if you wish to register a domain for the Public Suffix List. Please ensure you have read our guidance on Public Suffix List usage here: https://www.facebook.com/business/help/126789292407737?id=1205376682832142 Facebook will review your request, come back with any questions, and if agreed, will work with you and the Public Suffix List maintainers to recommend an addition to the Public Suffix List. Note that applications made separately via the Public Suffix List GitHub pull request flow will be rejected
Comment:
Can you change the intro?
I suggest:
Please note that the Public Suffix List (PSL) is a volunteer-maintained catalog resource that browsers and other systems opt to include some or all of at their own pace or manner. Inclusion in the PSL is intended to be modest and accurate in respect of the file size and volunteer maintaners time. They have no control over pacing or even if requested names once added will be accepted and included by browsers. Requests should also be carefully curarted to ensure they do not cause unexpected consequences to the domain name. By completing this form, as it helps us to aid you in determining appropriate candidate domain names for processing inclusion requests to the Public Suffix List as well as the approach and format of the request. Direct requests via the PSL Github made outside this form and process will likely be rejected and may cause unexpected outcomes that are not immediate to recover from.
Please ensure you have read our guidance on Public Suffix List usage here: https://www.facebook.com/business/help/126789292407737?id=1205376682832142
Facebook will review your request, come back with any questions, and if agreed it is appropriate to request, will work with you to review the domain(s) in question and submit it to the Public Suffix List maintainers to recommend an addition Pull Request with the required information and structure.
Here are the checkboxes that the submitter enters:
-
I confirm my business doesn’t require functionality on the domain that I want to register on the Public Suffix List
-
I confirm the subdomains of the domain I want to register on the Public Suffix List are fully separated from one another, and I need to prevent data sharing between them
-
I confirm each subdomain for the domain I am requesting addition for corresponds to a separate business
-
I confirm that I understand being added to the PSL is a semi-permanent action and cannot be easily reversed in short timeframes
-
I confirm that I understand that I will lose the ability to track cookies for the domain I want to register on the Public Suffix List
-
I confirm that I have not created a domain for addition to the PSL solely for Facebook advertising purposes for my own business
Can you add:
- The domain(s) being submitted shall have at least 2 years remaining in their registration term at the time they are submitted to the PSL.
Thanks @dnsguru will get this fed back and reviewed for any changes
On Facebook, the induction path form reads like this:
Please ensure you have read our guidance on Public Suffix List usage here: https://www.facebook.com/business/help/126789292407737?id=1205376682832142.
Facebook will review your request, come back with any questions, and if agreed, will work with you and the Public Suffix List maintainers to recommend an addition to the Public Suffix List. Note that applications made separately via the Public Suffix List GitHub pull request flow will be rejected.
The Public Suffix List or PSL is independently maintained by a group of volunteers and, as such, Facebook cannot control and offer or enforce commitments on turnaround time for PSL requests or inquiries, or which use cases get accepted to the PSL. There are no guarantees with respect to how long it will take to process the request, and there is no control over the timing of this change being updated downstream in browsers, libraries, certificate authorities or other systems or processes that incorporate the PSL.
OK there was a reduction in volunteer martyrdom, which is fine, but a very important and absent note is that companies seem to focus on their focus.... Just like many of the suggestions made on the text for the FB induction form were not included, the various downline projects and companies that voluntarily utilize the PSL catalog similarly will or won't include things, and of course do so at the pace they will, beyond the ability of the PSL volunteers to affect.
@n8schloss can you do triage on the PR that remain open and have the purple lable "IOS-FB?" on them?
@n8schloss can you do triage on the PR that remain open and have the purple lable "IOS-FB?" on them?
I just went through and commented on all the open PRs with that label. I think at this point all the open PRs with the label are still waiting on their authors to indicate if the request is related to FB advertising and iOS 14 or not.
Appreciate it @n8schloss and thank you for the updates.
I also have been googling IOS Facebook PSL to locate any sites or sources that are offering the less sophisticated guidance. Gratefully, I notice that you've beat me there on a lot of them. Thank you for that proactive reactive effort.
Add sevenfriday.com
Update 2021-09-20
The team at Facebook has put in place a review process which has been helping requestors unfamiliar with the PSL or the cookie impacts from self-nerfing their commerce websites, which has reduced the affected / effect impacts on the volunteer cycles for the PSL.
At the core of the issue remains a deliberate hack of a hack of a hack for the type of subdomaining capability to get some mildly restored ability to do user tracking for marketing systems, and the PSL was not built for this, nor is resourced for it. Most of the time, the affected registering and using a domain name or using a slightly upgraded tier of whatever service solves the problem.
Browsers and others who incorporate the PSL do so in an entirely voluntary manner, based upon an institutional resistence to things that attempt to work around limits designed into software for purpose.
The PSL plays a crucial role in something called 'Universal Acceptance' of TLDs, which has to do with ensuring that there is improved elegance in the handling of domains and administrative boundaries. Browsers opting out of continued use of the PSL will cause other fractions in how domains behave in software that will be bad for internet users.
Why is this bad for internet users? Witness the issue at hand of two different interests with two different standards and objectives. There are numerous other browsers and uses of the PSL - and as awful as a situation is that you have to come to the a free and open resource like the PSL and ask volunteer maintainers who are not resourced to handle your question, there exists at least that one place to un-monkey the change between A and F.
Should more the browsers opt-out or go their own direction on this, the z-axis of this problem likely expands with it.
Cutting to the chase, that's why there is resistance to these entries. These #1245 workaround requests, each and every single one of them that might be allowed in, are a nail in the coffin of the PSL and the future voluntary use of it by those down line.
Two PR related to working around the problem have been put through as a test. These have been well vetted by the team at FB.
These will be "reviewed" for their impact, and may be rolled back depending upon feedback from the parties involved. Others that have undergone the review and determination within the FB team shall sit in an indeterminate queue with the label "IOS PCM / FB AEM Victim Queue".
100% of PR that seek a workaround to the IOS/FB issue that have not undergone the 'should I do this' review with FB will be labelled wontfix and closed.
The conversations and progress forward will be on a best available effort pace from the volunteers here.
- There is no service level on this.
- There is no intended service level on these.
- Facebook has an intake process for the affected, and has updated their customer reviews with their customer affected by the PCM change in IoS related to some of the tracking stuff.
- There is not any turn-around or estimates.
We volunteers are doing our best to address this and while there is empathy for the affected, one has to consider the bigger picture and the jeopardy that gets introduced with each request and how it could adversely impact everyone.
If this is unsatisfactory, or one is seeking to expedite a solution, we encourage you to find solutions within your own systems or technology and reduce your reliance on cookies for the purposes envisioned.
If there is a need to vent or otherwise have a desire to express your feels - please direct that discussion to Apple or Facebook.
Update 2021-11-29 : Have not had feedback from Facebook or PR submitters related to last few 'trial baloon' merges, so it seems a good opportunity to do another trial group of the PRs in the queue.
Propose a review and process of 3 more 'testbed' submissions from the queue :
#1405 #1420 #1462
Assuming there are no comments in opposition to processing these three, and they are complete and conforming requests that validate in DNS and registration term, sorting, etc, I will merge them at the end of the week, on or about December 3, 2021.
Feedback has been positive from the existing trial balloons. I'm going through and confirming on the three you've proposed to merge in. Just #1462 to confirm on now.
As I noted previously, we're still working on another solution for this issue that does not require the PSL so I'm hopeful that many of these won't be needed in the near future and we can draw an even clearer line. I expect that line will mostly be philosophical/principled about the types of use cases that may need to be on the PSL for visibility reasons rather than technical ones.
UPDATE October 5, 2022... We're going to review the remaining 'Victim Queue' PR and process the ones that can be processed. In coordination with the team at Meta, their own solution has been put in place, and they have revised their documentation to not refer the affected to the PSL for solutions.
Our thanks to Meta on stepping up and fielding the associated pull requests to help out with narrowing the volunteer cycle impacts from this change.
Ongoing assistance in fielding Pull Requests is appreciated by the volunteers here maintaining the PSL.
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.