I guess how it detects the "when sites try to open the popup-based authenticaion flow" is the attack vector. If it's Javascript, it's likely to be easily exploitable. If it's in the browser's chrome I suppose it would take a malicious add-on or similar device.
Right now a site could disingenuously call the relevant Facebook SDK API to unblock the Facebook resources listed here, and only on that site: https://searchfox.org/mozilla-central/source/browser/extensi...
I'm not too sure why that would be worthwhile as an attack, though. If you have anything in mind that would make it so, please let me know.
In the meantime, I'm working on a way to further tighten this a bit so the unblocking will only happen if a popup is successfully opened (so that at least if the popup blocker kicks in, nothing will happen unless the user intentionally allows that popup). I'm not 100% sure if that will work well, but I hope so.
I think the main attack vector I'd be worried about is if the SDK itself implemented a way around this protection, rendering it relatively useless. If that's not a feasible exploit, then I wouldn't be overly worried about as it would take effort on each website maintainer to implement and maintain the exploit.
The "real popup" detection sounds like a great addition if it works well!
SmartBlock just stands in for that blocked script, acting just enough like the real API to prevent some common site breakage.
This lets it detect when sites try to open the popup-based authenticaion flow, unload the stand-in script, load the real one, and continue the login flow.
It only unblocks some Facebook resources, as listed here: https://searchfox.org/mozilla-central/source/browser/extensi...
It only unblocks it for that specific website (the domain in the tab URL), and only until Firefox is closed. Other trackers continue to be blocked, and other tracking protections stay in place (as opposed to turning off ETP for the site entirely).