Ethernet vs. WiFi vs. Bluetooth #4
Comments
|
There is actually no "other" currently in the spec (seems I misled you on twitter)... but there could be. In the spec, "unknown" is used to capture both unknown connection types and those that don't fit into the enum. I would be inclined to throw "bluetooth", "ethernet", into the "unknown" set.... or add "other" for those and keep "unknown" for when the connection is unknown. @sicking? @slightlyoff? thoughts... |
|
I don't see the value in separating "other" and "unknown". To the I think it makes sense to keep "ethernet" separate (though I would I don't feel strongly about separating "bluetooth" from / Jonas |
|
The use cases for exposing this distinction are still not immediately obvious. So let me make this statement: providing developers with the ability to assume what any particular connection type means in terms of bandwidth/cost/metering is giving them a large footgun. That is also why we have removed 'bandwidth' and 'metered' from the original NetInfo spec. WiFi is generally no worse than Ethernet in most cases (@sicking, above you suggest these two connection types differ in quality?) so this distinction seems, at best, superfluous. At worst, it allows developers to apply different settings to these two connection types which seems like a non use case. I'd propose the following states as sufficient to fulfil the use cases presented in [1]:
Why? Because only users (not developers, devices or browsers) ultimately know of any data caps they may have or any overrage fees they could incur on each different type of connection. These things that are not encoded in systems and cannot be accurately modelled at a technical level. At the same time, users are always aware how they are currently connected to the Internet. They can apply their own assumptions to these connection types rather than allowing a developer to enforce certain bandwidth/cost/metering assumptions on their behalf - which may turn out to be wrong and may have unfortunately been hard-coded in to a web application. Here are the states I would be able to query (+events) as a developer: ( navigator.onCell == true && navigator.onLine == true ) // "cellular" (4G, 3G, GSM, GPRS) This type of API would:
In summary this would seem like a simpler solution that is both easier to implement, less ambiguous for developers and ultimately users, more privacy preserving for users and future-proof. What do you guys think? [1] https://github.com/w3c-webmob/installable-webapps/blob/gh-pages/ios_standalone/README.md |
|
So what exactly is developers going to use this for, if they should not imply anything about bandwidth, latency, metering etc.? If my laptop is connected to my iPhone via WiFi and the phone is connected to the world via 3G, then my laptop essentially is connected via 3G, even though the first hub is via WiFi. The physical connection type out of the current device (the first hub) does not seem very relevant.
It would be useful if the OS knew this, at least to some granularity. A lot of applications could benefit from this, e.g. to adjust bandwidth for streaming music, or to decide when to download security updates for installed applications. |
The most common use case in [1] is asking a user whether they want to do something on a cellular connection or not. Users (not developers) should be free to determine what that means for them personally on their current device, with their current data plan, with their current data connection type.
But this is not a technical problem we are currently able to solve. Put another way: such rules are not currently exposed to devices in any meaningful technical way so where would we get such rules from? Some devices allow users to set caps manually for different connection types (e.g. [2], [3]). It might be interesting to expose and/or enforce similar caps on the whole (e.g. [2]) or per origin (e.g. [3]) but that would make more sense being tackled in a future API :)
Not even native applications can currently determine such a scenario via native APIs. Therefore, it is unlikely this kind of info can be exposed to web apps at this point in time unless we could determine in all native platforms that network tethering is taking place (which we can't, I believe). [1] https://github.com/w3c-webmob/installable-webapps/blob/gh-pages/ios_standalone/README.md |
|
@c960657, with this API, you can build most of the applications that are in the following document:
Sure, but that's an exceptional case. If you know how to tether, than you basically know what you are doing (and the potential costs associated with that). Consider, if you were to tether now on your laptop, your email client, Dropbox, and any other networked applications will just use the available connection. This API can't help you - and that's fine because you took an explicit action as a user to tether (and hopefully understand what that means). Where the API does help is in that an application can give the user the choice to sync/download data on either "other" only (wired, bluetooth, wifi, includes tether) and/or "cellular". |
|
I agree with @richtr - and the applications we looked at can all be built with this model. I would be in favor of only having:
We can then expose more if we need to in future versions of the API. |
|
FWIW @richtr's proposal above also makes sense to me. The use cases that we've seen so far are mostly related to the usage of mobile networks vs other networks. Given the lack of use cases for Ethernet vs WiFi vs Bluetooth I agree that exposing these values as connection types adds no real value and increases the chances of developers making assumptions about bandwidth/cost/metering. I'm inclined to expose |
The adaptive streaming use case can be addressed by other APIs different than the netinfo one. https://github.com/w3c-webmob/netinfo-usecases#why-not-expose-bandwidth |
|
Apart from the Gmail use-case (it is based on an assumption that mobile connections are slow - this is generally not true with 3G and 4G) and the carrier billing use-case, the other use-cases on the list seem to be based on an assumption that mobile data is expensive and/or limited (e.g. to X GB per month) and should thus not be used to transfer large files. In practice, mobile charges differ extremely between domestic traffic (often flatrate, possibly with a monthly cap) and roaming traffic (extremely expensive). This suggests that the relevant properties are:
The browser could provide UI that allows the user to specify which of the above categories his mobile subscription is in (and possibly an advanced UI to specify this for specific WiFis also).
I agree that tethering is mostly for tech-savvy users. However, using a 3G-backed public WiFi on a bus or train is not. Also, public WiFis generally do not charge you per MB, but some may impose a total traffic cap per day (this is not uncommon in hotels). Of course we cannot support all possible setups, so we have to draw the line somewhere.
It would require the OS makers to make some interface and/or apply some additional logic (e.g. if your WiFi access-point can be detected as an iPhone, it is reasonable to assume that the connection is mobile, etc.). Such requirements may be reasonable, but putting them into a spec is a bad idea, if they are currently only hypothetical. |
I can only speak from personal experience, but I really appreciate the control apps like Audible give me: I've made explicit choices before to use up my limited data plan on an audio book - and was saved from using up my quota by the ABC app when I was dropped from a Wi-Fi network (the app stopped streaming and showed me an alert!). Having these at a global level would not work for me a lot of the time. Generally, apps seem to do the right thing. Doing what you suggest above comes with its own set of problems - and those problems are all hypothetical at this point. I would rather we enable an API that we know, understand, and can clearly see working with real applications that exist today, than make assumptions about how something might work that we have not yet seen anyone do. The good thing also of our API, is that it helps overcome many of the little footguns we see on native platforms - while enabling all the same use cases. |
|
closed via w3c/netinfo@b2982ad |
|
Awesome! :) Based on the logic presented in https://github.com/w3c/netinfo/issues/4#issuecomment-36332244 - where we can deduce the connection type through a combination of this API + navigator.onLine - should connection.type not be boolean-based instead? (and renamed to navigator.[isCellular/onCell/cellular/<insert your favourite name here>]?). |
|
@richtr I wouldn't be in favor of that. The current model is much more adaptable/extensible and achieves the same thing. |
I think you misunderstood me. I wasn't suggesting that you should make a global decision on what should be allowed on each type of connection. Whether you want to download a large file over an expensive connection should of course be a case-by-case decision. My suggestion was that rather than exposing whether the connection is mobile/non-mobile, it would be more useful to developers to expose whether the connection is free/paid/expensive. Then I wouldn't get warnings about possible data charges when I am using my flat-rate 3G connection, except when I am abroad. The default value - if I have not configured anything else - should be that all mobile connections are in the "paid" category.
I agree. Why would anyone use Bluetooth except when connecting via a cellphone with a mobile uplink? |
Maybe. But connection-type-driven web apps may break if implementations add new types or each implementation exposes different sets of connection types. The current model makes it easy for an implementer to ignore implementing the 'official' states ('cellular', 'other', 'none') or add additional states (e.g. reintroducing 'ethernet', 'wifi' and 'bluetooth' - undoing the advances we've made via this particular issue discussion). That could fragment API implementation and make its usage harder for web devs across different implementations. I could live with this as it is currently defined but I do wonder whether a boolean response makes for a better finite connection state model (see [1]) when combined with navigator.onLine [2] :) [1] https://github.com/w3c/netinfo/issues/4#issuecomment-36332244 |
|
@c960657 I think you are asking for both a browser-based UI for users to indicate what type of connection they are on (free/paid/expensive) since we cannot determine that information programmatically and then proposing an accompanying JavaScript API for web pages to retrieve those user settings (?). The problem is that users will probably not initially select what type of connection they are on, or they will change networks and not update this setting in their browser or they will choose the wrong setting based on a misunderstanding of the options available and the browser vendor could be held liable for that misunderstanding or error. It might be worth discussing your idea with implementers and getting back to us but you are now proposing something fundamentally different to the current NetInfo API. We should keep this thread on point - focussed on issues within the current spec - and discuss new proposals in a more suitable place (e.g. in a separate issue, on browser implementer mailing lists or web standards lists). WDYT? File this as a separate issue? |
Not quite. Assume the API can report either "free", "nearly-free", "metered-cheap", "metered-expensive" The UI should allow the user to specify what his mobile plan is flatrate or metered.
If the user has not specified his mobile plan, the value should default to "metered-cheap". This is the same assumption that most apps currently use. The part about holding the browser vendor liable for user misconfigurations sounds like FUD :-)
I don't think this is so fundamentally different. But of course, if your goal is to design an API that reports on the physical connection type, my proposal is out of scope. If your goal is to solve the issues presented in the list of use-cases, I think my proposal is in scope. Anyway, I just saw a reference to this discussion on Twitter and came by with a few ideas. I don't know anything about this working group, its charter or its timeplans. So how to proceed is completely up to you. I am just of offering my two cents :-) |
|
I don't buy the argument about footguns. Yes, there are certainly ways to abuse the API or use it wrong, but that argument is what has kept us from doing anything for 2 years. There simply is no way to create a foolproof API for this. Things like slow wifi connections, tethering and unlimited data plans means that there's always ways to make the wrong decisions based on the data returned from this API. I absolutely think that we need the ability to tell an app "you're on wifi/wired". Saying "you're not on cell" does not provide enough confindence that the user is actually connected to wifi/wired. I.e. if I build an app that has a feature which automatically sucks down large pieces of data, I want to have in my settings UI a checkbox for "enable feature X only on wifi" or "enable feature X only on wifi/wired". It would feel very scary to me as a developer to have that UI and then enable the feature whenever the connection type is "other". I would have no idea what types of crazy and potentially costly connection types the user's hardware has. It seems like a very real possibility already today that the user could use a bluetooth connection to connection to another cellphone where he/she has a costly plan. Such a user would likely be surprised that if they check "enable feature X on wifi" that this would enable the feature also on bluetooth. Developers could certainly use a different language in the UI, something like "disable feature X on cellular". However that doesn't actually help the user. First of all negatives in settings UIs are always more confusing. Second, it still means that the feature will be enabled over bluetooth. I.e. even if the user understands the language, now he/she has to go into the settings UI and uncheck anytime he/she connects over bluetooth. I don't feel strongly about separating "wifi" and "wired" from each other. As long as we can come up with a good string that makes it clear that both are included. And it needs to be separate from "other". I also don't feel strongly about separating "bluetooth" from "other". Possibly I could see apps wanting to treat it as "cellular" because it most likely is. But I'm fine with grouping it with "other" for now, though we should check with Google since they requested "bluetooth" to be there. |
But this is not just an alternative way of asking to 'Disable feature X on wifi/wired' as you suggest. I'm relying heavily on the (excellent) research provided on the subject at [UC1] for the rest of this response... Firstly, apps having a particular sensitivity to cellular connection types is the only use case that has been presented time and again in [UC1](and cellular connection types only based on commonly understood but 'fuzzy' assumptions on their bandwidth/cost/metering). When applications are asking 'Use on WiFi only?' what they seem to really be trying to determine is whether the user has a costly or otherwise limited data cellular plan or not. There are so few reasons when that is not what is really being asked or assumed in [UC1] as to be considered almost irrelevant. Secondly, in a responsive web site, how would the web developer detect that e.g. 'wired' was even an available connection type at all on the current device before presenting a 'wired/wifi' question to the user? Or Bluetooth or any other connection type? How would a developer know which connection types exist in the first place in order to ask the right question of their user based on the connection capabilities of their current device?
Right. Instead it tells you exactly what you'd expect: that the user is not connected to cellular. This is what developers are actually always really asking of the user - albeit in lots of different ways e.g.:
Also, more stricter interpretations of 'not cellular' can also be found in [1]. e.g.:
I can see that Bluetooth may be a pain point but is there anything else? It is not clear what other connection types you are considering or proposing to be in scope. It would be useful to discuss those further as they are likely highly relevant to this issue. Regarding Bluetooth, a good, if rough, definition of this as a connection type would be 'as a proxy for sharing from a cellular data plan'. Though this definition is not entirely true 100% of the time it is a fairly useful and realistic definition for the majority use case. Under such a general definition Bluetooth could be treated as a 'cellular' connection type (albeit as a special 'cellular' connection type but still carrying the same perceived limitations and implications that a standard cellular connection type carries). Whether that needs a separate entry in the connection type enum is thus debatable (since the effect is identical to the 'cellular' connection type and out on its own it may often be overlooked as being essentially equivalent to 'cellular' so why separate it out in the first place?). As a side note, if you disagree with this definition of what a Bluetooth connection means (e.g. it is also equally often used to share an Ethernet or WiFi based connection) then being able to identify a Bluetooth connection type has just become ambiguous enough to have lost all credibility or meaning in terms of its impact on a web application and should still not be exposed :) If we're going to discuss further I hope we have some convincing use cases to base our decisions on. Right now that would be the use cases found in [UC1]. |
As far as I can tell, it just tells you "The user is either connected to something other than cellular, or he/she is connected to something that we don't know what it is and that might be cellular".
This is a UI decision that we should leave up to the app. The current API basically says "don't do your UI like this, do it like that!". I'd rather stay out of the UI decisions and leave it up to developers. |
|
Although I'm in violent agreement with @richtr, I can sympathize with @sicking's point about not overly hand-holding what developers do. What @sicking suggest also aligns somewhat with the extensible web manifesto: basically, let's just provide the primitives and let user-land sort it out... and once they do, go back and standardize what we can. So, I'm going to draft up PR to reintroduce "ethernet", "wifi", and "bluetooth". Then developers are free to do the groupings in their libraries ("ethernet and wifi" === "reliable", "bluetooth" can be lumped with "other", or just provide |
|
As said on Twitter, I'd group the network types by what type of network category they represent:
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 This classification has the following advantages:
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 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 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 |
|
I'm kinda liking @fbender's proposal. I've pinged the Google guys to see what they think. Worst case, we just fall back to the original model. |
|
Because the bikeshed should obviously be blue, I think the right word maybe isn't cellular. The reason for this is that WiFi networks often are based on the same cellular network technology. Also cellular is a technology while "local" and "personal" are user-centric. But I'm maybe over thinking the whole thing ;-) |
|
@FremyCompany think about it from what makes sense to the audience. We are assuming, when we say "cellular", most developers will know what that means. "Cellular, as in like 3G and stuff." |
|
Of course, there's often a tradeoff to make between wording correctness and ease-of-use, but I think "mobile network" is the most frequently used of the two. I just tried and Google yields 33000k entries for "mobile network" and only 700k for "cellular network" (respectively 5000k vs 900k in Bing). Therefore, I believe in this case we can be both technically correct and use the most mainstream terminology. |
|
Terminology is never about "mainstream". 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".
They are a classification of range and stationarity (assuming I use the right term here), not user-centric (in this context). 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 (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 (Late-edited disclaimer for clarity.) |
|
FTR, here's some discussion on Twitter: https://twitter.com/marcosc/status/440107446766272513 |
|
We should not be generalizing prematurely. Providing what the OS provides is a MUST. Perhaps that sort of specific data can be hidden behind a "subtle" interface (as in Web Crypto) with a higher-level interpretive interface as an additional option, but it should be additive. We owe developers information and parity. Surface detail to the extent you can (safely). |
|
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. 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": 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. 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. |
|
I haven't seen this in the thread, but there is also the old use case of On 2/27/2014 1:58 PM, Rich Tibbett wrote:
Jeanne Spellman |
|
Agree with @jakearchibald here. Argued previously that providing low level APIs here isn't a good solution to use cases which basically boil down to: let the user decide how he spends his data plan. |
|
@jakearchibald, it seems like you are arguing that we should remove this API entirely. If so, that sounds like a separate issue from this one. Mind filing separately (and prepare to have me disagree over there :) ) |
|
@sicking Bracing for impact https://github.com/w3c/netinfo/issues/8 |
reintroduced wifi, ethernet, and bluetooth (closes #4)
The latest draft currently defines the following connection types that can be returned by this API [1]:
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
The text was updated successfully, but these errors were encountered: