I'm not exactly sure what they're referring to in this article, since they elide technical details. Localhost resources might consist of: * file:// URIs, wh

I'm not exactly sure what they're referring to in this article, since they elide technical details. Localhost resources might consist of: * file:// URIs, which are well-understood and protected for a long time now * http(s)://localhost/ URIs, which seems most likely to be the subject of their focus in this discussion. Many software packages, particularly Linux ones, are known to spawn web servers, sometimes unbeknownst to the end-user, and sometimes on an alternate port. It usually takes extra effort to secure these servers with authentication, and it's usually infeasible to deploy TLS certificates on them. * http(s)://localnet URIs, in the form of RFC1918 private IP address space, which might also encompass 169.254.0.0/16 and 100.64.0.0/10, as well as all IPv6 equivalents, such as link-local addresses. It is a fairly well-known hole that any web server could link or embed a resource from private network space, and the user's browser would dutifully fetch it, without considering whether the external untrusted network had a right to fetch that resource in the context of the user's web browser. The latter case is perhaps the most difficult to defend against, and the most concerning case, because while your personal workstation may not run web servers listening on localhost, your LAN may present juicy opportunities for lateral movement, especially in terms of consumer routers with admin interfaces, print servers, IoT devices, etc.