Hi Yoav,

It's been 2 weeks but no other API owners have replied.  Do you know if
there's any blockers?  Should we ping the other API owners or could you
help us?

Best,
Jonathan

On Wed, Apr 12, 2023 at 1:26 PM Yoav Weiss <[email protected]> wrote:

> LGTM1
>
> Thanks for explaining! :)
>
> On Wed, Apr 12, 2023 at 2:24 PM Jonathan Hao <[email protected]> wrote:
>
>>
>>
>> On Wed, Apr 12, 2023, 12:45 Yoav Weiss <[email protected]> wrote:
>>
>>>
>>>
>>> On Wed, Apr 5, 2023 at 2:02 PM Jonathan Hao <[email protected]> wrote:
>>>
>>>> Sorry for the confusion about the spec name.  We've recently changed
>>>> our stance
>>>> https://github.com/WICG/local-network-access/issues/91#issuecomment-1494704528
>>>> and the spec name is still unsettled until we hear back from other browser
>>>> vendors. Both Private Network Access and Local Network Access mean the same
>>>> thing for now.
>>>>
>>>> On Wed, Apr 5, 2023, 12:22 Jonathan Hao <[email protected]> wrote:
>>>>
>>>>> Note that Private Network Access is in the process of being renamed to
>>>>> Local Network Access, so you may see inconsistent names for the time 
>>>>> being.
>>>>>
>>>>> Explainer
>>>>>
>>>>> https://github.com/WICG/local-network-access/blob/main/explainer.md
>>>>>
>>>>> Specification
>>>>>
>>>>> https://wicg.github.io/local-network-access/#secure-context-restriction
>>>>> <https://wicg.github.io/local-network-access>
>>>>>
>>>>> Design docs
>>>>>
>>>>> Local Network Access: Allow Potentially Trustworthy Same-Origin Fetches
>>>>> <https://docs.google.com/document/d/1XopQKc6sR-2URgKqEleb-XNjcSPOjTI-E5qRxWGBuTY/edit#heading=h.y2euwddkcot>
>>>>>
>>>>> Private Network Access: Preflight requests for subresources
>>>>> <https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit>
>>>>>
>>>>> Summary
>>>>>
>>>>> Allow same-origin local network fetches to potentially-trustworthy
>>>>> origins and do not send preflights for them. We currently send preflights
>>>>> before all local network requests, but ignore the results, as proposed in 
>>>>> Intent
>>>>> to Ship: Private Network Access preflight requests for subresources
>>>>> <https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/72CK2mxD47c/m/5mkboUneAwAJ>
>>>>> .
>>>>>
>>>>
>>> Can you expand on this change? Would this result in not sending
>>> preflights IFF their origin is the same as the document's origin?
>>>
>>
>> Yes. Preflights will not be sent iff the origin is the same as the
>> documents' origin and the origin is potentially trustworthy.
>>
>> Would this also work for embedded documents? (resulting in a single
>>> preflight for the document's resource, but not subresource)
>>> Or would it be restricted to cases where the user explicitly went to a
>>> local network top-level document? (Or something else entirely, and I
>>> misunderstood)
>>>
>>
>> Yes it works for embedded documents too. The preflight for iframe
>> navigation is being worked on separately in https://crbug.com/1291252.
>> If the subresource is same origin to the embedded document then it doesn't
>> require additional preflights.
>>
>>>
>>>
>>>>
>>>>> Blink componentBlink>SecurityFeature>CORS>PrivateNetworkAccess
>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature%3ECORS%3EPrivateNetworkAccess>
>>>>>
>>>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/572
>>>>>
>>>>> TAG review statusIssues addressed
>>>>>
>>>>> Risks
>>>>>
>>>>> Interoperability and Compatibility
>>>>>
>>>>> This change reduces the compatibility risk of enforcing preflight
>>>>> results on private network requests as we now send fewer preflights for
>>>>> private network requests, so it’s less likely to break websites.
>>>>>
>>>>> Gecko: No signal about this specific change.
>>>>>
>>>>> WebKit: No signal about this specific change.
>>>>>
>>>>> Web developers: No signal about this specific change, but they should
>>>>> be happy since this reduces compatibility risks.
>>>>>
>>>>> Other signals:
>>>>>
>>>>>
>>>>> Ergonomics
>>>>>
>>>>> None.
>>>>>
>>>>>
>>>>> Activation
>>>>>
>>>>> We plan to ship this change directly to M114 as this relaxes the
>>>>> previous restrictions.
>>>>>
>>>>> Security
>>>>>
>>>>> This change is limited to potentially trustworthy origins. Proof of
>>>>> certificate protects users from DNS rebinding.
>>>>>
>>>>> WebView application risks
>>>>>
>>>>> There’s no plan to ship Local Network Access on WebView.
>>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>> Will this feature be supported on all six Blink platforms (Windows,
>>>>> Mac, Linux, Chrome OS, Android, and Android WebView)?No
>>>>>
>>>>> Not on Android WebView given previous difficulty in supporting PNA
>>>>> changes due to the lack of support for deprecation trials. Support for
>>>>> WebView will be considered separately.
>>>>>
>>>>>
>>>>> Is this feature fully tested by web-platform-tests
>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>>>> ?No
>>>>>
>>>>> DevTrial instructionsNo DevTrial for this change
>>>>>
>>>>> Flag name
>>>>>
>>>>> LocalNetworkAccessAllowPotentiallyTrustworthySameOrigin
>>>>>
>>>>> Requires code in //chrome?
>>>>>
>>>>> Only for metric logging
>>>>>
>>>>> Tracking bug
>>>>>
>>>>> https://crbug.com/1382068
>>>>>
>>>>> Launch bug
>>>>>
>>>>> https://crbug.com/1274149
>>>>>
>>>>>
>>>>> Estimated milestones
>>>>> DevTrial on desktop 114
>>>>> DevTrial on Android 114
>>>>> Anticipated spec changes
>>>>>
>>>>> Open questions about a feature may be a source of future web compat or
>>>>> interop issues. Please list open issues (e.g. links to known github issues
>>>>> in the project for the feature specification) whose resolution may
>>>>> introduce web compat/interop risk (e.g., changing to naming or structure 
>>>>> of
>>>>> the API in a non-backward-compatible way).
>>>>>
>>>>> None
>>>>>
>>>>> Link to entry on the Chrome Platform Status
>>>>> https://chromestatus.com/feature/5737414355058688
>>>>>
>>>>> Links to previous Intent discussions
>>>>> Intent to prototype:
>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/ArrhiKB8XF0/m/cGO-5B1IAwAJ
>>>>> Intent to prototype (all preflights):
>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/PrB0xnNxaHs/m/jeoxvNjXCAAJ
>>>>> Intent to Experiment (all preflights):
>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOC%3DiP%2Bew8hADZkdQ3AO6P9WzfGuzLPp9JjJZqztV5oZmaK8oQ%40mail.gmail.com
>>>>>
>>>>>
>>>>> This intent message was generated by Chrome Platform Status
>>>>> <https://chromestatus.com/>.v
>>>>>
>>>> --
>>>> 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/CABsQ2jGAcTV4CUKKwsYYfnQRiQ_W6KK9L4OQ5uNHNGn3WMhZ5Q%40mail.gmail.com
>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABsQ2jGAcTV4CUKKwsYYfnQRiQ_W6KK9L4OQ5uNHNGn3WMhZ5Q%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/CAOC%3DiPLfTRMRBp56AY-DTAAke5kx6dKVfKqc8c6RXVr7tu3MqQ%40mail.gmail.com.

Reply via email to