The usecases do not justify the existence of this API about netinfo HOT 19 CLOSED

I don't think that simply not honoring autoplay when on a cellular connection is a good idea. Or at least that it solves the use cases fully.

First of all there's always pages that use JS and .play() to do their own autoplaying. Such pages need a way to know when not to call .play().

Second, isn't there a risk that it will get pages fully stuck? I.e. pages that contain markup like

However more importantly is that I don't think that we should expect to be able to find all different things that authors want to do differently between device-on-mobile and device-on-wifi. If native platforms hadn't had an API for detecting connection type, would we have even found all of the use cases above?

When talking to native app developers, and developers of bridging solutions like Cordova, the first request I always hear is for the ability to detect how the user is connected. The reasons vary (save the user money, don't initiate downloads that are going to take too long anyway, don't suck up the little bandwidth that the user has), but the request is very commonly the same.

I definitely think that we should provide whatever high-level APIs/solutions that we can in order to avoid people having to use the netinfo API. However we need an escape valve for the cases that we haven't yet covered. Extensibleweb and all that.

I definitely would be interested in seeing experiments in honoring autoplay when on cellular connections. But I don't want to hold off doing a netinfo API in the meantime.

from netinfo.

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. This means we fix the existing web, rather than providing an API and hoping developers use it (in the right way).

The current approach for the netinfo API assumes that the user knows more about the kind of networks they use regularly than the user agent does, the same way that app authors know more about their apps than the user agent does.

IMHO both are in a better position than the browser to:

1. As an app author, ask the user how they would like the app to behave in the presence of different types of networks for each app specific feature.
2. As a user, tell the app how I would like each of its features to behave based on my knowledge about the network I am using.

How would the user agent know which specific app features require autoplay/download prevention or warning? How would the user agent make a clear distinction about app specific features to provide me with an informative enough warning about what the app is trying to do? What if I want to allow music streaming but not music downloads via 3G (6.10 for instance)?

The user agent can certainly expose an UI to allow/forbid the usage of a specific network type by an app (for instance, 5.1 iOS does it), but I cannot see that being enough for use cases where a more granular setting is required. It should not be an all yes or all no decision.

4.3 Carrier billing: This would be better adaptive. Attempt to id the sim, if that fails, ask for number.

A failure attempt to identify a SIM via the network means time lost in the process. And time is quite valuable in payment flows. Note also the comment: "In order to decide what authentication process to trigger, payment providers currently try to identify the type of connection on the server. This usually entails maintaining lists of IP ranges for each carrier they integrate and some extra redirections."

5.10 Tweetbot streaming: Is this valid? Is streaming a bad thing on 4g?

Well, it's a bad thing if my 4g connection costs me money.

from netinfo.

@sicking:

First of all there's always pages that use JS and .play() to do their own autoplaying. Such pages need a way to know when not to call .play().

"their own autoplaying" doesn't work in Chrome Android today. See http://jsbin.com/makib/1/. play() needs to come from a user-interaction event.

Second, isn't there a risk that it will get pages fully stuck? I.e. pages that contain markup like (note the lack of 'controls'). Or is that simply considered bad form since UAs might allow users to disable autoplay?

UAs already diable autoplay. Is there some code missing from this paragraph?

However more importantly is that I don't think that we should expect to be able to find all different things that authors want to do differently between device-on-mobile and device-on-wifi. If native platforms hadn't had an API for detecting connection type, would we have even found all of the use cases above?

If we're not using use-cases to justify adding to the platform, what are we using?

When talking to native app developers, and developers of bridging solutions like Cordova, the first request I always hear is for the ability to detect how the user is connected. The reasons vary (save the user money, don't initiate downloads that are going to take too long anyway, don't suck up the little bandwidth that the user has), but the request is very commonly the same.

All of which the are better handled by the OS where the user can set limits and control apps in a single place. Say we ship this API, the users' problem isn't solved at all. It depends on sites implementing it correctly in a discoverable way. Then, users like me are going to be annoyed, because sites are going to treat me as metered, but I'm not (unlimited data plans are cheap in the UK). It becomes like those "btw we use cookies" messages that need to be dismissed site by site, and it'll become very tempting for a browser to lie and say "wifi" all the time to avoid a poorer experience for the user (like we saw with media="handheld")

If we fix this at a platform level, it's fixed across the web instantly, and users like me with unlimited data can disable the notifications at an OS level.

from netinfo.

@ferjm:

The "each feature" point is valid. In my suggestion there'd be no way for an app to background sync emails but not attachments on cell. However, the cost for this feature is an API that will be abused, needs to be dismissed on a per-app basis, and needs to be implemented correctly in apps before the user gets any benefit.

