Facebook Third Party Sign In Button Error

[weems]

Support Request to Fix Facebook Sign in to Websites.

1. Go to https://quora.com
2. Click Sign in Using Facebook
3. Observe Nothing Happens
4. Try with Same Type of Button For Google when Signed in to Google and Notice you get a Window to allow Signing in to Quora using Google

Trying the Above Steps for https://fitbit.com and https://digg.com/reader#sign-in renders the same result. I think it is likely due to third party tracking being blocked. Perhaps we should discuss if we want users to block third party tracking or allow these buttons to function. It seems we are allowing the Google Button to function.

[psimyn]

Possibly duplicate of #449 ?

And maybe #503

[weems]

@psimyn for #449 I would agree, but Tracking is Off Yet Signing in using Google works.

[weems]

@psimyn I don't think it is relevant for #503 because in the latest Brave I can sign in to FB chat with tracking on.

[bbondy]

@diracdeltas could you take a look?

[diracdeltas]

This is due to tracking protection blocking requests from www.quora.com to www.facebook.com and possibly also staticxx.facebook.com. Quora, Digg, and Fitbit login with FB are also broken in the same way in Firefox in Private Browsing mode (which has tracking protection enabled).

I think we shouldn't whitelist FB in this case because it's a solvable bug in the implementation of FB login. There is no reason the site needs to make a third-party AJAX request to a facebook domain in order to popup the login window AFAICT. As the OP noted, Google login works fine.

We could try to detect if the page is making requests to the FB login endpoint and pop up a dialog that says basically "turn off tracking protection on this site in order to login with FB".

[weems]

@diracdeltas curious if (Firefox, others) consider the FB buttons more of a tracking risk than the way Google has designed them in some way more securely? Or if the reason Google is allowed through is something more mundane.

[diracdeltas]

Or if the reason Google is allowed through is something more mundane.

The reason Google is allowed through is that the button functionality doesn't require 3rd party requests.

[weems]

If only FB was more responsible. :/

[BrendanEich]

Is anyone talking to Facebook? The feature from their point of view is the social graph data the relying party gets; this gave some sites a reason to adopt FBConnect back in the day, IIRC.

At scale most users will see us as the buggy party. Can we fake out things so that the login succeeds but the 1st party is concealed? Handwaving a bit, @diracdeltas does this seem possible?

To say a bit more: the button functionality seems to require 3rd party requests, but could we both block those requests and make those appear to succeed, and so let the login succeed? Might involve some monkey-patching.

[diracdeltas]

Is anyone talking to Facebook?

I am most in favor of them fixing it on their side so that this also works for Firefox with Tracking Protection. Will try to find someone now.

[diracdeltas]

FF issues: https://bugzilla.mozilla.org/show_bug.cgi?id=1226498, https://bugzilla.mozilla.org/show_bug.cgi?id=1163771

Judging by the number of people complaining about this on StackOverflow, I'm surprised it's not a bigger deal for Mozilla or Facebook

[diracdeltas]

Either way, I think it would be pretty straightforward to hack around in the preload script.

1. user clicks FB login button.
2. Brave unblocks connect.facebook.net temporarily and calls the boilerplate code that loads it asynchronously.
3. we wait until the FB SDK is loaded and then call the actual click handler for the FB login button.

When a user clicks the FB login button, that is a signal that they are consenting to being tracked by FB IMO.

[sebmck]

@diracdeltas I don't think the Firefox bug is the same issue. That one's due to Firefox blocking the Facebook script when tracking protection is enabled which is unavoidable since the script is required to actually function.

The resource at "https://connect.facebook.net/en_US/all.js" was blocked because tracking protection is enabled.

I'm looking into this particular issue effecting Brave and it does look like it's due to making an AJAX request. I'll keep this issue posted.

[diracdeltas]

@kittens i think you're right. just checked and actually Brave already whitelists connect.facebook.net for that reason.

[diracdeltas]

Changing the temp. whitelist from just connect.facebook.net to ['connect.facebook.net', 'connect.facebook.com', 'staticxx.facebook.com', 'www.facebook.com'] fixed the issue on all three sites (quora, digg, fitbit). I think this will be harder to shim than I initially thought. @bbondy for the next release, do you think these should all just be whitelisted for now or only whitelisted on sites where we know they are necessary?

[diracdeltas]

closing this in favor of #880 for further discussion