Update Wiki to include details for transparency about the Facebook vetting process

[bedfordsean]

Apparently it isn't possible to raise a PR against a Github wiki so instead posting proposed text here as an issue for review.

Context: With various PRs now coming in related to iOS 14/Facebook issues, and with a process in place on the FB side about how we handle requests, we'd like to be transparent about what exactly Facebook is checking for to help provide assurance and a more open conversation about how certain domains end up on the PSL.

I propose the following updates to the wiki:

On page: https://github.com/publicsuffix/list/wiki/Third-Party-Diffusion, add sub-bullets to the Facebook bullet that detail:

• Facebook has a review process for requests for addition. During that review the following things will be checked:
  • The domain(s) requested for addition have subdomains in large numbers
  • The domain(s) requested for addition do indeed appear to represent separate business entities which require cookie separation
  • The domain(s) requested for addition are owned by the requestor and will continue to be owned for at least two years
  • The domain(s) requested for addition are not running functionality which would break with a PSL addition (e.g. login/registration, cookie functionality, JavaScript and dynamic behaviours)

[bedfordsean]

@dnsguru would you mind taking a review of this? Once we're agreed on the right level of detail, we can place this in the PSL wiki, FB docs, or both

[sleevi]

The first two bullet points have no bearing on the PSL, but their inclusion seems like it would be seen as valuable. Would it be simpler to just link to a page at Facebook with details on Facebook's process, which would make it clearer the distinction in policies and purposes?

[dnsguru]

I think in addition to these acceptance criteria that Facebook might measure, rather than a "we vouch" from one of the team at FB, we would want to have each PR hold some of the actual information responses - sans PII or sensitive info, but with enough substance to merit exception. Even with that, I am still quite reticent to start approving these. While the thundering herd issue now has some easing and FB have stepped in to sieve, for those that come through that qc we are still in workaround city. Most concerning to me is making exceptions to some of the principles around working around limits. My primary concern remaining is that this will add stress to the voluntary trust at the foundation of the PSL in us NOT doing this, which will cause browsers et. al. "consumers" that incorporate or use the PSL to stop and begin to roll their own.

…

On Wed, Sep 8, 2021, 6:25 PM Ryan Sleevi ***@***.***> wrote: The first two bullet points have no bearing on the PSL, but their inclusion seems like it would be seen as valuable. Would it be simpler to just link to a page at Facebook with details on Facebook's process, which would make it clearer the distinction in policies and purposes? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1412 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACQTJJH4U7FVSE5FZEDA7LUBAEHLANCNFSM5DUJHPRQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[bedfordsean]

Would it be simpler to just link to a page at Facebook with details on Facebook's process, which would make it clearer the distinction in policies and purposes?

Yes we can certainly do this to clarify/distinguish PSL focus vs Facebook.

I think in addition to these acceptance criteria that Facebook might
measure, rather than a "we vouch" from one of the team at FB, we would want
to have each PR hold some of the actual information responses - sans PII or
sensitive info, but with enough substance to merit exception.

I can investigate how we'd release discussion points but am not sure what sort of legal/confidentiality agreement we have with people who contact us through our support systems, so need to confirm on that first. If we want to optimise for transparency, it seems like a GitHub PR is actually best? (without all of the pressure/misdirected assumptions of accountability on PSL volunteers that happened before).

Even with that, I am still quite reticent to start approving these.

My main concern here is that I'm going to struggle to convince our support teams to long-term (fine for the short-term) run a process that doesn't deliver any outcomes for the businesses they support. Approve/deny responsibility ultimately sits with the maintainers here and we tell everyone that we make a "recommendation to proceed" with that our recommendation holds no stock and the arbiters are this group. I agree this is less than ideal and completely understand your points of concern re workarounds.

While the thundering herd issue now has some easing and FB have stepped in
to sieve, for those that come through that qc we are still in workaround
city.

The Facebook perspective on what constitutes a "workaround" here likely differs from Apple's perspective ;-). The PSL is very much a band-aid on top of a problem created by this browser behavioural change. We've got some other approaches in the pipe that are not PSL dependent, but they're still a few weeks away.

