Improved API to detect metered or expensive connections about netinfo HOT 33 CLOSED

Can you give an example what an author can actually do? Can they do better than have a checkbox that sets a cookie that overrides their heuristic? (and users having to do this for each and every website whenever they switch to a network not behaving like a typical wifi/cellular?)

If I give feedback that I use a MiFi device, what can they do?

If I give feedback that generally I have nearly unlimited cellular, but very expensive roaming, what can they do? Will I have to allow them to track my location?

Can a user from India expect a Czech website to encode local knowledge? How can I in UK provide a good heuristic for my visitors from Japan?

If my network is generally not expensive, but this month I've exceeded my limit, and now it's expensive, how can sites know that? (Android knows that)

OTOH if I told the Chrome team that my network provider made roaming free, would they need a multi-year standards process to change return !wifi || roaming to return !wifi || (roaming && provider.name != 'that cheap one')?

It seems to me that sites are a wrong place to solve this problem. They will always have less information than the browser. Giving feedback to one website is not nearly as effective as giving feedback to one browser vendor.

Network characteristics are not a site-specific thing. They're device and time/situation-dependent, so they're best configured per device, in one place, rather than per-website, on every website individually.

Users with unusual networks could install browsers encoding local knowledge (I hear Chinese browsers rock at this). They could install browser extensions that flip the switch for all sites.

from netinfo.

Unfortunately shipping ~"we know this doesn't work but we might be able to improve it in the future—fingers crossed, really" doesn't lend itself well to a standards process or intent's to ship.

I think Netinfo API that is know to be bad and unfixable is even less suited to be shipped.

I see the options as:

1. "we know this doesn't work yet, but we will be free to improve it in the future—fingers crossed"
2. "we know this doesn't work, and it won't improve in the future, and—fingers crossed—it won't backfire horribly like User-Agent, so that in a decade browsers will have to pretend any post-WiFi network technology is WiFi just to be given happy code path on websites"

Improvement of isConnectionExpensive does not require much finger crossing. Android already allows user to set data plan cap, and can track approximate data usage. This shows that it's already possible* to implement it better than Netinfo API allows.

*) for that to actually happen Android OS devs must cooperate with Chrome devs, but difficulty there is not in API design or technology limitations, but Google's product decisions/policies to make that happen.

best we can do is expose related signals that we can define and allow developers to build own (smarter) models on top.

I disagree, for two reasons:

• accurate models require access to information which is not available to the websites, and should not be made available to protect privacy and avoid creation of new fingerprinting vectors. Browsers can gather much more information without exposing it to the web.
• not every developer will build a smarter model, so it's certain that there will be sites relying on the dumbest assumptions. OTOH every developer would benefit from models implemented in isConnectionExpensive, which can be made as smart as the browser vendor can make them.

I do have much more faith in browser vendors getting the algorithm right, once, with access to user settings and system information, than millions of developers re-inventing the model themselves (and sometimes making it buggy, short-sighted or maybe even decent at the time when they built the site, but unable to update it later when new technology becomes available).

just wrapping the exact same logic you can implement in user space with existing API. As such, personally I don't see a lot of value in exposing it as a standalone+first class primitive.. at least as of today.

I've shown you clear examples known today where the Netinfo.type API is going to backfire, and an abstraction over that API will not.

from netinfo.

I agree, and wrote about it in some length a while back.

The idea of metered as a probability is an interesting one.

from netinfo.

@igrigorik I think you have to be conscious about the difference between current implementation, and possible future implementations.

Yes, currently all implementations are bad, and perfect implementations are not possible. All vendors complain that they can't make any metered/expensive property 100% reliable.

However, Netinfo.type API gives no choice but to make the same bad implementation, on every website individually, forever. It sets the current implementation limitations in stone.

OTOH isConnectionExpensive can be improved for all sites immediately as soon as better implementation becomes possible.

Compare site A using:

if (type == wifi) hi() else lo()

with B:

if (!isConnectionExpensive()) hi() else lo()

Currently both behave the same.

However, if 5G or 6G networks become fast and cheap:

