Three changes have been suggested in the network quality exposed via JS API. The goal here is to reduce the chances for cross-origin fingerprinting:

1. Up to 10% random noise should be added to the network quality estimates before exposing it via Javascript API. The noise should be a function of the hostname, and the noise should remain constant for a given hostname.

2. The current bucket size in the network quality estimates is 25 msec (for RTT) and 25 Kbps (for downlink). This means currently the estimate is rounded off to the nearest 25 msec or 25 kbps before exposing it via JS API. The bucket size can be updated to 50 msec / 50 kbps.

3. The upper limit on the estimates should be added. For RTT, the upper limit can be 3000 msec, and for kbps it can be 10000 kbps.

What purpose does the ConnectionType part of this API provide? What can I do with the information that a user is on WiFi vs cellular vs Ethernet? That information is completely useless to me as any of these connection types can be either metered or unmetered.

The only use I can see for ConnectionType is to assume that some connection types are metered, which will only harm the minority of users like me with metered WiFi and unmetered cellular data.

The "published version" link in https://w3c.github.io/netinfo/ points to http://www.w3.org/TR/netinfo/ which returns a 404. http://www.w3.org/TR/netinfo-api/ exists but is a shelved spec. Should the "published version" link be updated or just removed?

The spec currently says that connection.type === "none" is for when the connection is

explicitly disabled, such as in "airplane" mode

I think it should be used whenever we know that we have no connection, i.e. whenever navigator.onLine === false.

Android supports wimax and it would be nice to provide a max download speed for it from the spec.

There are times where it's difficult for the UA to determine what the connection type is. What should be the connection type in those cases? Unknown is more accurate than other.

navigator.connection.addEventListener('onchange', changeHandler)

should be

navigator.connection.addEventListener('typechange', changeHandler)

Also note the lack of "on".

The way the links in the table are broken. We need to let ReSpec automatically link those up instead.

I'll need to rewrite how that works. Just lodging this as a reminder to do that.

The current API draft differentiates between cellular and other connection types -- but not among "fast" and "slow" cellular connection types.

While the sheer existence of a 3G (and up) connection does not mean the data is actually transmitted at high speeds, there is a substantial difference between what you can do on 2G and what you can do on 3G and up.

I posit that the same kind of usecase that drives me (as a developer) to know if you're on cellular or not will only really be served if I can determine (with a certain level of confidence) what kind of connection you are on.

