> Chrome's PNA protection can be bypassed using the IP address 0.0.0.0 to access services listening on the localhost on macOS and Linux.<p>It seems they're saying if you have a service listening to localhost (private), Chrome is supposed to not resolve 0.0.0.0 (public) to localhost, yet it currently does so.<p>So seems to me they're solving a security bug. But if I got this right, it's surprising how it got like that in the first place, doesn't make sense in any scenario I can think of to resolve 0.0.0.0 to localhost? Why would a browser try to resolve 0.0.0.0 to anything in the first place?
I can’t tell from reading the Chrome page (<a href="https://developer.chrome.com/blog/private-network-access-preflight/" rel="nofollow">https://developer.chrome.com/blog/private-network-access-pre...</a>) or the linked WICG draft: do these new protections apply to the usual CORS-bypassing requests: form submissions and ordinary navigation?
pls excuse my aged brain, now with a new blood clot.<p>IIRC adding 0.0.0.0 0.0.0.0 to your hosts file helps ???<p>On macOS;<p>% ping 0.0.0.0
PING 0.0.0.0 (0.0.0.0): 56 data bytes
ping: sendto: Socket is not connected
ping: sendto: Socket is not connected
Request timeout for icmp_seq 0
ping: sendto: Socket is not connected
Request timeout for icmp_seq 1
ping: sendto: Socket is not connected
Request timeout for icmp_seq 2
ping: sendto: Socket is not connected
Request timeout for icmp_seq 3<p>% ping 0
PING 0 (0.0.0.0): 56 data bytes
ping: sendto: Socket is not connected<p>ping: sendto: Socket is not connected
Request timeout for icmp_seq 0
ping: sendto: Socket is not connected
Request timeout for icmp_seq 1
ping: sendto: Socket is not connected
Request timeout for icmp_seq 2
ping: sendto: Socket is not connected
Request timeout for icmp_seq 3
ping: sendto: Socket is not connected<p>Is this correct ???