This feature is requested by developers, and the main use-case I hear is serving lower quality content to mobile users. If this becomes the primary use of the API, a mobile browser will be able to offer a superior user experience by lying (like the media="handheld" case again).

What if I want to allow music streaming but not music downloads via 3G (6.10 for instance)

I don't think that's what 6.10 is, those options aren't connection dependent. The 3rd option is, which is covered by my suggested "large download" warning.

A failure attempt to identify a SIM via the network means time lost in the process. And time is quite valuable in payment flows. Note also the comment: "In order to decide what authentication process to trigger, payment providers currently try to identify the type of connection on the server. This usually entails maintaining lists of IP ranges for each carrier they integrate and some extra redirections."

This feature doesn't fix this right? They're still going to have to check which mobile network they're on in order to match them to the payment system.

from netinfo.

I want to add another data point to this. A lot of these use-cases are based around the assumption that cell is metered and wifi isn't, but I don't think that's true. Eg:

BT Home Broadband £10 (+£15.99) per month. 10GB limit, then £5.30 per 5GB. http://www.productsandservices.bt.com/products/broadband/packages/

Three Mobile Broadband £12.90 per month. No limit, no limit while roaming in many countries. http://store.three.co.uk/SIM_Only/Voice_Pay_Monthly

from netinfo.

Much to my surprise, similarly offensive garbage in Canada:
http://www.rogers.com/web/link/hispeedBrowseFlowDefaultPlans

The place I'm staying at is both capped in speed (6mbps) and d/l limit (20 GB) per month. Exceeding the d/l incurs a charge per gb ($2).... and it costs $44.49/month wft!!!!

To compare, mobile plans from the Canadian company Wind are "unlimited" (10GB, lols) @ 21.1MBps for $30/month. It's all pretty bad here, it seems. Compared to Europe, where I paid a EU40 for real unlimited internet with speeds of at least 54mbps). My mobile plan was on a 4G capable network and I paid EU30/month for 1GB.

Regardless, the case still holds about giving users a choice of control over which connection they end up using for large d/ls. If that's an API decision, is a different matter.

from netinfo.

Lots of good data here:
http://www.macleans.ca/society/technology/canadas-almost-third-world-internet-access/

"Canada ranks below most of the developed world in download and upload speeds, prices and quality. In most cases it’s not third-world service, but judging by Ookla’s numbers, it’s fair to say that many third-world countries are within shooting distance."

from netinfo.

Interesting idea from https://twitter.com/pornelski/status/444143738022289408, offer a courtesy request:

navigator.requestDataUsage(roughUsageInBytes).then(function() {
  // play video, download large document etc etc
}, function() {
  // nah
});

Just a courtesy like the netinfo API, but allows the browser to ask the user, or answer for the user due to an earlier indication eg "Argh, I have unlimited data, don't ask me again".

from netinfo.

It turns out primitives aren't that useful to read the user's mind.

from netinfo.

The use cases for netinfo seem to be a case of using info we can find out easily as proxy for stuff that we can't, ie we want to know whether you're on a mobile connection because that's more likely to be metered, and although the spec defines a property for directly querying whether the connection is metered, no-one has any idea how to implement it.

The problem is that there's not a decent correlation between mobile networks and metering (as Jake illustrated) and there's not even a reliable way of detecting a mobile connection in the first place. Mobile connections can be, and often are, better than wifi, especially in developing countries. Wifi can be, and often is, metered too. Trying to do this by proxy metrics is basically garbage in, garbage out.

I like Kornel's suggestion, and my (probably naive) suggestion for how to implement it is to standardise a carrier info metadata format, probably JSON or XML, and an endpoint it can be requested from as a private hostname on the carrier's network, which could be very descriptive, eg:

http://carrier/netinfo.json:

{
   "bandwidth": 1.5,
   "isMetered": true,
   "pricePerMB": 0.05,
   "priceCurrency": "GBP"
}

If you wanted to avoid websites being able to access this just by downloading it with an XHR in browsers that aren't aware of it, maybe you could use a protocol other than HTTP.

This should also work for connections that are upstream of the UA, so if you have a laptop connected to a phone via tethering, you'd still get the netinfo file from the carrier. In the unlikely case of multiple metered connections being chained together, each carrier can union their netinfo with the upstream netinfo, and produce a worst-case netinfo for downstream consumers.

from netinfo.

