Network Information status?

[anssiko]

The DAS WG charter states:

Network Information API

An API to discover the current network characteristics — the group will determine in collaboration with the WICG whether the existing implementations of this API on mobile warrants restarting its standardization process

Need to figure out whether this requirement is satisfied or not.

High-level implementation status suggests there's probably adequate implementation experience:
https://caniuse.com/#feat=netinfo
https://developer.mozilla.org/en-US/docs/Web/API/Network_Information_API

Loop in @marcoscaceres for WICG input.

[marcoscaceres]

I think we should reconsider what is feasible in adopting the netinfo API. The API is overly ambitious in that goes beyond the original use cases and requirements, and I think that's a problem for adoption because of all the privacy concerns: it adds a large fingerprinting area.

The primary use cases are well understood (again, see the use cases and requirements). If we could just solve for "is this a metered connection?" that would be a huge win. Secondary case of "don't download large files" might be handled by other APIs... for example, in theory Fetch could intercept a response, check the expected size, and ask the user if they really want to download such a big file.

Anyway, I don't mean to get into the details here, just want to caution that Mozilla will object to taking the Netinfo API as is. We'd probably want some assurance that the scope of that API will be reduced to something less ambitious (specially in light of other recent API additions to the platform that serve a similar purpose).

[anssiko]

(Connecting the dots: Web & Networks Interest Group is soliciting feedback on this API from its participants: https://lists.w3.org/Archives/Public/public-networks-ig/2020Mar/0002.html)

[reillyeon]

Given the objections above I think we should let this specification continue incubating until cross-vendor concerns are resolved. When it comes time for migration I believe the WebPerf WG may have more experience with the use cases being resolved than the DAS WG.

[anssiko]

We concluded in #84 to make no changes to this API vis-à-vis the current charter, i.e. keep the provision we work together with WICG to determine whether this API should progress on to the standards track.