Hacker News Reader

Comment by Sephr | Hacker News Reader

Why is the Network Information API still a thing? I don't feel like it should even be listed on this website, as it's an anti-feature. It only encourages discrimination on connection types, as it doesn't expose the only important part: is this connection metered?

Developers are going to use this API to serve me higher resolution assets over my metered WiFi & Ethernet connections (assuming they are unmetered) and lower resolution assets over my unmetered cellular LTE connection (assuming it's metered).

WiFi vs cellular vs Ethernet is not important. What's important is the usage policy behind the connection, and in its current state, the Network Information API can only be used to harm my user experience.

View on HN

How can a web browser or even native OS determine if a user's wifi network is metered? I agree it would be nice in theory if there was some kind of "dollars per MB" API, but I don't see how web browsers could implement that in practice.

I work on a podcast app. When people are downloading hundreds of MB or more daily, they emphatically want control over when downloading takes place. In practice, almost all of them are satisfied with a binary choice between cellular or not. Those who do sometimes use expensive or slow wifi networks can blacklist them, which is also what network info APIs support.

There are also other applications such as metering apps, utilities that trigger actions upon network changes. Some very popular Android apps (e.g. Tasker, IFTTT) rely on network info for that; web falls further behind if web apps can't access that data.

Through DHCP, the DHCP server can set different DHCP-options to notify clients what type of connection it is. For example: Android Phones set up to be a hotspot will set DHCP option 43 to a value indicating that it's a metered cellular connection.

I had no idea DHCP could even do that. What do Android devices do on unmetered cellular connections? How do they know if the connection is metered or not?

In android settings you can set if your connection is metered or not, and set thresholds / warnings.

In Windows it's possible to set a wifi connection as metered. I've used this when tethering to my phone. So this info could be passed into the browser.

Usage policy is not necessarily metered vs free. It's a mixed bag of user expectations, developer needs and technical properties of the connection. Connections are by no means only unmetered broadband and metered LTE. I have recently experienced several connection "quirks" that require different approach:

  * punishingly high RTT
  * packet-per-timeframe ratelimit
  * throttling by queueing packets
  * unstability (some requests get served in tens of ms, others get lost in void)
  * connection jumping from one provider to another (e.g. mobile/wifi while next to home)

For example, jaggy GPRS in the middle of nowhere can mean two things: I working in a field and need to check something as quick as possible without ads and other unnecessary cruft hindering with that, or I am resting in a cabin and am willing to wait for a "proper" app to load.

I may also have two connections: fast metered, slow unmetered and would like applications to load important stuff fast over metered network and cosmetics over unmetered one. Too bad I have to pull whole javascript framework first in order to see anything, because web components, and it's uncacheable because it's webpacked with application code.

I think this is important in case of 2G/3G/LTE distinction. Where phones that can access only 2G networks should get served "light" version of websites.

I think it's likely that most people would prefer the "light" version.

Absolutely not, have you tried 0.facebook.com ? Ux nightmare !

This use case is already handled by navigator.connection.downlinkMax. There is no reason to include navigator.connection.type in this API if you want to serve different content based on downlink bandwidth.

Network type can be used for more than just serving higher-resolution assets. It can also be used for doing aggressive pre-fetching of assets that may not be needed when on wifi. For example, my native RSS client will pre-fetch images from blog posts when it refreshes on wifi, but won't do that on cell. It's not unreasonable to think that various web apps might want to do the same sort of thing.

That's the same issue though. Your RSS client is assuming that all cellular connections are metered and all WiFi connections are unmetered, so it intentionally uses less data when you are on a cellular connection.

Which is usually a correct assumption. But it's more than just metered, it's also assuming that my wifi connection is likely to be faster and therefore downloading a bunch of assets in the background will have less of an impact on my available bandwidth.

'usually' you mean in the US?

While I was in the UK I had unlimited data on my mobile but a 100GB limit/month on my landline connection

Metered landlines aren't uncommon in the US, especially in areas with poor telecom infrastructure. I think if your app is worried about amounts of data relevant for metered cellular (which can be in the 2GB range in some places, including the US), the metering on landlines is virtually infinite in comparison.

I know enough people who's mobile data is both faster and cheaper than their home broadband that I cannot agree to your statement that this is usually a correct assumption.

Reply on news.ycombinator.com