LGTM2

On Fri, Feb 2, 2024 at 11:10 PM Mike Taylor <[email protected]> wrote:

> Correction: LGTM1, conditioned on requesting Enterprise, Debuggability,
> and Testing bits in chromestatus. :)
> On 2/2/24 5:09 PM, Mike Taylor wrote:
>
> LGTM1
> On 2/2/24 11:17 AM, Jonathan Hao wrote:
>
> Contact emails [email protected]
>
> Explainer
> https://github.com/WICG/private-network-access/blob/main/explainer.md
>
> Specification https://wicg.github.io/private-network-access
>
> Design docs
>
> https://docs.google.com/document/d/1UqkJsc2VZ4bXmZkVxh-EPyBFEtdxX9p2zX4sxzAj754/edit?usp=sharing&resourcekey=0-7cfhrTo57AElxA6M9EVScg
>
> Summary
>
> Before a website A navigates to another site B in the user's private
> network, this feature does the following:
> 1. Checks whether the request has been initiated from a secure context
> 2. Sends a preflight request, and checks whether B responds with a header
> that allows private network access.
>
> The above checks are made to protect the user's private network.  There
> are already features for subresources and workers, but this one is for
> navigation requests specifically.
>
>
> Since this feature is the "warning-only" mode, we do not fail the requests
> if any of the checks fails.  Instead, a warning will be shown in the
> DevTools, to help developers prepare for the coming enforcement.
>
>
> Blink component Blink>SecurityFeature>CORS>PrivateNetworkAccess
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature%3ECORS%3EPrivateNetworkAccess>
>
> Motivation
>
> To prevent malicious websites from pivoting through the user agent's
> network position to attack devices and services which reasonably assumed
> they were unreachable from the Internet at large, by virtue of residing on
> the user’s local intranet or the user's machine.
>
>
> Initial public proposal
> https://discourse.wicg.io/t/transfer-cors-rfc1918-and-hsts-priming-to-wicg/1726
>
> TAG review https://github.com/w3ctag/design-reviews/issues/572
>
> TAG review status Issues addressed
>
> Risks
>
>
> Interoperability and Compatibility
>
> Since we don't enforce the checks and only show warnings, there isn't any
> compatibility risks on the client side. On the server side, it shouldn't
> pose any risk either as the server can ignore the preflight requests.
>
>
> *Gecko*: Positive (
> https://github.com/mozilla/standards-positions/issues/143)
>
> https://mozilla.github.io/standards-positions/#cors-and-rfc1918 makes it
> a bit clearer that this is indeed positive (vs the issue).
>
>
> *WebKit*: Positive (
> https://github.com/WebKit/standards-positions/issues/163) Safari
> disagrees with the spec name and header names, but still overall positive.
>
> *Web developers*: Mixed signals Anecdotal evidence so far suggests that
> most web developers are OK with this new requirement, though some do not
> control the target endpoints and would be negatively impacted.
>
> *Other signals*:
>
> Security
>
> This change aims to be security-positive, preventing CSRF attacks against
> soft and juicy targets such as router admin interfaces. DNS rebinding
> threats were of particular concern during the design of this feature:
> https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit#heading=h.189j5gnadts9
>
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
> None
>
>
> Debuggability
>
> Relevant information (client and resource IP address space) is already
> piped into the DevTools network panel. Deprecation warnings and errors will
> be surfaced in the DevTools issues panel explaining the problem when it
> arises.
>
>
> Is this feature fully tested by web-platform-tests
> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
> ? Yes
>
>
> https://wpt.fyi/results/fetch/private-network-access?q=fetch%2Fprivate-network-access&run_id=5090117631868928&run_id=6245938696814592&run_id=5769215446351872&run_id=5679819023974400
>
>
> Flag name on chrome://flags None
>
> Finch feature name PrivateNetworkAccessForNavigations,
> PrivateNetworkAccessForNavigationsWarningOnly
>
> Requires code in //chrome? False
>
> Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=1524350
>
> Estimated milestones
> Shipping on desktop 124
> Shipping on Android 124
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/4869685172764672
>
> This intent message was generated by Chrome Platform Status
> <https://chromestatus.com/>.
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOC%3DiPJ3_pVL7Tecn_3iKBMojOVPx8%3D%3DnCDQWRKetG_9WBxsWg%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOC%3DiPJ3_pVL7Tecn_3iKBMojOVPx8%3D%3DnCDQWRKetG_9WBxsWg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8f8b93f8-4358-4fdc-bfe2-d43cec3e37c1%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8f8b93f8-4358-4fdc-bfe2-d43cec3e37c1%40chromium.org?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSLfMW08XDibmDKrCKkJOjyHj3B%2B3MsmQ4WnwxeoBk_wng%40mail.gmail.com.

Reply via email to