Site A: screws 5G/6G users.
Site B: browser will change the algo, all works fine

When wifi is very slow (bad signal, conference Wifi), and the OS can detect that (Android tries to, so it's not a fantasy). If that was exposed to the browsers:

Site A: unaware, screws lie-fi users
Site B: if browser reads the extra info from the OS, it can adapt and user gets better experience

If miraculously network providers start exposing data plan metadata (or Google Fi does this themselves for their own network/OS/browser)

Site A: unware, bad experience
Site B: the browser can use really good implementation and provide accurate information

So basically even though today Netinfo.type and isConnectionExpensive are equivalent, the former is doomed to be bad forever (and potentially grow into a headache for browser vendors if poor 2016 assumptions get written in stone in millions of copies of never-updated JS libraries), while the latter can be seamlessly improved for all future network types, network provider integrations, browser settings, etc.

from netinfo.

@igrigorik I think you have to be conscious about the difference between current implementation, and possible future implementations. Yes, currently all implementations are bad, and perfect implementations are not possible. All vendors complain that they can't make any metered/expensive property 100% reliable.

Unfortunately shipping ~"we know this doesn't work but we might be able to improve it in the future—fingers crossed, really" doesn't lend itself well to a standards process or intent's to ship. Given this constraint, the best we can do is expose related signals that we can define and allow developers to build own (smarter) models on top. For example, nothing stops the developer from taking wifi vs cellular distinction as a bootstrap signal and then augment that with own logic and feedback from the user — e.g. a video streaming application can prompt the user to confirm conditional on some network type, etc. In fact, that's exactly what React team has done, and I encourage you to build own libraries that can help developers avoid various pitfalls.

As far as exposing "metered" signal: in principle I'm all for it, but the underlying implementations on the platforms we care about are just wrapping the exact same logic you can implement in user space with existing API. As such, personally I don't see a lot of value in exposing it as a standalone+first class primitive.. at least as of today.

from netinfo.

This may have come up before, but could the isConnectionExpensive (or similar) boolean be driven by the UA via the user instead of the network on an opt-in basis. Maybe there could be a confirmation option for a user wherein they can note that specific network connections are metered. Could even happen at the OS level (which may make the most sense) and be a passthrough to the UA. Then it may not be defined in all instances (which is ok) but it could provide better context when it is available. So I'm other words it exists, but is bull by default and is up to the UA & user to determine whether it gets populated.

This would also reduce some privacy concerns since it's opt-in and it would bypass the carrier issues altogether.

from netinfo.

Actually, Google's Save-Data HTTP Client Hint is an even more elegant and well-defined solution than anything here.

from netinfo.

React native has isConnectionExpensive which I think is fantastic — it can be implemented today based on the same flawed coarse assumption that the sites and apps are forced to use, but at the same time it keeps it possible to seamlessly upgrade the API when new technologies become available, new user settings are added, new data plans are created, etc. — and does it all while keeping privacy as tight as possible.

https://twitter.com/cheeaun/status/753169251481952257

from netinfo.

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.

Then let's open a bug where we discuss how and where this can be exposed. Saying X is not useful because you need Y does not mean X is not useful, it just means you want Y :-)

I agree, and wrote about it in some length a while back.

I think we covered most of those points in: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/tU_Hqqytx8g/Gl3P86AwBAAJ.

React native has isConnectionExpensive which I think is fantastic...

Tracing it down to the source:

• https://github.com/facebook/react-native/blob/235b16d93287061a09c4624e612b5dc4f960ce47/ReactAndroid/src/main/java/com/facebook/react/modules/netinfo/NetInfoModule.java#L91
• https://developer.android.com/reference/android/support/v4/net/ConnectivityManagerCompat.html#isActiveNetworkMetered(android.net.ConnectivityManager)
• https://android.googlesource.com/platform/frameworks/support/+/refs/heads/master/v4/java/android/support/v4/net/ConnectivityManagerCompat.java#48

It's only supported on Android and maps to a simple switch on MOBILE vs WIFI. shrug...

from netinfo.

@igrigorik maybe the title needs to change but this is already the issue where I'm discussing an alternative API, explaining why the current one isn't fit for the purpose.

from netinfo.

Note that previous versions of the NetInfo API included a metered attribute. It was removed because no browser ever got around to implementing it correctly. The current API chose to expose things that are true.

With connection type, you can create a user setting, "play videos while on cellular data?". This is what mobile apps do that worry about metered data.

If there wasn't connection type, and just a bogus metered, you'd have to understand the bogus implementation (on each browser) in order to create the same user setting.

from netinfo.

The problem is that the current implementation only serves visitors directly on cellular and the rest of them are essentially locked out. There are plenty of mifi users. Wimax in Japan is widely used... and metered, while connectionType === 'wifi'

If there wasn't connection type, and just a bogus metered, you'd have to understand the bogus implementation (on each browser) in order to create the same user setting.

The implementation would still have to be defined and shared across the browsers to avoid that.

from netinfo.

The implementation would still have to be defined and shared across the browsers to avoid that.

Implementations don't (usually) get shared among different rendering engines. Specifications do. And specifying metered heuristics in a way that works across platforms, OS and rendering engine architectures is going to be a hard problem to tackle, unless we get some cross-platform OS level support for it (probably relying on asking the user), or decide to get it as input from the user at the browser level.

I've shown you clear examples known today where the Netinfo.type API is going to backfire, and an abstraction over that API will not.

I'd claim that an overly-optimistic-about-its-own-accuracy API, such as isConnectionExpensive() would backfire very quickly, because developers would rely on it immediately (or learn it's not reliable and ditch it) rather than wait for it to become useful sometimes in the future.

