[HN Gopher] iOS 14 and Facebook Pixel causing increase in PSL in...
___________________________________________________________________
iOS 14 and Facebook Pixel causing increase in PSL inclusion
requests
Author : CameronBanga
Score : 210 points
Date : 2021-04-07 15:54 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| lmb wrote:
| 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.
| devrand wrote:
| To make things worse, it's basically impossible to remove a
| domain from the PSL as no one knows how software built against
| the PSL would handle it. A removal could break tremendous
| amount of software that people rely on.
| dialtone wrote:
| It's interesting because being added to the PSL reduces your
| ability to track users. So yeah, I have a bridge to sell you,
| interested?
| djrogers wrote:
| > being added to the PSL reduces your ability to track users
|
| Not really, in fact it can increase your ability to track
| users if it's (ab)used in specific ways - see use case #2 and
| #3 here:
|
| https://github.com/privacycg/private-click-
| measurement/issue...
| dialtone wrote:
| There's an approval process to be added to the PSL so
| abuses would be quite surprising and easy to remove when
| discovered.
| iudqnolq wrote:
| This entire discussion is literally about how that's not
| the case.
| irrational wrote:
| >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)
|
| What is to stop Facebook from assigning an engineering team to
| act as volunteers so the turnaround time drops to zero?
| seoaeu wrote:
| Um, because those engineers don't have commit access to the
| repository? You can't just hire an engineering team and take
| over any open source project you want.
| irrational wrote:
| Oh, I was assuming the engineering team would lie a pretend
| like they did not work for Facebook. I assumed they would
| slowly work to gain the confidence of those in control and
| little by little they gain the access they required
| themselves. Maybe they could pretend not to know each other
| and use that to their advantage. Surely a company with the
| resources of Facebook could manufacture fake alternate lives
| for the engineering team to make them look completely
| legitimate and harmless.
| kogir wrote:
| Isn't the easiest solution here for companies to register their
| own domain? Why be company.service.tld and not just company.tld?
| What are these businesses doing for email?
| mrweasel wrote:
| In this case I think the issue is trackers. If you owned a
| retargeting or tracking service, you might have
| customer1.retargetting.com and customer2.retargetting.com.
| Apple will now see these as being the same site, unless
| individually registered in PSL. This limits the amount of data
| that can be aggregated by retargetting.com, unless each
| subdomain is added to PSL.
| donmcronald wrote:
| Yes, it is. The main reason I can think of for using subdomains
| would be for super low value content that isn't worth $10-30 /
| year for a real domain.
|
| There could also be a setup / maintenance angle I guess.
| Specifying a big list of custom domains is more work than
| *.example.com.
| mangosquash wrote:
| I work on digital advertising for a franchise where each
| individual store manages their own shopify site at
| location.franchise.com. Soon, these sites won't be able to
| run ads that track purchases, unless franchise.com is added
| to this list.
|
| I understand the PSL managers' position that this is an
| unfair burden to place on them though.
| local_dev wrote:
| >these sites won't be able to run ads that track purchases
|
| Isn't that part of the purpose of the changes that Apple is
| making? As a user, this seems like a great change. Less
| tracking is a positive.
| fshbbdssbbgdd wrote:
| In principle, you can know that an ad click resulted in a
| purchase without knowing who clicked the ad and who made
| the purchase. Apple supports these kinds of measurements
| for its own Apple Search Ads product.
|
| The "entropy limit" you see people talking about
| elsewhere in the thread is one means that attempts to
| allow ads to be measured like this without revealing
| information about the users. But if every store
| *.shopify.com is in the same entropy pool, there won't
| even be enough information to tell which ad campaign led
| to a sale on which store.
| mangosquash wrote:
| Apple is doing some cool things to make personally
| identifiable tracking from Facebook ads much less
| pervasive, while still providing advertisers/businesses
| data about whether or not their ads are working. These
| things include sending batches of data every 36-48 hours
| instead of data as it happens, etc. But in order for
| these tools to work, Apple is asking Facebook to rely on
| this list to see if subdomains would be able to set up
| conversion events to collect this anonymized batched
| data.
|
| This system will make ads worse, but I think it's an
| alright balance. Not being able to have any conversion
| tracking will make ads dismal.
|
| I wish that Apple would work to maintain their own list
| that served this purpose, or provided support to the
| volunteers that were tasked with keeping this updated.
| donmcronald wrote:
| Yeah, but if they're talking about physical location
| franchises individually owned by local residents (there
| are a lot), the tracking they want to do probably isn't
| nearly as pervasive as Facebook as a whole.
|
| For example, each location might want to track the
| effectiveness of ads for their locality. Facebook is
| probably a decent place for them to run ads too.
|
| The big problem is that Facebook has earned a reputation
| of abusing all the data they collect, so most people are
| going to say the same thing as you and not have any
| sympathy, but it probably screws over the poster you're
| replying to pretty bad.
| donmcronald wrote:
| Yeah, I didn't quite understand it correctly at first.
| That's a really good example of a legit use case that's
| collateral damage from Apple vs Facebook.
|
| I can think of other issues now too. For example, I think
| government services should be structured as subdomains
| instead of each department registering a separate domain.
| This will encourage the use of separate domains if they
| need to track effectiveness and that's bad IMO. We don't
| want to normalize stuff like irsonline.com because of the
| boost it gives phishing.
|
| There's definitely two sides to this one.
| jefftk wrote:
| Summary: 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 could be appropriate for
| different shops.
|
| FB issued guidance suggesting domains like retail.example
| consider getting themselves added to the PSL, and now the PSL (a
| volunteer project) is getting a lot of requests. The PSL project
| has put these requests on hold, and asked FB and Apple to work
| this out. FB is talking to Apple in
| https://github.com/privacycg/private-click-measurement/issue...
|
| [1] https://webkit.org/blog/11529/introducing-private-click-
| meas...
| devrand wrote:
| 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 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.
|
| [1]: https://github.com/sleevi/psl-problems
| TechBro8615 wrote:
| 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?
| [deleted]
| ghughes wrote:
| That thread between FB & Apple is fascinating. The potential
| solutions being discussed have significant implications:
|
| 1. Apple: "not support eTLDs in PCM and only support TLDs" - so
| no more ad attribution for multi-tenant domains.
|
| 2. Facebook: "some sort of vetting process to determine who is
| using subdomains in a way that is aligned with the intended
| purpose of the PSL" - so Apple takes over the PSL inclusion
| process and institutes strict vetting to prevent abuse of PCM,
| which would presumably take months to implement.
|
| This looks like a serious design problem with no solution that
| could be implemented before ATT drops.
| donmcronald wrote:
| The biggest problem is that no matter what "scale" of
| tracking is tolerable on a single domain / subdomain,
| Facebook still gets the aggregate.
|
| So if you fix it for small multi-tenant domains, nothing
| changes for Facebook and they still get all the aggregate
| data, right?
|
| There's going to be a lot of collateral damage before ads and
| tracking get fixed IMO.
| cma wrote:
| ATT?
| Zelphyr wrote:
| App Tracking Transparency
| tony101 wrote:
| https://developer.apple.com/documentation/apptrackingtransp
| a...
| nsxwolf wrote:
| Paid Sick Leave?
| kapp_in_life wrote:
| Public Suffix List. It's in the link.
| foolproofplan wrote:
| Pumpkin Spice Latte
| fotta wrote:
| > 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.
|
| https://github.com/publicsuffix/list/issues/1245#issuecommen...
|
| ~~Seems like FB was abusing the work of volunteers here as a
| reaction to changes in iOS 14.~~ I don't see why they can't run
| their own PSL a la NTP servers.
|
| edit: Seems like Apple was the one to declare PSL as canonical.
| marketingtech wrote:
| 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."
| HappyTypist wrote:
| Apple should be officially supporting this project and turn
| it into an independent, but full-time gig. If the maintainers
| decline, Apple should hire someone to manage their own.
| fotta wrote:
| Ah I just read the links in jefftk's comment and it seems
| like you're right.
| tialaramex wrote:
| The existence of multiple independent definitions for eTLD+1
| would be very likely to create security holes, via a Confused
| Deputy-type scenario.
|
| If I was a security researcher, or a blackhat, and I found that
| bar.example is on the Mozilla PSL, and so Firefox considers
| foo.bar.example and quux.bar.example to be separate sites -
| while it isn't on the Apple PSL and so Apple's APIs treat
| foo.bar.example and quux.bar.example as parts of the same site
| (or vice versa), then I know I'm going to find weird bugs where
| Apple and the Firefox browser understand things about these two
| names differently and I can likely exploit that.
|
| The preference from PSL team members is to do _less_ with this
| hack over time, to put it behind us. But alas instead it
| motivates people to turn a hand-wavy notion "You know, a web
| site" into further reliance on the PSL instead of actually
| building a robust solution to their problem.
|
| This is particularly inexcusable from Apple because it's not
| like Apple is hurting for resources. If they actually wanted to
| solve problems, they could put the work in; so I think we can
| conclude they weren't much interested in solving the problem,
| only as usual in ensuring somebody else takes the blame.
| NovemberWhiskey wrote:
| > _edit: Seems like Apple was the one to declare PSL as
| canonical._
|
| Dependency on the Public Suffix List is already baked into
| essentially 100% of the global browser market for purposes like
| control of setting cookies - I'm not sure Apple made it any
| more 'canonical' by depending on it here.
| rectang wrote:
| PSL: Public Suffix List
|
| https://publicsuffix.org/
|
| > _A "public suffix" is one under which Internet users can (or
| historically could) directly register names. Some examples of
| public suffixes are .com, .co.uk and pvt.k12.ma.us. The Public
| Suffix List is a list of all known public suffixes._
|
| > _The Public Suffix List is an initiative of Mozilla, but is
| maintained as a community resource._
| kristofferR wrote:
| Is this actually a problem? From the Github page it seems like
| the rate of invalid inclusion requests is very low, less than one
| per day:
|
| https://github.com/publicsuffix/list/pulls?q=label%3Awontfix...
| kelnos wrote:
| That's not the issue; addition requests volume has suddenly
| gone way up because of this new Apple policy, and the
| volunteers that run the PSL are not prepared for it.
| throw14082020 wrote:
| What is a PSL inclusion request? Public Suffix List?
| pugworthy wrote:
| Same question - what is PSL?
|
| My best guess at the moment is Public Suffix List.
| manzu wrote:
| I'm just here to point the finger at Facebook, or anyone, for
| finding this workaround of declaring your legitimate website as a
| domain suffix just for tracking entropy purposes this is so
| laughable. like my ford fiesta identifies as an apache attack
| helicopter
| tick_tock_tick wrote:
| Apple is the one that declared this list to be the source of
| truth. Facebook is just information customers of Apple's
| decision.......
| gruez wrote:
| Can someone provide more context here? How does being added to
| the PSL affect tracking? Why are businesses adding themselves to
| the PSL en masse?
| twobitshifter wrote:
| 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 between all
| higher level domains. client1.mysite.com and
| client2.mysite.com. This allows you to store as much
| information as you want.
| TechBro8615 wrote:
| The PSL has always been a giant hack and totally
| unmaintainable in the long term. It's only a matter of time
| before someone mistakenly relying on it for security purposes
| gets owned by a rogue PR. Also, as mentioned in some of these
| issues, browsers don't even update it on any sort of
| guaranteed schedule.
| jakear wrote:
| The fun thing is you can s/PSL/DNS/g and the statement
| still holds. Same for BGP
| FemmeAndroid wrote:
| This followup issue seems to have a more clear writeup,
| especially for someone like me who is a bit out of the loop when
| it comes to the PSL:
|
| https://github.com/privacycg/private-click-measurement/issue...
| vHMtsdf wrote:
| The linked discussion makes me wonder, how much of our
| existence on the internet is just an unintended consequence of
| some minor engineering decision? Whim of an unknown engineer
| creating or destroying million dollar industries down the
| line...
| djrogers wrote:
| While it does have quite a bit of details, this followup issue
| is clearly written by someone from FB or one of the other AdCos
| who wants to point the finger back at Apple. The tone and
| wording used here is rather rich and entitled.
| [deleted]
| pandemicsyn wrote:
| you're not joking: https://github.com/privacycg/private-
| click-measurement/issue...
|
| >Who will vet such a list continuously at a global scale?
| >Apple should. >Apple created this issue in the first place.
| The need for multi-tenant websites to add themselves to the
| PSL exists only because of the PCM design decision to limit
| measurement to registrable domains. The urgency exists
| because Apple's planned ATT enforcement.
| romanhn wrote:
| Ben Savage is a pretty high-level engineer from Facebook's
| Ads org
| dkonofalski wrote:
| Seriously. I can see reasons that aren't entirely altruistic
| for Apple in trying to increase these privacy protections but
| trying to offload it back to Apple as if Facebook's abuse of
| consumer data isn't the real reason for this is ridiculous.
| wffurr wrote:
| They seem to think that people can't really "opt out" of
| "tracking" (scare quotes theirs). Talk about entitled.
| dialtone wrote:
| The quotes are entirely appropriate because adding some
| domain to the PSL makes the subdomains siloed cookie-wise
| so they can't share cookies and the PSL cannot use cookies
| anymore. Since they can't share cookies you can't track
| across even the same domain when added to the PSL.
|
| This is a feature needed for sites like Rakuten, Shopify,
| Alibaba that have multiple merchants under the same
| domains.
|
| Nothing to do with entitlement.
| kelnos wrote:
| FB seems to believe they are entitled to the ability to
| track people on iOS. Apple is under no obligation to
| allow that.
| dialtone wrote:
| Apple literally built a feature that requires addition to
| PSL to support a usecase that was addressed multiple
| times in the PrivacyCG meetings. How is this entitlement,
| they are following the Apple requirements.
| dswalter wrote:
| According to the comments in the history of that user on
| Github, it is someone who claims to be an engineer from
| Facebook in an earlier post: https://github.com/WICG/trust-
| token-api/issues/28#issue-6447...
| marketingtech wrote:
| This is fascinating to see Apple and Facebook engineers
| politely yet publicly arguing over potential technical
| implementations of Apple's privacy policies.
| [deleted]
| varispeed wrote:
| To be honest Facebook should offer a tracking free version with
| paid subscription. It is not acceptable that the only way to use
| Facebook and contact your family is to sacrifice your own and
| theirs privacy. When are we going to have a regulator step in and
| tackle this? It doesn't seem that GDPR has helped much, so I
| think more radical steps are needed. Such tracking that is being
| done online would be illegal offline (stalking), so I don't see
| how long this is going to go. It's not sustainable.
| echelon wrote:
| iPhone users are probably among Facebook's most valuable
| advertising demographic (ie. lots of disposable income).
| Apple's decisions to block tracking are hurting them in a big
| way, and offering a paid subscription probably won't seem
| attractive to users if Facebook prices it at the full value
| lost.
|
| We've trained people that everything is free. We can't get away
| from that now that the genie is out of the bottle. Furthermore,
| people might just decide Facebook isn't worth it for them at
| the level of functionality they provide. As more churn happens,
| the overall value of the network decreases.
|
| Apple just checkmated Facebook.
| dialtone wrote:
| This has nothing to do with tracking to target ads. Facebook
| doesn't need Apple to execute that, people share data with FB
| voluntarily.
|
| This is about measuring the impact of advertising while
| following a standard published by Apple itself and covering
| the usecase of big marketplaces with sub stores in it.
| PeterisP wrote:
| I don't think that such a paid subscription would be feasible.
| Facebook currently earns more than 150 $/year on ads for each
| of their US/Canada user _on average_ ; and iPhone users who
| would be willing to pay for such services probably are worth
| more than the average, so the appropriate market-determined fee
| to replace invasive ad targeting would be quite large.
|
| I don't think people would be willing to pay for tracking-free
| Facebook more than they pay for Netflix.
| varispeed wrote:
| I don't think profits of a private company should be a
| justification for such invasion of privacy. There is plenty
| of ways they could make it work, but we need a legislation to
| compel them to do so. That option should be mandated by law
| even if it turned out to be niche.
| sergiotapia wrote:
| So much brain power and work wasted on this ad bullshit
| amelius wrote:
| Yes and ads also stimulate over-consumption which hurts the
| planet.
|
| The solution is to block all ads, or even better, ban them.
| layoutIfNeeded wrote:
| Why are we using a centralized list for determining who's an eTLD
| and who's not? Why don't we store this metadata in the actual DNS
| records?
| marketingtech wrote:
| This is a result of Apple limiting the entropy of marketing data
| that can be received from a domain (defined as an eTLD+1) to 6
| bits.
|
| This causes problems for platforms like Shopify or marketplaces
| like Alibaba or eBay that may have multiple sellers trying to run
| ads on a domain and competing for the same small pool of entropy.
|
| This solution? Leverage the "public suffix" list to define your
| domain as an eTLD and give every seller a separate subdomain so
| that everyone gets their own data entropy namespace.
|
| Now every hosting provider or online marketplace is scrambling to
| re-architect their site into subdomains with public suffixes to
| maintain the status quo.
| gsnedders wrote:
| > This causes problems for platforms like Shopify or
| marketplaces like Alibaba or eBay that may have multiple
| sellers trying to run ads on a domain and competing for the
| same small pool of entropy.
|
| This is essentially https://github.com/privacycg/private-click-
| measurement/issue....
|
| Effectively it boils down to, "how can you distinguish the
| seller from the website owner?", if you want to give both
| seller and website owner entropy.
| tekstar wrote:
| Pretty much all Shopify shops have their own domains, only a
| minority drive traffic to their .myshopify.com subdomain
| bredren wrote:
| I was a bit surprised that a shopify biz that could not be
| bothered to use its own domain would be very concerned about
| monitoring ad performance.
|
| Seems someone would first effect to have a better branded
| site. As in, a decent TLD.
|
| And that if anything, this is a kick in the pants of an
| ecommerce site to get its own domain(s) to deal with this.
|
| Do I have that right?
| 43920 wrote:
| There's probably a decent number of sites that get most/all
| of their traffic from impulse purchases off of Facebook
| ads, and who have no actual branding. Obviously they should
| go ahead and just get a domain name, but they likely
| haven't had any reason to care up until this point either.
| simlevesque wrote:
| Well, I could own google.myshopify.com and be happy with it
| but have no way to buy the .com
| Macha wrote:
| Just suck it up and buy google-calculatorstore.com or
| whatever - if you're happy with the myshopify domain you
| clearly don't care _that_ much.
|
| Of course, that specific example, since Google is
| trademarked and well known might get you on the wrong end
| of Shopify's ToS or a UDRP request either way.
___________________________________________________________________
(page generated 2021-04-07 23:00 UTC)