4 ms·

There is a specification for blocking this: https://wicg.github.io/private-network-access/ https://wicg.github.io/private-network-access/ It gained support fr

There is a specification for blocking this: https://wicg.github.io/private-network-access/ https://wicg.github.io/private-network-access/ It gained support from WebKit: https://github.com/WebKit/standards-positions/issues/163 https://github.com/WebKit/standards-positions/issues/163 …and Mozilla: https://github.com/mozilla/standards-positions/issues/143 https://github.com/mozilla/standards-positions/issues/143 …and it was trialled in Blink: https://developer.chrome.com/blog/private-network-access-update/ https://developer.chrome.com/blog/private-network-access-upd... Unfortunately, it’s now on hold due to compatibility problems: https://developer.chrome.com/blog/pna-on-hold https://developer.chrome.com/blog/pna-on-hold

matthberg 1y ago
Yep! Unfortunately its main method (as far as I remember from when I first read the proposal at least, it may do more) is adding preflight requests and headers to opt-in, which works for most cases yet doesn't block behind-the-lines collaborating apps like mentioned in the main article. If there's a listening app (like Meta was caught doing) that's expecting the requests, this doesn't do much to protect you. EDIT: Looks like it does mention integrating into the permissions system [0], I guess I missed that. Glad they covered that consideration, then! 0: https://wicg.github.io/private-network-access/#integration-permissions https://wicg.github.io/private-network-access/#integration-p...
bakkoting 1y ago
Both Firefox [0] and Chrome [1] are working on successors which rely on permissions prompts instead of preflight requests. [0] https://groups.google.com/a/mozilla.org/g/dev-platform/c/B8oN3ARp_j0/m/rWKXmnj4AAAJ https://groups.google.com/a/mozilla.org/g/dev-platform/c/B8o... [1] https://groups.google.com/a/chromium.org/g/blink-dev/c/CDy8LAs-DoA/m/H5pNeS3WAAAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/CDy8L...
- grg994 1y ago
  The Firefox bug referenced in [0] is open since 2018 (https://bugzilla.mozilla.org/show_bug.cgi?id=1481298 https://bugzilla.mozilla.org/show_bug.cgi?id=1481298)?! What is so difficult about this? 0. Define 2 blocklists: one for local domains and one for local IP addresses 1. Add a per-origin permission next to the already existing camera, mic, midi, etc... Let's call it LocalNetworkAccess, set it false by default. 2. Add 2 checks in networking stack: 2a. Before DNS resolution check the origins LocalNetworkAccess permission. If false check the URL domain against a domain blocklist, deny the request if matches. 2b. Before the TCP or UDP connect check the the origins LocalNetworkAccess permission. If false check the remote IP address against an IP blocklist, deny the request if matches. 3. If a request was denied, prompt the user to allow or disallow the LocalNetworkAccess permission for the origin, the same way how camera, mic or midi permission is already prompted for. This is a trivial solution, there is no way this takes more than 2-300 lines of code to implement in any browser engine. Why is it taking years?! And then of course one can add browser-specific config options to customize the blocklists, but figure that out only after the imminent vulnerability has been fixed.

matthberg 1y ago

Yep! Unfortunately its main method (as far as I remember from when I first read the proposal at least, it may do more) is adding preflight requests and headers to opt-in, which works for most cases yet doesn't block behind-the-lines collaborating apps like mentioned in the main article. If there's a listening app (like Meta was caught doing) that's expecting the requests, this doesn't do much to protect you. EDIT: Looks like it does mention integrating into the permissions system [0], I guess I missed that. Glad they covered that consideration, then! 0: https://wicg.github.io/private-network-access/#integration-permissions https://wicg.github.io/private-network-access/#integration-p...

bakkoting 1y ago

Both Firefox [0] and Chrome [1] are working on successors which rely on permissions prompts instead of preflight requests. [0] https://groups.google.com/a/mozilla.org/g/dev-platform/c/B8oN3ARp_j0/m/rWKXmnj4AAAJ https://groups.google.com/a/mozilla.org/g/dev-platform/c/B8o... [1] https://groups.google.com/a/chromium.org/g/blink-dev/c/CDy8LAs-DoA/m/H5pNeS3WAAAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/CDy8L...

grg994 1y ago
The Firefox bug referenced in [0] is open since 2018 (https://bugzilla.mozilla.org/show_bug.cgi?id=1481298 https://bugzilla.mozilla.org/show_bug.cgi?id=1481298)?! What is so difficult about this? 0. Define 2 blocklists: one for local domains and one for local IP addresses 1. Add a per-origin permission next to the already existing camera, mic, midi, etc... Let's call it LocalNetworkAccess, set it false by default. 2. Add 2 checks in networking stack: 2a. Before DNS resolution check the origins LocalNetworkAccess permission. If false check the URL domain against a domain blocklist, deny the request if matches. 2b. Before the TCP or UDP connect check the the origins LocalNetworkAccess permission. If false check the remote IP address against an IP blocklist, deny the request if matches. 3. If a request was denied, prompt the user to allow or disallow the LocalNetworkAccess permission for the origin, the same way how camera, mic or midi permission is already prompted for. This is a trivial solution, there is no way this takes more than 2-300 lines of code to implement in any browser engine. Why is it taking years?! And then of course one can add browser-specific config options to customize the blocklists, but figure that out only after the imminent vulnerability has been fixed.