Developers would choose to download that oversized video that they normally wouldn't, without making a conscious tradeoff and without asking the user, because the API would lie to them and tell them that it's OK.

Now, maybe that broken state will be fixed at some point in the future when all browsers implement smarter heuristics that we currently cannot fathom. Maybe. But it's a pretty big bet.

from netinfo.

I don't understand how abandoning bad heuristics of isConnectionExpensive in favour of the same bad heuristics implemented with NetInfo improves anything for anybody.

We know developers assume WiFi is fast/cheap, and cellular is slow/expensive. NetInfo is always going to have the same amount or less information than the browser's heuristic can use, so NetInfo will always be as bad or worse. If the browser can't make it work, then site authors can't make it work either.

It's not a choice between:

bad heuristics of isConnectionExpensive vs good heuristics of Netinfo.type

In the NetInfo API by design a good heuristic is impossible.

it's a choice between:

bad heuristics of isConnectionExpensive vs bad heuristics of Netinfo.type, but one is due to implementation limitations, and may be fixable, and the other is bad by design, and is unfixable.

from netinfo.

@pornel the difference is that NetInfo.{type, downlinkMax} allows developers and framework authors to build own implementations that match their expectation, or encode local knowledge - e.g. geography specific rules, user provided feedback, and so on. As such, it enables rapid (developer driven) iteration that's decoupled from the multi-year standards cycle: React team can ship a new version in each release as they iterate on what "isExpensive" means to them. Yes, mistakes will be made in the process, but same is true for every other low level API in the platform.

from netinfo.

If I give feedback that I use a MiFi device, what can they do?
If I give feedback that generally I have nearly unlimited cellular, but very expensive roaming, what can they do? Will I have to allow them to track my location?

They can override their heuristics with user preference. Yes, the application can also request Geolocation to re-prompt the user later if it detects a country change.

If my network is generally not expensive, but this month I've exceeded my limit, and now it's expensive, how can sites know that? (Android knows that)

You can expose a config flag in your application that users can toggle. Also, Android doesn't really know that.. it only knows it if the user set a threshold, which is very very rare.

OTOH if I told the Chrome team that my network provider made roaming free, would they need a multi-year standards process to change

It would be significantly longer than a library updating such logic. Also, it's rarely that "clean", more often it'll be a special type of plan, restrictions in certain countries, etc. This type of logic is better handled higher up in the stack.

from netinfo.

They can override their heuristics with user preference. Yes, the application can also request Geolocation to re-prompt the user later if it detects a country change.

This is a thing that both browser and site can do, but browser can do it better (e.g. know difference between actual roaming and free wifi in another country), and once for all sites.

You can expose a config flag

This is a thing that both browser and site can do, but browser can do it better, and once for all sites.

Android doesn't really know that.. it only knows it if the user set a threshold, which is very very rare.

Sites never know that. This means that Android can handle rare cases, sites can't.

It would be significantly longer than a library updating such logic.

The difference is that browsers are generally evergreen, so the code change will reach users faster via the browser, than via sites.

With JS libraries I think there's only small portion of sites that use similar evergreen dependency update process. I'd expect majority of sites to update libraries ad-hoc, if ever. e.g. A major website I'm familiar with will launch a new section next month that uses jQuery 1.0.1.

from netinfo.

The difference is that browsers are evergreen for all users. With JS libraries I think there's only small portion of sites that use similar evergreen process.

@pornel I think we're going in circles.. :) I think the root of our disagreement is: I believe application developers are smart -- yes, they make mistakes, but they are able to fix them too; they are able to fix them faster than browsers are able to ship new versions. As such, I believe the current API provides more flexibility to smart developers to do smart things, and I have faith that they will do so. You may disagree with this position, and if so, then we'll just have to agree to disagree -- this is a subjective argument.

Back to the topic of this bug: metered. Is there anything actionable on this attribute?

Note that previous versions of the NetInfo API included a metered attribute. It was removed because no browser ever got around to implementing it correctly.

from netinfo.

I believe the current API provides more flexibility to smart developers to do smart things, and I have faith that they will do so. You may disagree with this position

I don't disagree, but this is not what I'm arguing about. My argument is that, for this particular feature, everything smart site developers can do, smart browser vendors can do just as well or better (and conversely, all the limitations browser vendors face, sites will face too).

My other argument is that all major browser vendors keep their browsers updated and generally keep high quality, but this unfortunately is not true in case of all websites. There is a significant portion of sites that are badly written with poor assumptions, and which never get updated.

Therefore, if this heuristic is in the browser, it'll be of quality as good as NetInfo allows (or better), and regularly updated for all sites. If it's implemented on sites, it'll be of varying quality, sometimes very bad quality, and quite often out of date, even for decades.

This is not a hypothetical speculation — this keeps happening with every web API. If we only had to deal with "smart developers" who know what they're doing and keep their sites updated, "webcompat" wouldn't be a pain. For example it was quicker for IE and Firefox to add support for -webkit- prefixes than it was for sites to remove them.

So it's quite reasonable to expect that if heuristic around Netinfo API will need to be updated, it'll be quicker for all browser vendors to make this API lie, than for all sites to update their heuristic.

from netinfo.

My argument is that, for this particular feature, everything smart site developers can do, smart browser vendors can do just as well or better

No, we can't. As a developer I can come up with any number of heuristics that leverage local context + user feedback and iterate on those rapidly... such heuristics may work for my particular use case, but may not be applicable outside of my region/application. As a browser developer, on the other hand, I need to come up with globally correct defaults.. which is a very different and significantly harder (intractable, as of today) problem.

from netinfo.

My other argument is that all major browser vendors keep their browsers updated

I agree that updating versioned libraries deployed over many sites is hard.

