Comments (15)
That seems pretty reasonable to me, fwiw.
from netinfo.
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.
from netinfo.
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.
from netinfo.
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?
from netinfo.
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.
from netinfo.
I'd consider adding a tethered attribute, or potentially using the tethered type for the type attribute.
from netinfo.
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.
@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?
from netinfo.
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...
from netinfo.
@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?
from netinfo.
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.
from netinfo.
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.
from netinfo.
I'm reaching the same conclusion, maybe .isCellular
or .isMobile
is sufficient.
from netinfo.
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+
from netinfo.
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)
from netinfo.
Related Issues (20)
- Update the thresholds for different effective connection types HOT 7
- IANA section with registrations HOT 2
- Somewhat mangled IDL for NetworkInfomation HOT 2
- Fix indent in EXAMPLE 1
- Support .toJSON() on NetworkInformation interface
- Remove [NoInterfaceObject] HOT 2
- Include a separate “metered network” property in addition to “save data” HOT 1
- Netinfo status
- Should we archive this? HOT 21
- Can we just do metered? HOT 3
- Should `effectiveConnectionType` be a fixed set of values? HOT 15
- Revise use cases
- Privacy review and standards track plan HOT 1
- Should ontypechange be added again?
- compatibilité d'affichage mobile HOT 1
- Update repo and spec to show this is no longer being actively incubated HOT 6
- [tomayac/netinfo 🍴] `isMetered` should be `metered` HOT 1
- [tomayac/netinfo 🍴] Remove typedef HOT 1
- [tomayac/netinfo 🍴] Need to document why `sustainedSpeed` can be `Infinity` HOT 1
- Client Hints should get Sec-CH- prefixes HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from netinfo.