Words With Friends Facebook app just shows a spinning 'W' tile

[chrisco23]

Just tracked this down turning off my extensions one by one. Sure enough turning off Privacy Badger solved it. I investigate a little more and found that I can exclude) apps.facebook.com and still have Privacy Badger on.

That's fine for me for now but thought you might want to know, as who knows what else broke on Jan 17.

[ghostwords]

Previously: #3027 where vscode.dev and visualstudio.com belong to the same MDFP list, but our DNR rules somehow blocked a subdomain of visualstudio.com on vscode.dev.

Here, facebook.net and facebook.com are similarly on the same MDFP list, but our DNR rules somehow block connect.facebook.net on apps.facebook.com.

Here is the relevant DNR block rule that ends up blocking connect.facebook.net:

{
    "action": {
        "type": "block"
    },
    "condition": {
        "domainType": "thirdParty",
        "excludedInitiatorDomains": [
            "meta.com",
            "facebook.com",
            "instagram.com",
            "messenger.com",
            "threads.net",
            "workplace.com",
            "oculus.com",
            "oculuscdn.com",
            "oculusrift.com",
            "oculusvr.com",
            "powersunitedvr.com",
            "cdninstagram.com",
            "facebook.net",
            "fbcdn.com",
            "fbcdn.net",
            "fbsbx.com"
        ],
        "requestDomains": [
            "facebook.net"
        ]
    },
    "id": 1280,
    "priority": 1
}

[ghostwords]

OK, so the problem here is that Chrome sees a Zynga sub frame (wwf.zynga.com) attempting to load something from connect.facebook.net, and apparently excludedInitiatorDomains consider the immediate parent frame to be the initiator, not the top-level document. Since we mean to check third party-ness against the top-level document, not the sub frame, and since zynga.com is not part of Facebook's MDFP list, we end up blocking connect.facebook.net on apps.facebook.com.

[chrisco23]

ok, thanks. So does this mean it's expected behavior? I'm fine with leaving apps.facebook.com disabled as it is now, all works at least.

…

On Wed, Jan 29, 2025 at 12:18 PM Alexei ***@***.***> wrote: OK, so the problem here is that Chrome sees a Zynga sub frame ( wwf.zynga.com) attempting to load something from connect.facebook.net, and apparently excludedInitiatorDomains consider the immediate parent frame to be the initiator, not the top-level document. Since we mean to check third party-ness against the top-level document, not the sub frame, and since zynga.com is not part of Facebook's MDFP list, we end up blocking connect.facebook.net on apps.facebook.com. — Reply to this email directly, view it on GitHub <#3048 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB3B4YPNIU33L7MKPANK7L2NEZPRAVCNFSM6AAAAABWBZMF52VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMRSG42TEMZXGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[ghostwords]

We're butting up against a Chrome Manifest V3 design problem. This is definitely a Privacy Badger bug, unfortunately not limited to Facebook. We should have a workaround for it in the future, but yeah, I would just keep PB disabled on apps.facebook.com for now.