I expect we can probably hold on making a firm call one way or the other on this until then (we're seeing ~40 requests/month and maybe 0-1 of those per month seem like they might be a fit for PSL addition).

That said, there are some fairly clear examples like "myshopify.com" whose primary goal was cookie separation but a side effect/second desired outcome for Shopify was also allowing their hosted merchants to run ads on an eTLD+2. I think it would be better if we can nail down concretely the principles we have in mind for the grey zone cases like that and what would constitute a "yay" or a "nay".

[dnsguru]

Time permitting, these discussions can evolve. Working around third party limits via the PSL is unattractive, as it will trigger the affected browsers/ca/etc that had counted on rate limits to fork away from use of the PSL. The PSL currently plays a crucial role in Universal Acceptance of domain names and the naming system as it evolves, and most notably TLDs that newly launch have historically been hobbled within webkit based browsers where the lag time between eTLD list updates (PSL) by those and their propogation out to devices can take MONTHS.

Great effort was put in to working with ICANN to obtain a json file of TLDs as they Contract (as opposed to getting added into the Root) in order to overcome that gap, which keeps TLDs from going to search instead of DNS when they launch.

If Webkit were to be motivated by repetitive use of the PSL to work around the security and privacy features in Apple devices, and opt to stop using / incorporating PSL to go their own direction for eTLD+1 sourcing, this likely fractures the universality of the PSL to have some predictable impact on TLD launches, which was hard won and good for internet users.

This means as new IDN ccTLDs launch, ccTLD changes happen, new gTLDs open, etc. will be broken or behave inconsistently on devices that have a fruit on them from those that don't. It would also mean that private entries such as those being submitted but also those of the thousands of other projects that the PSL helps explicitly define cookie behavior, adminstrative boundaries or other domain behavior for would lose that benefit.

When we are hardline about not using the PSL to bypass limits, big contexts like this are under consideration. Stressing the trust for workarounds adds risk that any of them can be that 'one too many' that splinters things and ruins it for those that follow.
Trust is earned, and 15 years in and thousands, perhaps tens of thousands of volunteer hours were invested in building that voluntary trust in the PSL.

Climbing down off my monologue soapbox, there are a handful of requests that have made it through the processes at Facebook of vetting and determination on proceeding or not. This has helped narrow the stressing of the resource constraint on PSL volunteers that was caused by Apple and Facebook identifying in their guidance that PSL entry eTLD+n were not nerfed by IOS.

Did that flood us? Sure. Was it irritating? Absolutely. Is our reticence to proceed in approving all PR that come through after FB vetting punative over those matters? Not really.

In fact, a couple were let through as a 'trial balloon', to test the waters on how the vetting process would work. Where there was ample information about the vetting, these did proceed forward. More may.

Each and every request that come through that process result in a PR that violate a core tenet trust in respecting third party limits.

With empathy for the affected, we tread lightly on this, and given what is at stake holistically, we want to have each PR have a clear and transparent rationale available to show why so that the institutional trust and voluntary incorporation that has the PSL to be so widely used.

I appreciate where the team at FB have stepped up to address the swarming issue and the patience of the affected who have hopped through the hoops to advance.

[bedfordsean]

Thanks @dnsguru for the history and context here. In following the PRs over the past several months, I've developed a strong appreciation for the the work you all do here. It's clear that this is a hard-fought project, with no "clear cut" answers in many cases - I do not envy the job!

We certainly don't want to jeopardise the rationale or reasoning that have led to the PSL being widely adopted, nor force a browser vendor to make a decision that the PSL is not fit for purpose and cut it, with all of the fallout that would come with that.

It was with that reasoning that I originally opened this issue to discuss the transparency aspect to try to consolidate and ensure that decisions being made with clarity on the checks and discussion that has happened prior. It seems to me like another important part of this is going to be consistency.

As I say, we do have some other things in the works as I am 100% agreed that the PSL is not the right place for these things to sit. The evolving browser landscape conversation in some ways is going to press the issue and I would much prefer we talk about it rather than sleepwalk into a place where the PSL becomes a defacto mechanism (at which point you'd probably have to take a very hardline stance to avoid workarounds).

I think this conversation does require more time and more thought. What I can commit to from the FB side is more transparency on the above described checks in our documentation, after which I suggest we revisit this conversation once our non-PSL solution has had a chance to bed in (likely a couple more months)?

As the "trial balloons" have now been floated, what would you like us to do with future PSL requests?

• We can continue this process and send them through here
• Alternatively we can tell clients who appear to be in a position that we believe to be fairly legitimate (nominally platforms who host many independent businesses like "myshopify.com") that they should treat a PSL route as very unlikely and instead work on other mechanisms?
  • As you can appreciate, it is a lot of work for a platform hosting service to totally overhaul their business and move away from subdomain hosting as well as getting each hosted business up and running with a purchased domain, so if this is the best path, I believe it is better to tell these platforms ASAP to get the ball rolling

[dnsguru]

Thanks @dnsguru for the history and context here. In following the PRs over the past several months, I've developed a strong appreciation for the the work you all do here. It's clear that this is a hard-fought project, with no "clear cut" answers in many cases - I do not envy the job!

Appreciate a lot where there is avoidance of adding scope or lifting.

We certainly don't want to jeopardise the rationale or reasoning that have led to the PSL being widely adopted, nor force a browser vendor to make a decision that the PSL is not fit for purpose and cut it, with all of the fallout that would come with that.

The other facet to this gem of a situation is that folks talk about breaking up and doing their own, which would render volunteer time irrelevant, which demotivates anyone really 'leaning in', right?

It was with that reasoning that I originally opened this issue to discuss the transparency aspect to try to consolidate and ensure that decisions being made with clarity on the checks and discussion that has happened prior. It seems to me like another important part of this is going to be consistency.

Yes, this was a good start. Identifying WHAT the venting process was between the affected party and FB is one portion of the transparency element, but really, if one looks at each individual PR like a universe of its own, some of what the actual answers were help to illustrate the rationale of letting something proceed or not.

I think I oversimplified my "FB Vouches" comment and should have more clearly articulated what I meant and expressed it in a manner that was perhaps a bit flippant... I'd say it better this way, that having comments from yourself or one of your colleagues at Facebook that have had an affected party run your gauntlet comment, "This party provided us answers that make us convinced this should proceed" is different than "When asked about X, their response was Y, indicating their understanding of both the problem and the impact", and the latter stands as better documentation about the PR and why it merits consideration.

As I say, we do have some other things in the works as I am 100% agreed that the PSL is not the right place for these things to sit. The evolving browser landscape conversation in some ways is going to press the issue and I would much prefer we talk about it rather than sleepwalk into a place where the PSL becomes a defacto mechanism (at which point you'd probably have to take a very hardline stance to avoid workarounds).

Yes, we seem to have a penalty for succes on the reach aspect here. And should there be other solutions, the true hope is that these do not unfix some things that have been hard won, like interoperability and Universal Acceptance.

I think this conversation does require more time and more thought. What I can commit to from the FB side is more transparency on the above described checks in our documentation, after which I suggest we revisit this conversation once our non-PSL solution has had a chance to bed in (likely a couple more months)?

Agree, time permitting

As the "trial balloons" have now been floated, what would you like us to do with future PSL requests?

My thinking was that we let these run for 90 days or so, watching for rollback requests or complaints (will need FB team to be forthcoming on where clients engage about this after being included, as those likely and hopefully are going through FB and not here)

• We can continue this process and send them through here
• Alternatively we can tell clients who appear to be in a position that we believe to be fairly legitimate (nominally platforms who host many independent businesses like "myshopify.com") that they should treat a PSL route as very unlikely and instead work on other mechanisms?

I'd like to get @sleevi and @weppos opinions on this - anything we would be doing in approving these puts nails in the coffin of trust in the PSL from my POV

• As you can appreciate, it is a lot of work for a platform hosting service to totally overhaul their business and move away from subdomain hosting as well as getting each hosted business up and running with a purchased domain, so if this is the best path, I believe it is better to tell these platforms ASAP to get the ball rolling

I have a robust "I hear ya" on this + #overstood and hopefully there is less changes in the future that operate in Fire, Ready, Aim mode outside of the PSL as this was.

[bedfordsean]

The other facet to this gem of a situation is that folks talk about breaking up and doing their own, which would render volunteer time irrelevant, which demotivates anyone really 'leaning in', right?

Completely. One of the other things I'm trying to avoid FB doing is making our own fork of the PSL for use by our in-app browser as a direct "solve" for businesses in this position. That would also create an inconsistency/lack of transparency problem that I'm not particularly thrilled about.

I'd say it better this way, that having comments from yourself or one of your colleagues at Facebook that have had an affected party run your gauntlet comment, "This party provided us answers that make us convinced this should proceed" is different than "When asked about X, their response was Y, indicating their understanding of both the problem and the impact", and the latter stands as better documentation about the PR and why it merits consideration.

Thanks that is a lot clearer and makes total sense. After you check in with @sleevi and @weppos to confirm whether we "hold" or "continue" during this 90D period, we can provide more context on future requests if "continue" is what we do decide.

My thinking was that we let these run for 90 days or so, watching for rollback requests or complaints (will need FB team to be forthcoming on where clients engage about this after being included, as those likely and hopefully are going through FB and not here)

This makes sense to me, and we'll definitely be checking in with the clients who have been through this process to ensure things are working as expected.

[dnsguru]

No new updates as yet. @bedfordsean as you see / hear requests within your team(s) related to those "trial balloon" PR or those in the queue, please add comments here.

[dnsguru]

Wiki is updated to include the bullet points @bedfordsean

[bedfordsean]

No new updates as yet. @bedfordsean as you see / hear requests within your team(s) related to those "trial balloon" PR or those in the queue, please add comments here.

Will do. From our side by virtue of PSL addition (which we pull daily) those businesses are now unblocked. I'll double check to see if any of the PSL pushes have made it into browsers yet which is the real test.

Wiki is updated to include the bullet points @bedfordsean

Thank you! We document the same bullets now as a response to form submissions on our help centre page