-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update Wiki to include details for transparency about the Facebook vetting process #1412
Comments
@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 |
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? |
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>.
|
Yes we can certainly do this to clarify/distinguish PSL focus vs Facebook.
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).
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.
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". |
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. 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. |
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?
|
Appreciate a lot where there is avoidance of adding scope or lifting.
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?
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.
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.
Agree, time permitting
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)
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
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. |
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.
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.
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. |
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. |
Wiki is updated to include the bullet points @bedfordsean |
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.
Thank you! We document the same bullets now as a response to form submissions on our help centre page |
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:
The text was updated successfully, but these errors were encountered: