Firefox 145 expands tracking protections against third-party scripts that hide inside embedded login iframes.
Firefox 145 goes after trackers that nest inside login iframes. If a weird “Sign in with…” box breaks, suspect the embed before you disable every protection in a panic. First-party login pages are not what Mozilla described as the target.
Why embedded logins were a loophole
Trackers love riding along with convenient buttons. An iframe that looks like a login can also phone home. Firefox tightened that pattern. Privacy gains often show up first as site breakage, then as patches from sites that relied on lazy embeds.
If you maintain a site with social login widgets, test on Firefox 145 quickly. Prefer documented, first-party-friendly flows over mystery frames stuffed with partners.
What users should do
Update Firefox. If a site’s social login dies, try the site’s own password form or passkey option. Ask the site to fix the embed rather than turning protections off globally for every website you visit.
Mozilla keeps choosing the user over the tracker’s convenience. Occasional breakage is the bill. Paying it once per broken embed beats paying with your session graph every day.
Site owner playbook
Replace third-party login iframes that pull extra trackers with documented OAuth redirects. Test on Firefox Nightly going forward so the next protection wave does not surprise you in production. If you must keep an embed, minimize third-party scripts inside it. Mozilla will keep closing loopholes. Engineering time spent on clean auth now is cheaper than emergency “please whitelist us” threads later.
Support macro for breakage
If users write in about a broken social login on Firefox, send a macro that suggests the site’s password form, passkeys if offered, and a link to update Firefox—not a guide to disable tracking protections site-wide. Train support not to make privacy the enemy of convenience by default. Mozilla raised the bar. Your support tone either respects that bar or trains users to tear it down.