Your browser lets remote code send packets to localhost???!

I think cross-site exploits (XSS, CSRF, etc) are about one site exploiting another site, and that's not what's happening here. Both sites/applications are cooperating; neither is being used in a way that its developer did not intend. There are plenty of intentionally-supported ways to opt in to cross-site communication - CORS, non-idempotent GET, WebSockets, etc - and there's nothing inherently wrong with using them, even when one side is running on localhost.

The problem here is that browsers and OSes try to implement privacy protection with sandboxing etc, with the policy that apps are allowed to persistently identify users but web sites aren't, and Meta and Yandex set up covert channels between their apps and web sites to violate that policy.

Protections like https://github.com/explainers-by-googlers/local-network-a... are not intended for this case (though they might fix it anyway, as a side effect): they're trying to e.g. prevent random web pages from accessing http://192.168.0.1/router.cgi?firewall=off in case the router manufacturer mistakenly assumes that any HTTP request from the local network must be from a trusted user and does not perform appropriate authentication.

Chrome's previous proposal (PNA) allowed local services to opt in to promptless cross-site requests (via the CORS pre-flight request), which wouldn't have blocked this covert channel since the Meta/Yandex apps could have just opted in. They say the main reason they dropped that in the new proposal is that it's much easier to add a permission prompt to one browser than to add the opt-in code to the many local services that currently rely on cross-site requests for legitimate purposes; it was for practicality and compatibility, not for improved security or privacy.