@triblondon, I see two issues with your proposal. The first one is that network carriers will never agree to expose this kind of information. Similar suggestions have surfaced in the DAP WG for years. The reception has always been very negative and for understandable reasons: providing endpoints through which carriers expose their raw price completely commoditizes their offering, ruining their value proposition and causing a race to the bottom, ultimately turning them into dumb pipes.

But even if we were to overcome this issue, we'd still be faced with a bigger problem: the data carriers would provide us would still be absolute, and not relative to what the user is used too. The bandwidth of a lousy 3G bandwidth is terrible for someone who's running on 4G all the time, but amazingly fast for someone which spends his time on Edge. Downloading a Gigabit of data at GBP 0.05 per MB might be peanuts for someone with a good job in London, while it's weeks worth of salaries elsewhere in the World. Worse, this can change for the same individual depending on what kind of data she's looking at; 5 pounds to skype a friend that is in the middle of a terrible divorce, totally worth the money. Half of that to watch movie trailers while you thought you were on wifi: infuriating.

On top of that, we're only talking about netinfo here, but there are similar concerns about battery life, which is also very much context-dependent.

Everything with these problems point to the need for dedicated UI/UX at the UA or device level, not per app implementations based on incomplete and misleading data. The problem is that, so far, there hasn't been enough incentive for vendors to compete on these issues and provide great user experiences. So instead, we cite the Extensible Web Manifesto and try to come up with vaguely related primitives. These won't solve the underlying problem that it is for users to decide how they want to spend their money (and their phone's battery life).

from netinfo.

OK, well, naive it is then. Though I don't see how your second problem applies to my solution - I'm not advocating some arbitrary judgement of what counts as 'expensive', just the ability to give the user an informed choice (which might just be "You're about to download a lot of data on a metered connection, is that OK'). And I'm not advocating doing so in JS either, native UI sounds good to me.

Anyway, my overriding priority is that we don't create APIs that give you data with apparent high precision but such inaccuracy as to be completely useless.

from netinfo.

Though I don't see how your second problem applies to my solution - I'm not advocating some arbitrary judgement of what counts as 'expensive', just the ability to give the user an informed choice (which might just be "You're about to download a lot of data on a metered connection, is that OK').

My bad, I thought you were suggesting we should expose this data to the application developer. Agree 100% this information should be exposed to the user at the UA/OS level. How this is done, however, is precisely where device manufacturers and carriers should be able to compete.

I've recently switched phone operator for an operator that provides extremely fine-grained and failsafe handling of data-roaming. For me, that's a major selling point. (Bonus points that it is using a web application for which roaming charges don't apply to provide this service.)

from netinfo.

I feel like people are forgetting the various constraints that we have here.

1. Not all data is created equal. Creating an API that asks "can this app transfer X MB of data" just leaves the user asking "depends on what data you want to transfer". There needs to be some sort of conversation between the app and the user where the app can describe what types of data it on occasion needs to transfer, and the user describing the policies it wants.
2. The types of data that an app might want to transfer changes over time. A gmail app essentially has a different type of data for each label and whenever a new label is created a dialog needs to be had about what policy to use for that label.
3. If you think that this dialog should happen through the UA where the UA is the one that displays UI to the user facilitating this dialog, then please describe the UI that you're envisioning.
4. There are many different types of policies that apps/users might want. The youtube app has a policy of "on mobile connections, only transfer video data if the user explicitly opts in through the play button". BBC has a policy of "on mobile connections, warn the user when transferring video data". Gmail has policies like "Only transfer N days worth of emails from this set of labels" (I really wish it also enabled the policy "download all unread emails in this set of labels"). It seems entirely sensible for gmail to want to adjust those policies depending on connection type. So policies are more complex than "yes/no/only on wifi".
5. Carriers are not able to expose payment plans to devices. As someone that have worked closely with carriers building a mobile OS, they have been happy to spend lots of money and engineering resources contributing to the OS and marketing it. But it was too hard for them to expose payment information. Sadly I don't know the answer to why this is.

I'm happy to add APIs which allow more of the dialog to happen through the UA. The most obvious one is where the app tells the UA "I have data I want to sync every X minutes" and the UA then can tell the app "now is a good time to sync". This way the UA can have a dialog with the user what apps to sync on what types of connections at how often.
This can be further extended such that the app tells the user the different types of data it has so that the UA can let the user configure which data types from which apps should be synced how often.

But I don't believe that we can create an API which allows apps to have all dialogs about what data to transfer when through the UA. We need the escape valve of allowing applications to have that dialog directly with users. In order for apps to then implement those policies it needs access to more information than apps currently have.

from netinfo.

\1. Not all data is created equal. Creating an API that asks "can this app transfer X MB of data" just leaves the user asking "depends on what data you want to transfer". There needs to be some sort of conversation between the app and the user where the app can describe what types of data it on occasion needs to transfer, and the user describing the policies it wants.

Absolutely.

\2. The types of data that an app might want to transfer changes over time. A gmail app essentially has a different type of data for each label and whenever a new label is created a dialog needs to be had about what policy to use for that label.

That's application-specific, and pretty much orthogonal to netinfo, imho.

\3. If you think that this dialog should happen through the UA where the UA is the one that displays UI to the user facilitating this dialog, then please describe the UI that you're envisioning.

We can essentially break down actions, data, etc. into two categories. Those that need to happen immediately, and those that are nice to preload for perf or offline-access reasons.

If you have APIs that allow developers to express whether a particular request falls in either category, then you can effectively let the UA decide when to fetch either depending on network conditions, battery, user prefs, etc.

Consider the following scenario:

I'm using my email client at home on wifi. The email client runs all of its key requests as regular XHR requests, and preloads other emails through this hypothetical preloading API. All of this is working fine until my phone's battery lowers dangerously. At this point, the preloading has automatically stopped despited being on wifi. Later I realize I have to run out to the airport for a long flight and decide to make sure I have all of my mailing lists pre-cached for offline access; I simply hit the application-level pre-cache function of the relevant mailbox which makes regular XHR requests for those and advises me when its done.

\4. There are many different types of policies that apps/users might want. The youtube app has a policy of "on mobile connections, only transfer video data if the user explicitly opts in through the play button".

This is the kind of setting you want at the UA level, and then be able to override on a per origin basis or on the spot (similar to how flaskblock works).

BBC has a policy of "on mobile connections, warn the user when transferring video data".

Same here. This belongs at the UA level.

Gmail has policies like "Only transfer N days worth of emails from this set of labels" (I really wish it also enabled the policy "download all unread emails in this set of labels"). It seems entirely sensible for gmail to want to adjust those policies depending on connection type. So policies are more complex than "yes/no/only on wifi".

Gmail is an interesting example, as it's a lot more complex than the other ones mentioned above. That said, if you break it down, you still up with the same kind of tradeoffs and prioritization you're doing elsewhere. Actions you want to do immediately: send an email, read an email, etc., where an override-able UA-level config option makes the most sense. And those which are essentially data pre-caching for performance improvement or offline access. Here again, providing means to do this (potentially in the background) seems like a much more sound strategy, again with UA-level config which can be changed on a per origin basis. The other potential benefit you get from this is that such requests can be deprioretized over regular XHR requests.

As you said, not all bytes have the same value to the user, nor do they have the same cost. While a developer can have an idea how valuable different data points are to the users within a given app, there is no way for the developer to know how valuable these are compared to other applications. For example, a key action within a casual game might have a lot less value to me than offline access to a month-old email. Likewise, I may be willing to spend real money on fetching map data while roaming, but would hate to spend some of my already paid for data plan on watching videos of cats on Youtube.

Using netinfo as a proxy for the above is simply misguided.

\5. Carriers are not able to expose payment plans to devices. As someone that have worked closely with carriers building a mobile OS, they have been happy to spend lots of money and engineering resources contributing to the OS and marketing it. But it was too hard for them to expose payment information. Sadly I don't know the answer to why this is.

As mentioned previously, it operators were to expose this information, they'd be setting themselves up to compete strictly on bandwidth cost, which understandably, is the last thing they want to do. This is not going to happen until operators drastically change their business model. (E.g. by becoming trusted identity of payment providers on top of dumb pipes. This won't happen any time soon.)

I'm happy to add APIs which allow more of the dialog to happen through the UA. The most obvious one is where the app tells the UA "I have data I want to sync every X minutes" and the UA then can tell the app "now is a good time to sync". This way the UA can have a dialog with the user what apps to sync on what types of connections at how often.

Yes, different use cases would want slightly different versions of that (e.g. sync between tomorrow 3:00am or 7:00am for a newspaper app), but the key idea here is some form of way to request large chunks of data that aren't of critical use to the app for now.

This can be further extended such that the app tells the user the different types of data it has so that the UA can let the user configure which data types from which apps should be synced how often.

There are plenty of improvements UA can do on top of that to differentiate and compete.

But I don't believe that we can create an API which allows apps to have all dialogs about what data to transfer when through the UA. We need the escape valve of allowing applications to have that dialog directly with users. In order for apps to then implement those policies it needs access to more information than apps currently have.

How so? If we appropriately distinguish between critical data and what is essentially pre-caching, this is a lot easier to reason about and doesn't require the application to even know about what network it is running on.

Note that, as mentioned previously, this distinction still lets you have an action on an app that says something like: "pre-cache all of my unread mails for label Foo now," essentially turning what previously could have been a background pre-caching task into an action that needs to be fulfilled immediately.

from netinfo.

We still seem to be talking past each other.

We can essentially break down actions, data, etc. into two categories. Those that need to happen immediately, and those that are nice to preload for perf or offline-access reasons.

This might be the core of where we misunderstand each other. I believe the situation is much more complex than that. Even for data that you download for "nice to preload for perf..." all data is not created equal.

For example gmail might want to download only email contents and no attachments when doing background preloading on a mobile connection. Or it might want to download just the count of unread emails for each label and non of the actual emails when doing background preloading.

BBC has a policy of "on mobile connections, warn the user when transferring video data".
Same here. This belongs at the UA level.

Please provide more details about what UA implementation you are envisioning here. When/how would we warn?

And do keep in mind that the UA doesn't have access to any more data than we are planning on exposing in netinfo. I.e. we also don't know if the user is on a unlimited dataplan or on a pay-for wireless.

The main advantage that the UA has is that we can create a settings UI which enables doing settings for all apps/origins in one place. I.e. rather than the user having to go open each application and go to their settings section, we can have a single location that enables configuring multiple apps.

But we're still forced to ask the user the same questions as apps need to. I.e. things like what data to avoid transferring when on a data connection, a question that is highly data (and thus application) dependent.

from netinfo.

We can essentially break down actions, data, etc. into two categories. Those that need to happen immediately, and those that are nice to preload for perf or offline-access reasons.
This might be the core of where we misunderstand each other. I believe the situation is much more complex than that. Even for data that you download for "nice to preload for perf..." all data is not created equal.

Agreed. I'm not suggesting that is fine-grained enough here. App needs to be able to prioritize (by ordering requests).

For example gmail might want to download only email contents and no attachments when doing background preloading on a mobile connection. Or it might want to download just the count of unread emails for each label and non of the actual emails when doing background preloading.

Absolutely. Though network type here is pretty much irrelevant.

BBC has a policy of "on mobile connections, warn the user when transferring video data".
Same here. This belongs at the UA level.
Please provide more details about what UA implementation you are envisioning here. When/how would we warn?

I'd suggest something similar to flash block, here, but that can be overridden.

And do keep in mind that the UA doesn't have access to any more data than we are planning on exposing in netinfo. I.e. we also don't know if the user is on a unlimited dataplan or on a pay-for wireless.

Noted.

The main advantage that the UA has is that we can create a settings UI which enables doing settings for all apps/origins in one place. I.e. rather than the user having to go open each application and go to their settings section, we can have a single location that enables configuring multiple apps.

Yes. Easily discoverable, per app settings seems like a good idea outside of this particular spec (eg to help with privacy, géo loc, etc.)

But we're still forced to ask the user the same questions as apps need to. I.e. things like what data to avoid transferring when on a data connection, a question that is highly data (and thus application) dependent.

I'm not sure I understand the above well enough.

from netinfo.

We can essentially break down actions, data, etc. into two categories. Those that need to happen immediately, and those that are nice to preload for perf or offline-access reasons.This might be the core of where we misunderstand each other. I believe the situation is much more complex than that. Even for data that you download for "nice to preload for perf..." all data is not created equal.

Agreed. I'm not suggesting that is fine-grained enough here. App needs to be able to prioritize (by ordering requests).

I don't understand how prioritizing helps? We're not trying to stay within a specific budget of bytes, such as "don't consume more than 5MB". Every byte costs the user money and so we only want to download the data that the user wants downloaded, but we want to download all of that data.

For example gmail might want to download only email contents and no attachments when doing background preloading on a mobile connection. Or it might want to download just the count of unread emails for each label and non of the actual emails when doing background preloading.

Absolutely. Though network type here is pretty much irrelevant.

No, what I'm saying is that the user would want gmail to avoid preloading attachments if preloading happens on a mobile connection. But if preloading happens on a wifi connection then the user wants attachments to be downloaded as well.

Please provide more details about what UA implementation you are envisioning here. When/how would we warn?

I'd suggest something similar to flash block, here, but that can be overridden.

Would we do this for all video content? That sounds pretty annoying.

And would we do this for audio data as well? Such as recordings of radio shows? Or small sound effects in a game?

from netinfo.

closing, as there seems to be enough vendor interest to implement this thing in its new form.

from netinfo.