Intent to Ship: Private network access warnings for workers

[Jonathan Hao]

Contact emails

tit...@google.com, l...@chromium.org, ph...@chromium.org

Specification

http://wicg.github.io/private-network-access

Design docs

https://docs.google.com/document/d/1fFSY8bExYZvKTDBBS0flry6E6Ihn63HOr0JhD2fB7ko/edit

Summary

This feature applies Private Network Access checks to web workers: dedicated workers, shared workers and service workers. These checks apply to all worker-specific fetches: - initial worker script fetch - fetch within workers - service worker script update fetch

In this first step, we'd like to ship warnings in DevTools to M110 when the above fetches happen.  Currently, 0.000319% of worker script fetches [1] and 0.043019% of the fetches within workers [2] are private network access.  We think we can drive the number further down if we show warnings in DevTools. We're also looking into allowing same-origin or same-site requests, as Titouan mentioned in this thread https://groups.google.com/a/chromium.org/g/blink-dev/c/FlenxUPCDec/m/C9LuRoQQAwAJ.

[1] https://chromestatus.com/metrics/feature/timeline/popularity/4145

[2] https://chromestatus.com/metrics/feature/timeline/popularity/4150

Blink component

Blink>SecurityFeature>CORS>PrivateNetworkAccess

TAG review

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Gecko: Worth prototyping (https://github.com/mozilla/standards-positions/issues/143)

WebKit: No signal

Web developers: No signals

Other signals:

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?

Debuggability

TODO

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No

Not enabled by default on Android WebView due to the lack of support for deprecation trials.

Is this feature fully tested by web-platform-tests?

No

Flag name

PrivateNetworkAccessForWorkers

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1371454

Estimated milestones

M110 to M112

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).

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5742979561029632

This intent message was generated by Chrome Platform Status.

[Chris Harrelson]

LGTM1 to add these warnings.

I assume you'll come back to the other intent with the results regarding whether the use counter went down as a result?

--
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 blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOC%3DiPK3PjhegFsCw8SPgddOzZJUZcwzAP2Z99AKG5KXgS%3DGjg%40mail.gmail.com.

[Jonathan Hao]

Yes, Chris.  We're going to add UseCounters to see how many of the private network requests are same-origin or same-site, which we can safely allow in secure contexts.

[Yoav Weiss]

LGTM2 for devtools warnings in this case. Should we also consider deprecation reports?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOC%3DiPKgWxJdQ7rG4gOan9XV_CN%2BwzR8LDUrYvVGU0nGb-NoNw%40mail.gmail.com.

[Rick Byers]

LGTM3 to deprecate (add warnings). 

On Wed, Nov 16, 2022 at 11:30 AM Yoav Weiss <yoav...@chromium.org> wrote:

LGTM2 for devtools warnings in this case. Should we also consider deprecation reports?

Good question. I asked about this for the broader removal (as NEL) here. I'll follow up on that thread, not specific to workers IMHO.

On Fri, Nov 11, 2022 at 2:23 PM 'Jonathan Hao' via blink-dev <blin...@chromium.org> wrote:

Yes, Chris.  We're going to add UseCounters to see how many of the private network requests are same-origin or same-site, which we can safely allow in secure contexts.

On Thu, Nov 10, 2022 at 5:40 PM Chris Harrelson <chri...@chromium.org> wrote:

LGTM1 to add these warnings.

I assume you'll come back to the other intent with the results regarding whether the use counter went down as a result?

On Thu, Nov 10, 2022 at 7:06 AM 'Jonathan Hao' via blink-dev <blin...@chromium.org> wrote:

Contact emails

tit...@google.com, l...@chromium.org, ph...@chromium.org

Specification

http://wicg.github.io/private-network-access

Design docs

https://docs.google.com/document/d/1fFSY8bExYZvKTDBBS0flry6E6Ihn63HOr0JhD2fB7ko/edit

Summary

This feature applies Private Network Access checks to web workers: dedicated workers, shared workers and service workers. These checks apply to all worker-specific fetches: - initial worker script fetch - fetch within workers - service worker script update fetch

In this first step, we'd like to ship warnings in DevTools to M110 when the above fetches happen.  Currently, 0.000319% of worker script fetches [1] and 0.043019% of the fetches within workers [2] are private network access.

Do these UseCounters just count private network accesses generally? Or specifically the case you want to break - private network access from within a public network resource? Also these are UseCounters, so I believe they're a function of page loads (even for workers), not a % of all fetches. 0.05% of page loads is non-trivial, so like for the broader intent I

 

  We think we can drive the number further down if we show warnings in DevTools.

FWIW I'm always skeptical of such hope, I think we've generally found the effect of warnings to be limited in the past (just open a few major websites and look at how many warnings already exist in the console!). To me the primary reason to give warnings is not to drive down usage, but to show that we've done everything reasonable to warn folks before we make a breaking change and reward the small minority who do pay attention and engage with warnings they see. We do sometimes learn about use cases and better mitigation strategies from a few developers when they see a warning and click through chromestatus to the bug to provide feedback.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWRzpt4rFiGg3jEJaievgN4yxEQAk4gx4EStDHVq-PqkQ%40mail.gmail.com.