At the same time, one can envision a service (not unlike https://polyfill.io/) which provides a single URL and provides JS code that wraps around current netinfo, heuristics, user input, etc. Such a service can provide evergreen userland code that performs these assumptions on behalf of site developers, and improves them over time.

from netinfo.

Copying from #60:

@bzbarsky 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: 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...

from netinfo.

A few thoughts on nomenclature...

• metered is a slippery concept. @jkarlin captured some of the issues in #41 (comment). Technically most every cellular connection is metered, which is how it was implemented previously and why we removed it.. the number of false positives is very high and there is a significant fraction of false negatives as well -- e.g. when you're tethered, connecting through a pay-for hotspot, etc.

• tethered has been used interchangeably with metered a few times, but they're not the same either. Not all tethered connections are metered, and there are metered connections that are not tethered.

The underlying question and primitive seems to be "is connection expensive". For sake of argument, let's say we exposed such boolean, how would the UA implement it without falling into the same false-{positive, negative} traps of metered and tethered?

For context, we tried to tackle this very problem via Data-plan Info API a few years back, but that didn't get far off the ground: carriers are reluctant to expose such data (for good reasons), billing cycles and accounting are way more complex than we anticipated, and exposing such data carries legal implications -- in short, it didn't go anywhere.

Since then, there's been work on a new (scoped down) effort that tries to address some of the above by limiting how/where the data is exposed - see (Google) mobile data plan sharing API; YT is piloting it with a few carriers. Perhaps there's a way to expose those bits to the underlying OS.. not sure what Android team is thinking there. The other gotcha is that this requires explicit one-by-one carrier integration.

In short, I'd love to see — and spent a lot of time pursuing plausible routes — a reliable "this connection is expensive" flag to users. However, based on what we have access to today, personally I don't think that's something the UA can deliver with a useful level of accuracy. There are heuristics that can be applied here (e.g. connection properties, country scope, user prefs, etc.), but none of these work reliably across the board and need to be augmented by app developers -- and in order for that to happen, we need to give developers the underlying signals so they can make their own tradeoffs, instead of hiding all of them behind a single boolean they can't trust.

In that spirit, I think one concrete improvement we can make here is expose "data saver" preference via JS -- see #42. Right now it's delivered in HTTP headers only.

from netinfo.

Here's the thing that confuses me: if we think the UA can't reliably figure out anything here, why do we think app developers will be able to? The latter seems to be the fundamental assumption behind the "just expose all the information to app developers and throw our hands up in the air"...

(And that's assuming they had access to the same information to start with... in practice, the UA has the option of taking use prefs into account but the proposed API doesn't expose such prefs to app developers.)

If we posit that people will create imperfect heuristics on top of the information we have for now, and we will then try to improve the setup, which is more likely to get updated to a new and improved setup: uas or apps?

from netinfo.

Here's the thing that confuses me: if we think the UA can't reliably figure out anything here, why do we think app developers will be able to? The latter seems to be the fundamental assumption behind the "just expose all the information to app developers and throw our hands up in the air"...

It's not the UA "can't figure out anything", and more that the underlying complexity of this space simply does not lend itself to a single attribute that developers are willing to trust at face value -- at least, none of the developers I've talked to at Google and other major properties. Also, each application has own specific rules for how and when to trigger certain features -- e.g. YouTube rules on when to toggle different app modes vs cost tradeoffs are completely different from Google Search, which differ from Twitter (which provides an app-level pref) from.. you get the point. What they want, and need, are lower level signals that allow them to build own logic that accounts for connection properties, UA-level prefs, device prefs, app-level prefs, etc.

If we posit that people will create imperfect heuristics on top of the information we have for now, and we will then try to improve the setup, which is more likely to get updated to a new and improved setup: uas or apps?

Apps. Because they can learn and iterate at several orders of magnitude faster and optimize this process to fit their specific requirements and user + app-level prefs.

That said, these efforts are not exclusive.. Case in point, we expose both effectiveType and rtt + downlink attributes to allow for both types of users: those that need lower level signals to meet their product needs, and a higher-level signal that others can use and the UA can improve over time. Similarly, in this case, we can work towards a solution that enables both types of users.

from netinfo.

Also, each application has own specific rules for how and when to trigger certain features

That's fair. But we're still not exposing all the signals UAs have access to to them. And, honestly, I would not be happy, as a user, with exposing all that to random sites I have no particular relationship with.

Because they can learn and iterate at several orders of magnitude faster

Except for all the ones that stop being maintained, yes? What you say may be true of active Google properties, but I think is quite false of the vast majority of websites that just pull in some JS library and leave it at that, never updating either the library or their code.

Similarly, in this case, we can work towards a solution that enables both types of users.

Where by "users" you mean "authors", yes?

from netinfo.

But we're still not exposing all the signals UAs have access to to them. And, honestly, I would not be happy, as a user, with exposing all that to random sites I have no particular relationship with.

Me neither. My point is not that we must to expose every low-level signal we can get our hands on. Rather, I just wanted to motivate why we can't abstract all of the complexity of NetInfo behind a single enum or attribute like "isSlow" or "isExpensive". The right answer(s) here are somewhere in the middle: the goal is to identify meaningful signals that have low false positive/negative ratio and have reasonable path for cross-UA and platform adoption, while minimizing overall exposure and bits revealed about the user.

Where by "users" you mean "authors", yes?

Yep.

Except for all the ones that stop being maintained, yes? What you say may be true of active Google properties, but I think is quite false of the vast majority of websites that just pull in some JS library and leave it at that, never updating either the library or their code.

I think we can serve both masters here.. effectiveType is a good example: it's built on top of rtt and downlink ("a simple table lookup") but this model allows both the power users to build and customize own models, and "regular" developers to rely on effectiveType which can be updated and optimized by the UA -- chose your own adventure.

from netinfo.

I think the problem I have is all the folks who think they're "power users" but don't actually maintain their code once it's written... I suspect they vastly outnumber actual "power users".

from netinfo.

@bzbarsky perhaps, but we don't define web platform features by lowest denominator. Based on all the feedback I've seen from teams that expressed interest in this API, they do need lower-level information to implement their use cases.

Unwinding the stack.. from my earlier reply (#41 (comment)):

In short, I'd love to see — and spent a lot of time pursuing plausible routes — a reliable "this connection is expensive" flag to users. However, based on what we have access to today, personally I don't think that's something the UA can deliver with a useful level of accuracy. There are heuristics that can be applied here (e.g. connection properties, country scope, user prefs, etc.), but none of these work reliably across the board and need to be augmented by app developers -- and in order for that to happen, we need to give developers the underlying signals so they can make their own tradeoffs, instead of hiding all of them behind a single boolean they can't trust.

In that spirit, I think one concrete improvement we can make here is expose "data saver" preference via JS -- see #42. Right now it's delivered in HTTP headers only.

Does that sound reasonable and a step in the right direction?

from netinfo.

but we don't define web platform features by lowest denominator

We try to define web standards in a way that will not create horrible situations that we have to unwind a few years later. That's not the same thing as "lowest common denominator", but it does mean that normal expected usage of the API should not be a footgun.

Exposing a "data saver" boolean makes sense to me, I think. I still think that the various teams who think they need lower-level information will end up misusing it such that a few years down the line we'll have browsers either breaking things or lying to preserve compat...

from netinfo.

Copying from #59:

I'd like to note that for tethered connections, using the first hop for type breaks all web app use cases (4.1, 4.2, 4.3) that are mentioned in the review doc. Imho it would be really great if we could amend the spec to handle tethering gracefully.

For me it would seem easiest to let go of the notion of the first hop and replace it by most limiting hop known to the client. In the absence of tethering indicators that would be the first hop thus no changes there, however when tethering is detected (e.g. via ANDROID_METERED DHCP option) the type could be reported as "cellular". (Though without further knowledge about the cellular link, downlinkMax would have to be reported either as infinity or for the connection technology of the first hop.)

Imho that change would make the spec clearer, because now all five attributes would consistently relate to the most limiting hop. Any thoughts?

from netinfo.

Tracing it down to the source:

[...] [alternative link: http://androidxref.com/6.0.1_r10/xref/frameworks/support/v4/java/android/support/v4/net/ConnectivityManagerCompat.java#47]

It's only supported on Android and maps to a simple switch on MOBILE vs WIFI. shrug...

That's basically just the compatibility library's fallback implementation for older OS versions. isActiveNetworkMetered is natively supported from Jelly Bean (API16) and up and that implementation lives elsewhere. As you can see the code also takes into account a) whether the user is roaming and b) whether the user used the option to manually mark a Wifi-network as being metered.

Windows also allows treating a Wifi connection as being metered since Windows 8 I think.

from netinfo.

Google has the right solution: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Save-Data

from netinfo.