Consider removing connection.type and bucket downlinkMax

[igrigorik]

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.

[igrigorik]

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.

type is used by some sites as a crude "metered" signal (if cellular -> metered, otherwise..). It's an imperfect signal, but it's directionally right in many~most cases in practice, especially if you combine it with downlinkMax (if cellular and ~2G -> metered, otherwise...). Also, note that we did have metered in earlier iterations of the spec and the underlying UA implementations did the same check under the hood (if cellullar -> metered), but the feedback from developers was that this is "bad implementation" and we should authors decide instead, hence type! Stuck between a rock and a hard place.. Perhaps if we can solve #41 in a smarter way, we can consider deprecating type, but in absence of that, I do think we need it.

enum ConnectionType {
    "bluetooth",
    "cellular",
    "ethernet",
    "mixed",
    "none",
    "other",
    "unknown",
    "wifi",
    "wimax"
};

We could consider collapsing some of the enum values.. Any proposals for how to simplify or refactor the above?

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.

Yep, that could fall out of the enum discussion as well. For cellular, we could probably create coarser ranges based on ~generations -- the one gotcha is that RTT ranges for different technologies within same "generation" can vary quite a bit, so we'll have to pay attention to that.

[bzbarsky]

I see. I think a UA has a much better chance of being able to tell metered vs not (e.g. I'm commonly on "metered wifi", when tethering, and there's no way, even theoretically, for authors to tell that from "type" as currently specced).

There was quite a bit of discussion about this in the thread starting with https://groups.google.com/forum/#!msg/mozilla.dev.platform/lCZmhCDGHPY/hq3CgPkFDwAJ that pointed out that last-link connection type is a pretty bad proxy for metering or not.

[jkarlin]

The spirit of this version of the netinfo spec was to tell truth which could be built upon. We know what the first-hop connection is and we know its theoretical limits. It's actionable information. E.g., my app could have a preference, "enable downloading of media when on cellular", the same as my native apps have. And the vast majority of time it's good enough.

I'm interested in discussions of how we might reveal metered information, but note that a 'metered' boolean is not a panacea. How would we define metered? My wifi is capped at 500GB before having to pay extra per MB. My cellular is capped at 5GB, except for media from a few select sites (e.g., youtube). At what point do we consider each to be metered? Is it metered when talking to youtube? If not, do we need an isMetered(origin) method? What if I'm tethered two hops away instead of one?

[bzbarsky]

The problem is that the "truth" is sometimes lying by omission and that if people really think of it as "truth" as opposed to "a guess which might be wrong" they will get things wrong, and sometimes disastrously so. At least if the app knows it doesn't know what's going on it can fall back to asking the user whether to do download a ton of data...

That, plus leaking all this fine-grained and otherwise invisible information is a privacy/fingerprinting disaster.

[jkarlin]

I'd consider adding a tethered attribute, or potentially using the tethered type for the type attribute.

[bzbarsky]

I think we have fundamental differences on whether the right solution here is to expose all the information possible to untrusted web pages or whether the right solution is to expose the smallest amount of information possible to address the use cases...

[igrigorik]

@jkarlin @bzbarsky let's tease apart the the threads here..

Re, metered: there is an existing bug for this @ #41 - let's move this part of the discussion there to avoid rehashing the same points. I'll copy over the feedback from this thread in there.

Re, buckets: @bzbarsky you suggested that we could revisit granularity of reported connection types and downlinkMax values. Do you have any suggestions for how you'd group the types and thresholds?

[bzbarsky]

I don't have specific suggestions. Those would depend on the specific use cases people have for this API in practice, and no one has made those clear...

[igrigorik]

@bzbarsky that's not entirely true, we do have https://wicg.github.io/netinfo/#use-cases-and-requirements :)... That said, it probably does make sense to refactor and merge the two docs with more up to date learnings in this space.

@jkarlin working from other direction, any thoughts on whether and which connection types we could simplify or merge? If we look at our Chrome telemetry.. e.g. I imagine WiMax is not a frequent occurrence?

[bzbarsky]

we do have https://wicg.github.io/netinfo/#use-cases-and-requirements :).

I would love a summary of the problem space the linked-to document describes! I can try to sort through it myself, but not sure when I'll have that much time to devote to this.

[jkarlin]

I believe that WiMAX is still fairly common in Japan. If we were to simplify the types I think it would essentially turn into boolean isCellular. If that covers our use cases I'd be okay with that.

[marcoscaceres]

I'm reaching the same conclusion, maybe .isCellular or .isMobile is sufficient.

[jkarlin]

We could switch to .isCellular, but that's not sufficient to increase privacy. downlinkMax can be reverse mapped to the connection type. We could create tiers of downlink, instead of specifics. That would improve privacy to some extent.

E.g.:

0-1Mbps
1-10Mbps
10-100Mbps
100+

[bzbarsky]

That seems pretty reasonable to me, fwiw.

[caraya]

Was there any agreement to update the spec to reflect this discussion? It's been 2 years and it's still reporting unknown for type on desktop.

that value doesn't help when it comes to deciding if a user is in a cellular connection (where we need to be careful with the data our app consumes) and wifi/ethernet where it's ok to download a large package (a web bundle or other large assets)