Seems like the right move from a volunteer run project, what will the future will hold though? Artificial scarcity is always a problem. On another note, for just 20k$ I can offer you exclusive use of the xxgfzrf.dinglebop.me Public Suffix so that you can keep tracking your users. Please reach out to sales@example.com if you are interested.
iOS 14 and Facebook Pixel causing increase in PSL inclusion requests
21–30 of 111 posts
Re: iOS 14 and Facebook Pixel causing increase in PSL inclusion requests
#22Can someone provide more context here? How does being added to the PSL affect tracking? Why are businesses adding themselves to the PSL en masse?
Re: iOS 14 and Facebook Pixel causing increase in PSL inclusion requests
#23Summary: Apple introduced PCM [1], and to keep people from using it for cross-site tracking it limits the bits available to a single site (as defined by the PSL). If shop-a.retail.example and shop-b.retail.example are completely separate, and don't want to compete for bits, Apple will still treat them as a single site unless retail.example is on the PSL. Being on the PSL is a big change (partitioned cookies, etc) but…
1. Multi-tenant domains that probably should've always been in the PSL (ex. to provide cookie silos) but are only realizing now that they should be in it due to the arrival of PCM.
2. Sites that want to abuse an eTLD to do something like give all users on their social network a custom subdomain so that they're not polluting the same pool.
--
I think it was actually reasonable for Apple to consider the PSL as it's basically the most comprehensive eTLD list that we have and would allow them to match browser behavior.
The problem now is that case (1) is sending a bunch of requests at once as something will now actually break for these sites. Before now it was really just them being lax with security and not considering that cookies should be siloed. This isn't a unique situation btw, PSL also saw a large increase in inclusion requests when LetsEncrypt added rate limits based on eTLDs.
(2) is obviously bad and there's really no other justification for these sites being in the PSL.
Therefore I think it's reasonable for PSL to deny inclusion requests that are solely for PCM reasons.
This all being said, the PSL is a massive hack [1] and really needs to be replaced by something else. It probably is about time for these companies to invest in a replacement.
Re: iOS 14 and Facebook Pixel causing increase in PSL inclusion requests
#24Can someone provide more context here? How does being added to the PSL affect tracking? Why are businesses adding themselves to the PSL en masse?
PSL is used to determine the level that a unique domain is registered at. This restricts cookies and privileges to that domain. It’s just a simple list because both .com and .co.uk are valid suffixes. Ios14 is using this list to prevent apps from tracking you across sites by limiting the data that can be stored per site. If you can get your domain recognized as a suffix as mysite.com then you can split information be…
Re: iOS 14 and Facebook Pixel causing increase in PSL inclusion requests
#25Seems like the right move from a volunteer run project, what will the future will hold though? Artificial scarcity is always a problem. On another note, for just 20k$ I can offer you exclusive use of the xxgfzrf.dinglebop.me Public Suffix so that you can keep tracking your users. Please reach out to sales@example.com if you are interested.
Re: iOS 14 and Facebook Pixel causing increase in PSL inclusion requests
#26> 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 Gi…
Apple is the company that declared this the canonical Public Suffix List. Facebook is just directing their customers towards it. "If you need to be considered a public suffix for Apple's new policy, you'll need to send your pull request to this repo."
Re: iOS 14 and Facebook Pixel causing increase in PSL inclusion requests
#27Re: iOS 14 and Facebook Pixel causing increase in PSL inclusion requests
#28Summary: Apple introduced PCM [1], and to keep people from using it for cross-site tracking it limits the bits available to a single site (as defined by the PSL). If shop-a.retail.example and shop-b.retail.example are completely separate, and don't want to compete for bits, Apple will still treat them as a single site unless retail.example is on the PSL. Being on the PSL is a big change (partitioned cookies, etc) but…
It sounds like there's two cases: 1. Multi-tenant domains that probably should've always been in the PSL (ex. to provide cookie silos) but are only realizing now that they should be in it due to the arrival of PCM. 2. Sites that want to abuse an eTLD to do something like give all users on their social network a custom subdomain so that they're not polluting the same pool. -- I think it was actually reasonable for App…
Can anyone explain why something like this wasn't implemented in the first place via DNS TXT records or tied to SSL somehow?
Re: iOS 14 and Facebook Pixel causing increase in PSL inclusion requests
#29> 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 Gi…
Apple is the company that declared this the canonical Public Suffix List. Facebook is just directing their customers towards it. "If you need to be considered a public suffix for Apple's new policy, you'll need to send your pull request to this repo."
Re: iOS 14 and Facebook Pixel causing increase in PSL inclusion requests
#30Earlier quoted context omitted.
It sounds like there's two cases: 1. Multi-tenant domains that probably should've always been in the PSL (ex. to provide cookie silos) but are only realizing now that they should be in it due to the arrival of PCM. 2. Sites that want to abuse an eTLD to do something like give all users on their social network a custom subdomain so that they're not polluting the same pool. -- I think it was actually reasonable for App…
Nice link to the GitHub issue which explains the problems clearly. Can anyone explain why something like this wasn't implemented in the first place via DNS TXT records or tied to SSL somehow?