(This does not absolve me from the responsibility to treat bandwidth with respect -- fast data does not equal unmetered or free data -- but that's not the case for wifi either.)

NetInfo thresholds for different effective connection types were decided more than a year ago. Since then, we have collected more metrics and have more visibility into how the API is being used. We should analyze the recent data and update the network quality thresholds based on that.

Few things that I can think of at the top of my mind:

1. Consider combining the slow-2g + 2g labels.
2. Consider making the threshold for 2g more aggressive.
3. Consider splitting 3g into two different catergories: Slow3G and Fast 3G.

The latest draft currently defines the following connection types that can be returned by this API [1]:

• ethernet
• wifi
• bluetooth
• cellular
• unknown
• other

In this list it is unclear what the use cases are for a web developer in being able to distinguish between Ethernet, WiFi and Bluetooth. AFAICT, no use cases have been presented yet that would require this distinction [2].

Connection types should be exposed to the web platform on a use-case-driven basis.

So do we have compelling use cases for Ethernet vs WiFi vs Bluetooth and does this distinction need to be maintained in the spec?

[1] http://w3c.github.io/netinfo/#connection-types
[2] NetInfo use cases @ https://github.com/w3c-webmob/netinfo-usecases#web-applications

Spun off of #4.

As said on Twitter, I'd group the network types by what type of network category they represent:

1. cellular, as in GSM,
2. local, as in local area network, i.e. both Ethernet and WiFi,
3. personal, as in personal area network, like Bluetooth, IrDA, USB Wireless, etc.,
4. unknown, as in "cannot be detected or is none of the types above".

This classification does not make any assumptions about connection speed or cost. It may however point to the stability (as in location) of the network and its participant: In cellular networks, participants are to be expected to move constantly (thereby hopping from cell to cell), while a LAN is (mostly) a fixed infrastructure, and participants are always within range of the one hub/router. A personal area network indicates close proximity to a low power networking device, and both participants and the networking device itself are highly mobile (i.e. are likely to move around like with BT tethering on a train). This leaves the last option to be unknown.

This classification has the following advantages:

• does not distinguish between WiFi and wired (while introducing a possible language for the prefs, i.e. "Only download in local network?"),
• does not introduce awkward API inconsistency (e.g. BT vs cellular),
• spec is forward compatible (also backwards compatible with obsolete networking stuff, bonus points for me!) with pretty much any connection type imaginable, i.e. does not require to add new enum types for entirely new ways to network,
• does not discriminate by connection speed, technology/protocol, or stability (as in signal) thereby sidestepping the footgun (at least theoretically),
• covers more edge cases (see printer example below),
• allows for ad-hoc networks / WiFi Direct (as commonly used in tethering[1]) to be classified as a personal area network.

The last point is essential. The hardware can tell whether the (WiFi) networking device is in ad-hoc mode (and I think the same is true for WiFi Direct) thus this information can be (and is) exposed via API which the user agent can hook into to determine the correct connection type. Note that the personal type may kick in when you have no Internet connection at all (e.g. isolated laptop-to-laptop network), and that is OK and expected (this allows covering edge cases for apps, e.g. the printer app acts differently when you're connected to your printer via WiFi Direct).

Now, there is value in knowing what "protocol" the connection is using, because surfing via GPRS is vastly different than surfing via 3G or LTE (or even EDGE), and Ethernet is different to WiFi or Bluetooth – the valuable quantities being (max.) bandwith and latency (I'm wondering why latency seldomly was an issue for these APIs) – but let's cover that in a different bug.

[1] There are exceptions, of course: I have a battery-powered WiFi router with a cellular modem (let's call it a MiFi) which quacks like a stationary router – though I specifically bought it to have high-bandwith low-cost internet when I'm abroad, i.e. I buy a local prepaid SIM to use with the MiFi. Similar situations are encountered in rural regions where the only way to have a satisfactory internet connection in homes (i.e. stationary) is to use 3G or LTE routers. In these cases, the network participant expects its connection to act like a stable, high-quality, and (for all intents and purposes) low-cost connection like DSL et al. I.e., this case is covered by the local type.

PS: There is one more connection type I'd like to mention: landline AKA modem AKA gosh-we-are-not-in-the-90s-anymore – unfortunately, this type is not uncommon even in developed countries, and I'd like to see it covered by the spec. This may fall under the cellular type (as it is comparable to GPRS or EDGE) or be its own type (thereby raising awareness for this issue among developers) though I have no idea what color the bikeshed should have … technically, DSL is also landline so that's probably not a good name, modem is not sufficient as well. Or just treat it as unknown and deal with it another time.

-- also see answers to original comment

Clarification about the term "cellular" vs. "mobile":

In technical terms, a cellular network is about "cells" where each cell is a logically separated area and users are an entity that moves between cells when they change their location. Huge WiFi networks with multiple APs basically extend the range of one network, the topology is like a (wired) LAN network with a flat or tree structure – it's a centralized structure whereas cellular behaves more like a WAN with independent nodes.

"Mobile" in itself doesn't say more than "not a fixed thing" and may not denote the right meaning. It's not interchangeable with "cellular".

cellular is a technology while "local" and "personal" are user-centric

They are a classification of range and stationarity (assuming I use the right term here), not user-centric (in this context). local and personal may also denote a technical classification (as in LAN & PAN), IMHO. I agree that cellular is a bit inconsistent here, though, but I think this is our only option, unfortunately.

If there is a "true" cellular mode available for 801.11 in the future (e.g. for municipal wireless networks, WiMAX?), it should probably fall under the cellular category.

(Disclaimer: I'm not familiar with the technical details but this is how it "feels" like. The bikeshedding is my personal opinion but I feel strongly for the cellular vs local vs personal distinction.)

FTR, here's some discussion on Twitter: https://twitter.com/marcosc/status/440107446766272513

Also note issue #7 which aims to introduce an API for querying the exact link type covering edge cases.

/cc @slightlyoff, @marcoscaceres

Could you please clarify which ConnectionType is to be reported in case a device is tethered? For example, tethering a laptop to a phone might happen over wifi and thus technically "wifi" would be the correct ConnectionType, however the effective connection type that governs the properties of the connection (speed, latency, cost) and that matches the representation in the mind of the user most probably would be better described by "cellular".

(For example Chrome OS interprets the spec quite literally and reports "wifi" for tethering, cf. https://bugs.chromium.org/p/chromium/issues/detail?id=728065.)

Source: https://groups.google.com/a/chromium.org/d/msg/blink-dev/tU_Hqqytx8g/HTJebzVHBAAJ

Knowing that a users' downlinkMax is changing can reveal information about what the user is doing (e.g. assuming we get it accurate, via NQE) or where the user is going - watching the user transition from cellular to wifi, for example, may reveal once a user is outside an office building, and watching the user transition from cellular 2g to cellular 3g to cellular 2g, along with other ambient sensors of a device (such as accelerometers, via http://w3c.github.io/deviceorientation/spec-source-orientation.html ) could reveal a user as they transition from cellular towers or move around a city.

NetInfo API exposes rtt/downlink/effectiveType attributes which are user agent's estimate of the network quality. The spec should specify the network layer at which these attributes should be computed.

From, blink-dev thread, @bzbarsky:

For the "cell phone talking to a cell tower" case, this API always reports "cellular" as the connectionType. That tells you absolutely nothing; it might be 2g or it might be 4g.

So even for the one use case when the first hop is at least likely to be the constraint on the connection, this API lumps in the cases when it is with the ones when it's not. And of course whether the first link is "ethernet" or "wifi" is really no one's business and no use on its own as a piece of information.

The downlinkMax attribute does report more fine-grained information, of course. But I still see no need for distinguishing between the various kinds of "wifi", or the various forms of "ethernet". There might be something to say about the different "bluetooth"s. But is there a practical reason to distinguish between CDMA and 1xRTT, say?

I, personally, would be much happier if we had a few buckets for the downlinkMax, insteaad of a huge table of lots of possible values. For the use cases I've seen described that would be sufficient.

The Accept-CH header is currently included by origin servers in HTTP responses if they are interested in receiving client hints from the browser (e.g., DPR). The spec currently does not require browsers to persist the opt-in across browser restarts. This means that if the origins are interested in receiving hints on all requests, then they need to include the Accept-CH header on all responses. This has two disadvantages: (i) Browsers currently fail to include the hints on the first request after the browser restart; and, (ii) It may not be possible for the origin servers to include the Accept-CH header on all responses due to responses being served out of different endpoints (CDNs etc.).

To fix this: The Accept-CH header should also support a max-age header value which indicates for how long should the browser remember this opt-in (including across browser restarts). A value of max-age set to 0 should cause the browser to stop sending client-hints to the origin. As an example,

Accept-CH: feature1, feature2, max-age=86400

would imply that the browser should include hints feature1 and feature2 for next 86400 seconds for that origin.

1. The table is not showing up and CSS styling for tables is missing?
   • Is there a cleanup step that's running on the table that's breaking our JS logic to populate the data?
   • When I create a new table, I don't see any CSS formatting for it.
2. Separately from above, it looks like new version of respec is throwing a lot of dfn warnings

@marcoscaceres any tips for either of the above?

Because OSs conceptually separate “metered network” from “data saver”, it is still worth including both of those two properties as available settings.

• Windows 10 supports marking networks as metered
• Recent Android versions detect networks that advertise themselves as metered networks, allow users to mark networks as metered manually, and recommends developers detect metered networks in conjunction with Data Saver to save data.

This was originally opened as #41, but the author closed the issue themselves. Please feel free to move discussion back to that issue if it would be better.

The spec currently says:" ...based on recently observed application-layer RTT measurements across recently active connections...". Some developers have interpreted this to mean that the returned RTT reflects the transport layer RTT, and is computed using the application layer RTT. This is an incorrect interpretation.

We should update the spec to make it clearer that this is measured at application layer, and remove any room for confusion.

Going through the use-cases http://w3c-webmob.github.io/netinfo-usecases/

4.1, 5.7, 5.9, 5.12, 6.4, 6.5, 6.6, 6.10, 6.11 "Avoid autoplay and/or warn on play/download": Better handled by the browser. It can prevent autoplay & warn when playback/download starts, the user can dismiss the notification across all sites permanently. This means we fix the existing web, rather than providing an API and hoping developers use it (in the right way).

4.2 Gmail: This use-case is already well handled adaptively. I don't think this is a use-case for netinfo.

4.3 Carrier billing: This would be better adaptive. Attempt to id the sim, if that fails, ask for number.

5.1, 5.2, 5.3, 5.4, 5.5, 5.8, 6.1, 6.2, 6.3, 6.7, 6.8, 6.9, 6.12, 6.13, 6.14, 6.15, 6.16, 6.17, 7.1 "Only use Wifi please for background updates": These use-cases are less relevant as we don't have background updating yet. But still, I'd like web sites to appear in OS-level settings like this. If background updates are handled in something like the ServiceWorker, the permission request could ask the user what connections they'd like the app to be able to use. "This site would like to update in the background. Allow? yes / yes, wifi only / no"

5.6 NPR: This is better done adaptively

5.10 Tweetbot streaming: Is this valid? Is streaming a bad thing on 4g?

5.11 iOS messaging: Better done adaptively. Use SMS on iMessage connection failure.

That's all of them. The variation and inconsistency of this in native apps is a bad thing. If a go from a metered plan to an unmetered one, having to change these settings app by app is a bad experience. The OS should control this, as it can also track data usage across all applications and warn me if I'm getting near limits I have set.

I understand the desire to match native, but in this case we'd be matching a flaw when we could be doing something better.

In the case where we have feedback from the network interface, or some other "network quality estimator" implementation, about performance of the upper bound of the downlink speed... Should we recommend some thresholds for triggering onchange updates?

For example, if we're on a WiFi link and signal quality is continuously changing and thus affects the upper bound, we probably don't want to trigger updates unless we pass some "meaningful" threshold? Knowing that we went from 20Mbps -> 19.9Mbps is arguably not meaningful and may result in a lot of unnecessary events?

Similarly, should these threshold change if and when the page is not visible? We'd have to account for worker contexts here as a separate case, as those are never "visible".

I created a proposal that is intended to extend to edge cases my proposal in issue #4 does not cover – though it does not replace it. It may look like a step back but it's about enabling developers while keeping sane defaults / recommendations.

See: https://gist.github.com/fbender/9322762

I think this incubation might have run its course as it hasn't successfully gained the cross browser support we had hoped for in the last 7 years. Thus, I'd like to propose archiving this incubation.

Mozilla remains fairly opposed to this work (with the rationale being that it is "harmful"):
mozilla/standards-positions#117

I'm not sure WebKit folks have taken a stand on it. @othermaciej?

cc @WICG/chairs

Hi, downlinkMax has type "Megabit", but the table lists "+Infinity" as a valid value.
My real problem is that in testing the browser reports Infinity but JSON stringify translates that to null. I can easily work around, just wanted to raise this.

Oops, wrong repo. Reposted to w3c/das-charter#78

I propose to have this WebIDL interface instead 2 separate ones:

[NoInterfaceObject, Exposed=(Window,Worker)]
interface NavigatorNetworkInformation {
   ...
};

Navigator implements NavigatorNetworkInformation;
WorkerNavigator implements NavigatorNetworkInformation;

From: https://groups.google.com/a/chromium.org/d/msg/blink-dev/tU_Hqqytx8g/BeB5MsxbAwAJ

On Wed, Sep 30, 2015 at 12:43 PM, Yoav Weiss [email protected] wrote:
We definitely should give developers the raw bandwidth and RTT data and let them build bandwidth estimation on top of that (assuming it has no privacy concerns). But that raw data cannot be exposed as a single point in time while expecting for it to be useful. We should expose such data as the continuous stream that it is, most probably on top of PerformanceTimeline.

On Thu, Oct 1, 2015 at 2:30 PM, Ryan Sleevi [email protected] wrote:

On Thu, Oct 1, 2015 at 2:18 PM, Ilya Grigorik [email protected] wrote:

On Thu, Oct 1, 2015 at 1:17 AM, Yoav Weiss [email protected] wrote:
Looking at the current processing model for onchange, it becomes even more obvious that the current spec cannot sit well with NQE based estimations as the downlinkMax value should change only when the underlying network connection changed, and when it does, onchange should fire.

"If the underlying connection technology changes (in either connection type or maximum downlink speed)" [1] ... Hmm, I think I see where I confusion is. My claim that we're NQE-compatible is based on "or maximum downlink speed changes" reading of above sentence, where "maximum downlink speed" is allowed to be adjusted based on network weather. Admittedly, not the greatest wording (I'm to blame :-)). I do agree that we should not limit notifications to changes to "underlying connection type".

"If the properties of the connection change (e.g. changes in connection type, downlink speed, or other criteria), the user agent must run the steps to update the connection values..." ~~ would something like that clarify our intent?

I think it's still unclear whether or not we want the singular value to be NQE-compatible. You've put forward the argument it can be (with slight spec changes), but from Alex's remarks, and from Yoav's, and from mine, I think there's some concern that making it NQE compatible makes it less appealing to developers.

The "what's new" section says onchange has been renamed to ontypechange. Later in the spec it's referred to as onchange. That appears to be a recent change. Which is it? Note that Chromium has already released with ontypechange months ago.

The document is missing a word in the following sentence:

This document was published by the Web Incubator Community Group as a .

as you can see, there is a missing word before the "as a" and the period.

The spec has [Exposed=Window,Worker] on the NetworkInformation interface, implying that the API is supposed to be available in workers. Yet it only defines a connection attribute on Navigator, not on WorkerNavigator. Is this an oversight? (For what it's worth chrome seems to implement it for WorkerNavigator as well).

A kilobyte is 1024 bytes.

The Save-Data client hint (described here in more detail by @igrigorik), exposes information that would be useful outside of the context of handling a HTTP request. For instance, a service worker might use the client hint to determine, as part of its install handler, whether to precache a heavy- or lightweight bundle of resources.

Exposing this information from within the NetworkInformation interface means that a service worker and other scripts could access it via navigator.connection.

OSs allow connections to be marked as "metered".

Discuss.

NetInfo API exposes rtt, downlink and effectiveType attributes. It is possible that the user agent does not have a valid estimate of one of some of these attributes. For example, this may happen when the user agent has just started, or if the information is unavailable on certain platforms. The spec should specify the values for each of these 3 attributes that the user agent should return when a valid value is unavailable.

Just started using this API and noticed that sometimes I see downlinkMax=Infinity or downlinkMax=undefined when the connection.type="wifi". The spec doesn't list Infinity/undefined as an option for "wifi", so I am wondering if this is a spec bug or implementation bug?

Infinity

• Mozilla/5.0 (Linux; Android 5.1.1; SAMSUNG-SM-G530AZ Build/LMY48B) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.124 Mobile Safari/537.36
• Mozilla/5.0 (Linux; Android 7.0; Nexus 5X Build/NRD90R) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.124 Mobile Safari/537.36

Undefined

• Mozilla/5.0 (Linux; Android 6.0.1; SAMSUNG SM-G900P Build/MMB29M) AppleWebKit/537.36 (KHTML, like Gecko) SamsungBrowser/4.0 Chrome/44.0.2403.133 Mobile Safari/537.36

Edit: Moved to this PR.

The IDL block in https://wicg.github.io/netinfo/#-dfn-networkinformation-dfn-interface is:

[Exposed=(Window,Worker)]
interface NetworkInformation : EventTarget {
  readonly attribute ConnectionType type;
  readonly attribute EffectiveConnectionType effectiveType;
  readonly attribute Megabit downlinkMax;
  readonly attribute Megabit downlink;
  readonly attribute Millisecond rtt;
  readonly attribute boolean saveData;
  attribute EventHandler onchange;
};typedef unrestricted double Megabit;typedef unsigned long long Millisecond;

Note the lack of newlines at the end. This doesn't match the source and is probably a ReSpec bug, but I don't know so am filing a bug here first.

Interface mixins are not exposed through language bindings, so I believe [NoInterfaceObject] can be dropped from NavigatorNetworkInformation mixin. There's an ongoing effort to remove [NoInterfaceObject] from WebIDL whatwg/webidl#609

@annevk this spec was not tracked in whatwg/webidl#430

navigator.connection.type -> cellular does not provide sufficient information to optimize for different connection types. For example, significant portion of mobile users in India are still (and will continue to be) on 2G networks. Similarly, there is a world of a difference between 2.5G, 3.5G, and 4G.

The ability to distinguish between these connection types is important for analytics (w3c-webmob/netinfo-usecases#65), and content adaptation - e.g. segmenting navigation and purchasing behavior, or serving an alternative experience for users on older generation networks.

One way to address this is to break apart type -> cellular into more fine-grained buckets. However, the downside to this approach is that we then have to agree on what that enum should be, and we'll have to update it once new connection types become available. Instead, I suggest we add a 'max theoretical bandwidth for this connection type' attribute, which exposes a single value in Kbps or Mbps... Which, incidentally, is exactly how FF originally implemented the bandwidth attribute defined in previous version of the spec: http://hg.mozilla.org/mozilla-central/rev/e652d673382f#l2.56

tl;dr:

• Introduce new attribute to expose max theoretical bandwidth for current (last hop) connection type.
• This attribute would expose a more fine-grained estimate than type - i.e. take into account generation of the cellular network, ethernet link-speed, etc.
• This attribute should have consistent units: kbps or mbps.
• This attribute should have a name that clearly indicates that it is not providing an estimate of end-to-end bandwidth, but is indicating the maximum theoretical bandwidth based on last hop connection type - i.e. it should not be called bandwidth. Instead, bandwidthCeiling or some such.

Also, yes, this attribute should be used carefully. It is not an indicator of end-to-end bandwidth, nor should it be used as such, but it is still a very useful signal as it places an upper bound (ceiling) on what the network can deliver, which is particularly useful and important for improving user experience on old(er) generation networks.

We have lots of links around the web pointing to w3c.github.io version..

What is this?

This is a proposal for a new HTTP request header and an extension to the Network Information API to convey the HTTP client's network connection speed.

• The header specifies the service level provided by the client's network connection. Levels of service are broken down into effective connection types (ECTs), which bin measured network characteristics such as round trip times and available bandwidth by the cellular connection technology with the most
  similar typical performance.
• The API extension provides the same information as the header, and additionally provides an estimate of the current round trip time (RTT) measured at the transport layer.

By default, the header will be sent only on slow network connections that perform as slow or slower than typical 2G connections.

Why do we care?

Web servers and proxies benefit, because they can tailor content to network constraints. For example, on very slow networks, a simplified version of the page can be provided to improve document load and first paint times. Likewise, higher-bandwidth activities like video playback can be made available only on
faster networks. Users benefit by being offered only that content that they can consume given network constraints, which results in faster paints, and less frustration.

Goals

The goal of the header and API is to provide network performance information, as perceived by the client, in a format that's easy to consume and act upon. The header's aim is to convey a level of performance in an intuitive format at a granularity that is coarse enough to key cache entries based on its value. The header aims to allow proxies and web servers to make performance-based decisions, even on the first request. The API extension aims to make it easy to make such decisions from within JavaScript. And the RTT API's aim is to provide more precise performance information for more sophisticated consumers.

Non-goals

We do not plan to convey the actual connection type used, because it is already available via the Network Information API's downlinkMax and its mapping to underlying connection technology, and it is not as actionable as the providing
the performance of the connection. E.g., a Wi-Fi or 4G connection can be slower than a typical 2G connection at times. We also do not aim to convey the flakiness (or variability) of the connection quality.

Header

Network speed is determined by mapping the estimated network performance to the most similar cellular connection type.

network-speed = "Network-Speed" ":" effective-connection-type  
effective-connection-type = "slow-2g" | "2g" | "3g" | "4g" 

The effective connection type (ECT) should be determined using a combination of transport layer round trip time and bandwidth estimates. The table below describes the initial mapping, which currently does not incorporate bandwidth.

The above mapping was computed from the RTT samples observed by Chrome over different connection types and network technologies (e.g., EDGE, GPRS). Thus, the mapping is independent of the variation in the characteristics of network technologies of different countries.

The Network-Speed header is designed to work with the Vary response header (rfc7234) to support caching keyed on network performance level.

When is the header sent?

Browsers should by default only send these headers when ECT is slow-2g or 2g. Via a to-be-determined mechanism, servers might request Network-Speed on faster networks, on a per host basis. Client Hints provides a mechanism for a server to advertise interest in a client's contextual data, but as a response header it cannot be used to enable providing network performance data on the first request.

Network Information API extension

The Network Information API provides read only attributes that contain the connection type (e.g., wifi, cellullar, ethernet) and the maximum downlink speed of the underlying connection technology in Mbit/s, as well as a way for workers to register for connection change events. In addition, the API will be extended to provide effective connection type and RTT estimates:

partial interface NetworkInformation : EventTarget {  
  readonly attribute EffectiveConnectionType effectiveType;  
  readonly attribute Milliseconds rtt;  
}

EffectiveConnectionType has the values: offline, slow-2g, 2g, 3g, 4g. These mirror the Network-Speed values, except for offline, which is only available via API.

RTT provides developers with higher fidelity information for developers who want to finely tune their experience. RTT is rounded to the nearest 10ms to protect against fingerprinting attacks.

Browsers can compute the RTT estimate by computing median of the RTT observations across all transport-layer sockets. If the transport-layer sockets are managed by the operating system, then the browser can query the APIs provided by the platform that expose RTT estimates for individual sockets. Alternatively, if the browser does not have access to the RTT estimates via the platform APIs, they can approximate transport RTT with app-layer RTT.

In Chrome 72:

> JSON.stringify(navigator.connection)
{}

It seems useful to define standard .toJSON() on NetworkInformation as for example PerformanceEntry is doing, so that stringify shows something useful.
https://www.w3.org/TR/performance-timeline-2/#dom-performanceentry-tojson

When toJSON is called, run [WebIDL]'s default toJSON operation.

https://wicg.github.io/netinfo/#dom-networkinformation-rtt

This is what the implementation in Chromium does, but starting from the spec I can't find that this should be the case.

Should it be the case? Maybe the value matching the effectiveType should be used? https://wicg.github.io/netinfo/#effective-connection-types

Following up from discourse...

@dontcallmedom, could you kindly transfer ownership to the WICG or grant me admin rights for this repo. I'm happy to do the transfer.

@annevk just pointed me to this document (via dret/webconcepts#49). since it does define new header fields, it should have an IANA considerations section with the appropriate registrations. i'd be happy to help with that.

The first two lines in EXAMPLE 1 are currently indented by 4 spaces:

    // Get the connection type.
    var type = navigator.connection.type;

I'm not a networking expert, but from https://wicg.github.io/netinfo/#privacy-considerations alone and searching for keywords like "origin" and "end-to-end" in the spec, it's not super clear whether the downlink and rtt attributes are supposed to be the same for all origins (tabs, roughly) or if there's any kind of isolation intended.

For example, is there anything that evil.com can learn by including non-evil.com in one or many iframes and observing? Even if deemed acceptable privacy risks, spelling out any implications for cross-origin information leakage, and not just information about the user's network characteristics, would be good.

There are going to be platforms where we may know the type of connection but not the specific technology (802.11a/b/g/n/ac etc.). What value do we use for maxBandwidth in those cases?

Let me begin to say that I never contributed to a formal forum so please pardon my mistakes.

What is the purpose of reporting the underlying technology to a website? Technologies come and go and they give the website no useful information at best, and a placebo at worst.

These are the current connection types:

• bluetooth
• cellular
• ethernet
• none
• wifi
• wimax
• other
• mixed
• unknown

And these are the current motivations: (source)

• Warning the user that doing something over cellular could cost them money.
• Detecting when a connection switches from cellular to Wi-Fi, and vice versa.
• Giving the user control as to whether large uploads/downloads should happen over cellular (mostly related to synchronizing media data like photos, videos, and audio files).
• Preventing accidental data transfers over cellular, which could use up the user's data transfer quota and/or cost them money.

I only see one theme: cellular is a metered connection.

You can't determine whether a connection is metered by the way the device connects to the internet. Examples:

• mobile hotspots let the device use a metered connection; the browser reports "wifi"
• My WiMax connection is unmetered; your WiMax plan has a limit
• Canadian home users have a metered connection; the browser reports "ethernet"
• Where does bluetooth stand exactly?

I read Why not expose if the connection is "metered"?. You're acknowledging the issue and still deciding to put the burden on the developers. OSes and browsers have definitely more data to figure out the type of connection, at least with a better degree of certainty.

"other"/"unknown" users will be left out entirely, possibly because they are using a technology not formally recognized or not-yet standardized, while OSes can definitely know more (with drivers; because of global metered switches like in Windows 8+; because the devices and OS are made by the same manufacturer; or because OSes have access to historic data usage)

In short, while the current type API might be useful for some networking tool, or as a basis for future development, what we really need is a metered property.

A metered property could return yes/no/unknown values or, better yet, an indication of (essentially) how much data costs, to avoid putting 200GB-metered connections in the same category as somebody who's running out of their 200MB plan.

Edit: As an easy alternative, metered could be a user agent-defined 0%-100% likeliness that a connection is metered, where "unknown" would be 50%, "cellular" ~90% and wifi ~10%. Absolute certainty would be reserved for situations where a user option is exposed (like Windows 8+)