Intent to Implement: Improved NetInfo API

[Marijn Kruisselbrink]

Contact emails

m...@chromium.org

Spec

Proposed spec is at https://docs.google.com/document/d/1mh3uqyiCntp38jDcoECvKLyy0F1UIZPFafI2N910IQI/edit?usp=sharing

Summary

We want Chrome Apps to know certain characteristics of the current network connection, and be notified when those characteristics change. Originally we intended to implement this as a Chrome Apps API, but it seems more generally useful on the web, hence this proposal.

Motivation

ServiceWorker will (finally) enable an API to persistently cache resources on the client for offline and other use cases. However, once cached, the resources must also be manually updated. Question is, when? We are now entering the realm of applications which persist data between navigations and need to periodically update their assets.

The scheduling of when the update is triggered can have significant impact on battery and bandwidth usage of the device. All of the Android tips on optimizing networking fetching / prefetch are directly applicable. Further, smart prefetch is not just an optimization, but can also be a differentiating feature - e.g. YouTube prefetch was a runaway success.

Combination of ServiceWorker + NetInfo allows the application to optimize when and how much data is prefetched, when resources are updated, etc.

Compatibility Risk

Currently already two versions of this API exist in the wild, v1 and v2 of the NetInfo API. For good reasons neither of these is currently implemented in blink. This proposal attempts to solve the problems with these existing versions, but since this is clearly a hard problem to get right, the idea is to initially only expose this new API to Chrome Apps while we work out any details/things that might not work in practice.

Ongoing technical constraints

None.

Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

The implementation will be different for every platform, but the goal is to support all five platforms.

OWP launch tracking bug?

No (although I'm guessing there should be one)

Link to entry on the feature dashboard

Not sure if there should be one?

Requesting approval to ship?

No. The feature will be developed behind a runtime flag, although we might want to expose this feature to chrome apps before being exposed by default for websites.

[Yoav Weiss]

On Tue, Nov 26, 2013 at 5:08 PM, Marijn Kruisselbrink <m...@chromium.org> wrote:

Spec

Proposed spec is at https://docs.google.com/document/d/1mh3uqyiCntp38jDcoECvKLyy0F1UIZPFafI2N910IQI/edit?usp=sharing

That looks significantly better than the current NetInfo API spec. 

One nit - IMO the word "cost" for "how much bandwidth allowance does the user have left" may cause author confusion. Maybe "bandwidthLeft"? 

Are there any plans to bring this improved API to the device-api WG? 

I know connection.type was shot down in the past because of security concerns (mostly fingerprinting AFAIK), but it always seemed to me like a weak argument against it, and connection.bandwidth that replaced it is, as you say, "a big lie" and noted in the spec itself as "may be hard to implement, can be quite power-consuming to keep up-to-date and its value might be unrelated to the actual connection quality that could be affected by the server."

[Adam Barth]

On Tue, Nov 26, 2013 at 8:40 AM, Yoav Weiss <yo...@yoav.ws> wrote:

On Tue, Nov 26, 2013 at 5:08 PM, Marijn Kruisselbrink <m...@chromium.org> wrote:

Spec

Proposed spec is at https://docs.google.com/document/d/1mh3uqyiCntp38jDcoECvKLyy0F1UIZPFafI2N910IQI/edit?usp=sharing

That looks significantly better than the current NetInfo API spec. 

One nit - IMO the word "cost" for "how much bandwidth allowance does the user have left" may cause author confusion. Maybe "bandwidthLeft"? 

Are there any plans to bring this improved API to the device-api WG?

Currently we use two different technology stacks to implement JavaScript API, one in for web-facing APIs in Blink and another for Apps/Extensions facing APIs in Chromium.  In the past, this division has made it more difficult to standardize Apps APIs because switching from from an Apps API to a Web API involves rewriting the API using a different technology rather than that simply evolving the implementation.  For example, Apps APIs cannot contain any EventTargets because the technology we use to implement Extension APIs can't subclass EventTarget.

For NetInfo, I thought we might try a bit of an experiment and try implementing an Apps-facing API in as a Blink module.  That would let us implement the API using the same technology we use to implement Web-facing APIs, which will hopefully smooth the transition to the standards track.  However, unlike most of the feature we work on in Blink, we aren't going to pursue standardization of the feature immediately.  Of course, without progress on the standards track, NetInfo won't be on a path to being exposed to the web, but hopefully it will be easier to transition to that path than if the feature was implemented in Chromium.

In summary, we don't have any immediate plans to bring this API to the device-api WG, but the reason we're experimenting with this implementation approach is to make it easier to do that in the future.

Adam

[Yoav Weiss]

In summary, we don't have any immediate plans to bring this API to the device-api WG, but the reason we're experimenting with this implementation approach is to make it easier to do that in the future.

 

Sounds great! 

[William Chan (陈智昌)]

Do we have any use case scenarios for these APIs? I'm curious if there's a subset of stuff that may be better suited to a different API. Not saying we shouldn't expose this stuff, but I wonder if we think we already have a good idea on how such an API would be used.

For example, if much of this is used to control how XHRs are issued, then maybe it's better to use an expanded XHR API that declares intent. This gives the platform more flexibility in optimizing it, since it will have a better overall view of everything that's happening. Like, if there are other interactive network operations happening, then it won't do a non-interactive bulk download. Or for mobile connections, the platform will know not to wake up the radio unless it's already awake for other reasons. Batching operations like this is better for battery.

[Peter Beverloo]

I have (standing) concerns regarding the use-cases this API is trying to address, which I've discussed with Ilya plenty of times in the past.

The use-case you propose is for Service Workers to know when they should synchronize their data, but I think it would be a lot better for the user agent to heuristically determine the ideal synchronization time based on when the user is likely to use an application, as well as the network conditions, battery status, user preferences and so on.  Especially on mobile this is important, as the user may not be online when they check the news: we may actually want to synchronize the data *before* they start the application (starting a Service Worker in the background has its own range of concerns, mostly regarding resource usage).

Connection information is very volatile.  While this especially is a problem on mobile, where connection quality can change based on just a few meters of movement, it's true for WiFi and ethernet connections as well: consumer connections are severely overbooked, a neighbor who starts to watch a movie on Netflix can impact the quality of your own connection.  Furthermore, LTE at my house is over ten times the speed of my ethernet connection ( :-( ).  What knowledge would a website derive from the connection type and class?  They would be inherently inaccurate.  Simple, but more accurate latency (and, if required, bandwidth) estimates can be derived from Navigation Timing and/or Resource Timing (if we'd fix our implementation).  For post-pageload scenarios the developer could send an XHR instead as "probe".  Right now accessing Resource Timing information for XHR resources is rather awkward, but we could enhance this by proposing to add a "timing" property to XHR objects.

The cost and costId properties also concern me.  I understand that defaulting to "metered" for mobile connections is a safe option right now because mobile devices simply don't know, but what would a website do with this information?  Provide a worse experience or lower video quality?  Users with more generous data plans wouldn't want that.  The approaching-bandwidth and exceeded-bandwidth values are interesting, but I would like to understand how often we actually know such information -- as I understand it we rarely do.

As for API design, the overloaded meaning of the "connectionClass" property is very unfortunate, and why would we expose both "costId" (integer) and "cost" (string)?  I trust that the API will be iterated upon while the implementation is on-going.

For the broader Web, I can see a few interesting use-cases which would be interesting to address:

    * Provide a starting quality for streaming video content before adaptive streaming kicks in.  This could be reasonably derived using Resource Timing, except when the entire page is loaded from the cache.

    * Will's example: batching network requests to avoid the radio starting up.  This could be addressed by bringing the something similar to the "lazyload" attribute to XHR. [1]

For Chrome Apps the question is a bit different, because they're more likely to work from local resources and may thus load everything from the cache.  Sending a probe on page load and reading the Resource Timing information could work around this, but requires an additional RTT.  It would be much better for developers to base decisions on actual data instead of inaccurate connection type and class-based assumptions.

I don't have an opinion about whether or not we expose an API like this for Chrome Apps, but I do not think we should implement this API as something intended to support on the Web Platform.  There is a lot of low hanging fruit we can address first: enhancing our Resource Timing information, proposing additions such as lazyload-like behavior and easy Resource Timing access to XMLHttpRequest.  We could also consider investigating more daring proposals, such as aborting in-flight progressive JPEG downloads when the received bytes can provide a reasonable quality for the screen size.

Thanks,

Peter

[1] https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html#attr-lazyload

[Mounir Lamouri]

It seems that this proposal is some kind of mix between NetInfo v1 and
NetInfo v2 but I am not really convinced that it is fixing the problems
that were raised.

First of all, exposing the connection type does not seem like a very
good idea. In a non-privileged context (ie. not Chrome Apps), it might
be a fingerprinting and privacy issue. In all situations, it can be used
to do the wrong thing. It is way too easy to do shortcuts like "'wifi'
and 'ethernet' are fast connections" and "'mobile' is slow". There are
many situations were that would not be true (Peter mentioned one). This
is why NetInfo v2 removed that attribute and introduced bandwidth
instead. Bandwidth is what developers usually want to know. As the
document points, it is hard to estimate bandwidth. However, a clever
estimation made by the UA would always be way better than a developer
using the connection type. Indeed Firefox for Android does not do
anything fancy but that implementation was a POC.

Regarding the 'cost' property. It is not clear to me why
'connection.metered' was commented as "a lie" but 'connection.cost' is
actually trying to do more. People have been complaining that there is
no reliable way to implement 'connection.metered', it is not clear to me
how this is going to be easier to implement 'connection.cost'.

I am not trying to fight for NetInfo v2 but I do not see big chances
that would make that proposal take off better than the two others.

Cheers,
--
Mounir

On Wed, Nov 27, 2013, at 3:08, Marijn Kruisselbrink wrote:
> Contact emails
>
> m...@chromium.org
>
> Spec
>
> Proposed spec is at
> https://docs.google.com/document/d/1mh3uqyiCntp38jDcoECvKLyy0F1UIZPFafI2N910IQI/edit?usp=sharing
>
>
> Summary
>
> We want Chrome Apps to know certain characteristics of the current
> network
> connection, and be notified when those characteristics change. Originally
> we intended to implement this as a Chrome Apps API, but it seems more
> generally useful on the web, hence this proposal.
>
> Motivation
>

> ServiceWorker<https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md>will

> (finally) enable an API to persistently cache resources on the client
> for offline and other use cases. However, once cached, the resources must
> also be manually updated. Question is, when? We are now entering the
> realm
> of applications which persist data between navigations and need to
> periodically update their assets.
>
> The scheduling of when the update is triggered can have significant
> impact
> on battery and bandwidth usage of the device. All of the Android tips
> on optimizing
> networking fetching /

> prefetch<http://developer.android.com/training/efficient-downloads/index.html>are

> directly applicable. Further, smart prefetch is not just an
> optimization, but can also be a differentiating feature - e.g. YouTube

> prefetch<https://www.google.com/search?q=youtube+prefetch&oq=youtube+prefetch>was

> a runaway success.
>
> Combination of ServiceWorker + NetInfo allows the application to optimize
> when and how much data is prefetched, when resources are updated, etc.
>
> Compatibility Risk
>
> Currently already two versions of this API exist in the wild,

> v1<http://www.w3.org/TR/2011/WD-netinfo-api-20110607/>and
> v2 <http://www.w3.org/TR/netinfo-api/> of the NetInfo API. For good

> reasons
> neither of these is currently implemented in blink. This proposal
> attempts
> to solve the problems with these existing versions, but since this is
> clearly a hard problem to get right, the idea is to initially only expose
> this new API to Chrome Apps while we work out any details/things that
> might
> not work in practice.
>
> Ongoing technical constraints
>
> None.
>
> Will this feature be supported on all five Blink platforms (Windows, Mac,
> Linux, Chrome OS and Android)?
>
> The implementation will be different for every platform, but the goal is
> to
> support all five platforms.
>
> OWP launch tracking bug?
>
> No (although I'm guessing there should be one)
>

> Link to entry on the feature dashboard <http://www.chromestatus.com/>

>
> Not sure if there should be one?
>
> Requesting approval to ship?
>
> No. The feature will be developed behind a runtime flag, although we
> might
> want to expose this feature to chrome apps before being exposed by
> default
> for websites.
>

> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+...@chromium.org.

[Ilya Grigorik]

Couple of quick notes based on out-of-band / in-person discussions with mounir@, mek@ and szymon@...

Szymon pointed out that there are already a couple of existing efforts to do bandwidth estimation in Chrome (in WebRTC and QUIC), and he is working on an implementation that would apply to "regular" TCP sockets and that it could/should be used to expose ".bandwidth" in NetInfo.

With above in mind, the current NetInfo draft [1] may, in fact, be sufficient and be a better fit than what was proposed at the beginning of the thread. Based on what we discussed, I think the conclusion was: use v2 draft as a starting point and expose .bandwidth instead of connection type; a naive implementation could initialize said value based on connection type (which is internal / not exposed directly), and a smarter implementation would then leverage the built-in BW estimation machinery to refine these values.

I'll defer the details to szymon@ and mek@... Hopefully I captured the gist correctly. :-)

[1] http://www.w3.org/TR/netinfo-api/

[William Chan (陈智昌)]

Given the lack of connection type in the API, I'm curious what mechanism we intend developers to use to handle mobile energy consumption by the radio? I in general see two options, which aren't necessarily mutually exclusive:

(1) Expose information about the connection type and let developers try to control radio usage within their app.

(2) Hope that we understand the network request use cases and provide additional, targeted APIs to address them. For example, some form of a bulk download API (an XHR attribute? a separate API? i dunno), that would let the user-agent optimize with its more global knowledge of what's going on on the device.

Personally, I think irrespective of whether we do something with (1), we should be providing additional APIs as suggested in (2), at least for stuff like lazy downloads or bulk downloads.

[Alex Russell]

On Tue, Dec 3, 2013 at 8:29 AM, Peter Beverloo <pe...@chromium.org> wrote:

I have (standing) concerns regarding the use-cases this API is trying to address, which I've discussed with Ilya plenty of times in the past.

The use-case you propose is for Service Workers to know when they should synchronize their data, but I think it would be a lot better for the user agent to heuristically determine the ideal synchronization time based on when the user is likely to use an application, as well as the network conditions, battery status, user preferences and so on.

The way this would be communicated to the SW would be with an event. Nothing in this API precludes the UA giving the app hints about when to sync.

 

[Alex Russell]

On Thu, Dec 5, 2013 at 11:19 AM, William Chan (陈智昌) <will...@chromium.org> wrote:

Given the lack of connection type in the API, I'm curious what mechanism we intend developers to use to handle mobile energy consumption by the radio? I in general see two options, which aren't necessarily mutually exclusive:

(1) Expose information about the connection type and let developers try to control radio usage within their app.

I think this is most promising; it gives frameworks a way to do the Right Thing (TM) transparently to app.

There's an associated wrinkle: all of this seems to assume single-path TCP/UDP. In a world where multi-path is available to apps, having these properties be single-valued seems like it'd require some sort of unseemly "smushing"; either overloading the meanings or creating concatenated properties. Perhaps better to pre-epmtively make these arrays that are single-valued MOST of the time?

[Szymon Jakubczak]

On Thu, Dec 5, 2013 at 5:48 PM, Alex Russell <sligh...@google.com> wrote:

On Thu, Dec 5, 2013 at 11:19 AM, William Chan (陈智昌) <will...@chromium.org> wrote:

Given the lack of connection type in the API, I'm curious what mechanism we intend developers to use to handle mobile energy consumption by the radio? I in general see two options, which aren't necessarily mutually exclusive:

(1) Expose information about the connection type and let developers try to control radio usage within their app.

I think this is most promising; it gives frameworks a way to do the Right Thing (TM) transparently to app.

Do you think frameworks will be able to handle the hysteresis of the mobile radio in a way that covers all background requests made by the app?

Mobile radios waste energy when in high power state, but actually idle. So, a smart framework should not only choose to make lighter requests when on mobile, but also batch requests together.

In the world of 3rd party scripts, will all modules of the app cooperate to batch their requests together? Would providing an API like in (2) make it more obvious to apps and frameworks how to do the Right Thing?

 

There's an associated wrinkle: all of this seems to assume single-path TCP/UDP. In a world where multi-path is available to apps, having these properties be single-valued seems like it'd require some sort of unseemly "smushing"; either overloading the meanings or creating concatenated properties. Perhaps better to pre-epmtively make these arrays that are single-valued MOST of the time?

If the browser exposes multi-path control to the application ("make this request over this network"), then it's a good idea to bundle these values in a structure describing one "network" (or "link").  But there is the same question of (1) vs. (2): would it be better to let apps/frameworks instead designate "make this request over an inexpensive/fast/energy-efficient network"?

[Peter Beverloo]

On Fri, Dec 6, 2013 at 1:46 AM, Alex Russell <sligh...@google.com> wrote:

On Tue, Dec 3, 2013 at 8:29 AM, Peter Beverloo <pe...@chromium.org> wrote:

I have (standing) concerns regarding the use-cases this API is trying to address, which I've discussed with Ilya plenty of times in the past.

The use-case you propose is for Service Workers to know when they should synchronize their data, but I think it would be a lot better for the user agent to heuristically determine the ideal synchronization time based on when the user is likely to use an application, as well as the network conditions, battery status, user preferences and so on.

The way this would be communicated to the SW would be with an event. Nothing in this API precludes the UA giving the app hints about when to sync.

Correct.  Which would mean that we don't have to expose raw network information to the Service Worker (or elsewhere) to satisfy that use-case.  Whether or not SW will use a UA-triggered event is a separate discussion (and mostly orthogonal to this one), I am only pointing out that the presented use-case, again, is mostly hypothetical.

On Fri, Dec 6, 2013 at 1:48 AM, Alex Russell <sligh...@google.com> wrote:

On Thu, Dec 5, 2013 at 11:19 AM, William Chan (陈智昌) <will...@chromium.org> wrote:

Given the lack of connection type in the API, I'm curious what mechanism we intend developers to use to handle mobile energy consumption by the radio? I in general see two options, which aren't necessarily mutually exclusive:

(1) Expose information about the connection type and let developers try to control radio usage within their app.

I think this is most promising; it gives frameworks a way to do the Right Thing (TM) transparently to app.

There's an associated wrinkle: all of this seems to assume single-path TCP/UDP. In a world where multi-path is available to apps, having these properties be single-valued seems like it'd require some sort of unseemly "smushing"; either overloading the meanings or creating concatenated properties. Perhaps better to pre-epmtively make these arrays that are single-valued MOST of the time?

The volatility of network connections means that there are hundreds of different situations we can be in.  Optimizing resource fetching for SPDY connections is different from HTTP 1.0/1.1-based connections, which can differ again based on whether the resources are located on one or multiple origins.

Exposing this API is a massive foot-gun.  I'm much in favor of exposing information to authors where it makes sense, but the volatility and complexity of network information leads me to believe that we should pursue other options --many of which are low-hanging fruit-- before even considering this.  I have yet to hear convincing use-cases which cannot be more appropriately handled by enhancing existing APIs.  Discussions on other forums seem to be reaching that conclusion as well.

Peter

[Robin Berjon]

On 06/12/2013 11:47 , Peter Beverloo wrote:
> On Fri, Dec 6, 2013 at 1:46 AM, Alex Russell <sligh...@google.com
> <mailto:sligh...@google.com>> wrote:
> The use-case you propose is for Service Workers to know when
> they should synchronize their data, but I think it would be a
> lot better for the user agent to heuristically determine the
> ideal synchronization time based on when the user is likely to
> use an application, as well as the network conditions, battery
> status, user preferences and so on.
>
> The way this would be communicated to the SW would be with an event.
> Nothing in this API precludes the UA giving the app hints about when
> to sync.
>
> Correct. Which would mean that we don't have to expose raw network
> information to the Service Worker (or elsewhere) to satisfy that
> use-case. Whether or not SW will use a UA-triggered event is a separate
> discussion (and mostly orthogonal to this one), I am only pointing out
> that the presented use-case, again, is mostly hypothetical.

Bringing battery status in as a factor is interesting. Most of the use
cases for both network and battery information access (as well as some
other system aspects) tend to involve the application wanting to know
when is a good time to perform a costly operation (the classic case
being DropBox that stops syncing over some network types or when the
battery level is too low — certainly a valuable feature).

Providing a bunch of low-level information and hoping that apps get it
right here is clearly a footgun, even without the fingerprinting
considerations. It would be more useful to have a way not just for
synchronisation but for a variety of operations for the app to be able
to say that it wishes to perform an operation that's costly in one or
more of battery, network, memory, etc., can it please be notified of
when a good time would be.

Note that even the group that initially put together NetInfo wasn't
convinced that it was a good idea (or at least solvable in that way) and
only published that for discussion.

> On Tue, Dec 3, 2013 at 11:57 AM, Mounir Lamouri
> <mou...@lamouri.fr <mailto:mou...@lamouri.fr>> wrote:
> Regarding the 'cost' property. It is not clear to me why
> 'connection.metered' was commented as "a lie"

Metered is a lie because it doesn't expose any useful information
(assuming you can even get it right to start with). You could be metered
but with the first terabyte free, you could be metered but visiting a
country in which it is cheaper for you to data roam than it is to use it
at home (possibly cheaper than using the WiFi connection at the hotel).
Any decision made on that is likely to be wrong a substantial part of
the time.

--
Robin Berjon - http://berjon.com/ - @robinberjon

[mar...@marcosc.com]

On Tuesday, December 3, 2013 6:56:37 AM UTC, William Chan wrote:

Do we have any use case scenarios for these APIs? I'm curious if there's a subset of stuff that may be better suited to a different API. Not saying we shouldn't expose this stuff, but I wonder if we think we already have a good idea on how such an API would be used.

In order to get an idea of how the API might be used, a few of us have documented how similar APIs are used on native platforms. We've looked at Android, iOS, and Windows Phone:
https://github.com/w3c-webmob/netinfo
 
The document includes a set of use cases and requirements based on what we saw:
https://github.com/w3c-webmob/netinfo#use-cases-and-requirements

We are still trying to work out what we should do on the Mozilla side, but would be good to get alignment if we are going to expose this in browsers. We are happy to discuss this further on the W3C's DAP list. We also have a preliminary API proposal that is fairly similar to the one linked to in this bug:
https://github.com/ferjm/w3c-netinfo-v3-proposal

We put it together after examining the above use cases - and the only utility we see in this API is to sometimes help users make choices regarding large downloads (we hope authors won't try to be clever and make decisions that are better left to the browser with this API - I'm also in strong agreement with Peter Beverloo that enhancements to XHR or a new fetch API is needed + the declarative lazyload/postpone attributes, as well as <picture> and client hints for responsive images, together handle all network performance cases - this API is almost useless for any performance stuff and should not be used by authors to make any such decisions).

[Rafael Weinstein]

Apologies for creating more churn on this thread. Having talked with Mozilla recently about this, I'd like to make a few observations based on the discussion here and on the use-cases which marcos refers to above.

AFAICT, there are a couple basic concerns here with the various proposals:

1) Exposing information which may be fundamentally incorrect, unreliable or expensive to provide (e.g. because of unforeseeable events like network congestion or unknowable information like the users cellular plan/status).

2) Exposing information which may have privacy implications

3) Exposing an API which becomes irrelevant in the future or encouraging apps to make unsafe assumptions.

Separately, I think the primary use cases (as Marcos lays out) is somewhat simpler than some of the discussion here is inferring. It's primarily 

"I may do something *possibly* slow and/or expensive. I'd like my user to have some control over this based on the network type."

This matches my experience of what native mobile apps generally do, and it strikes me like the best available of somewhat poor options. For better or worse, the human is the most likely to know whether sucking down bytes is going to be a terrible idea and the apps are sensibly trying to avoid the users anger.

I share the concern WRT to (3) above as the technology and pricing are changing rapidly.

However, it strikes me 

WRT (2) (if there is a privacy concern) that we can approach this API like we do similarly sensitive capabilities

WRT (1) that the v3 of this proposal has the benefit of being both implementable and correct.

"What kind of network is this" may well become poorly correlated with whether it's a good idea to pull lots of bytes, but it's unlikely to become fundamentally unanswerable and I'm worried that us doing nothing is worse than doing something that works in the near term, but whose value erodes at some point.

[Marcos Caceres]

On Wednesday, February 26, 2014 at 1:20 PM, Rafael Weinstein wrote:

> "What kind of network is this" may well become poorly correlated with whether it's a good idea to pull lots of bytes, but it's unlikely to become fundamentally unanswerable and I'm worried that us doing nothing is worse than doing something that works in the near term, but whose value erodes at some point.

Those of us working on this API at Mozilla share this position. If you guys are ok to proceed, we have a new spec ready at:

http://w3c.github.io/netinfo/

We are also happy to produce a test suite - and are open to changes. Looking forward to any feedback.

--
Marcos Caceres

[Jonas Sicking]

Agreed! We should move forward with implementing this asap.

/ Jonas

[Rafael Weinstein]

One more comment:

Another general objection was essentially a hope that the browser is in a better position than the app to make a judgement about when to do heavy lifting.

Consider the specific cellular plan I happen to have right now:

-I get 2GB of blazing fast LTE (often faster than local wifi) and when I've hit that

-All bytes are still free, but my carrier reduces the speed dramatically.

Now imagine an abstract application that wants at some point to transfer "alot" of data. Let's even imagine that the browser knows my rate plan *and* how much data I have left in the billing cycle before I hit "slow". How is it going to make this decision? 

The browser is in position of alot of data about it's operating context, but the app & user are in possession of (I'd argue) equally as important information: how important is this work? Unless the idea is to move the "importance" bits into the browser, I think the natural solution is to move the contextual bits to the app.

[Jonas Sicking]

Agreed. This general area is really tricky. Whether it is appropriate
to transfer a big chunk of data is not only a function of the user's
connectivity and data plan, it's also a function of what type of data
it is (known to the app and the user) and how important the data is to
the user (only known to the user).

I definitely think that we need to have APIs which moves
transfer-decisions from the app to the platform. That way we can add
smarts and user-configurability into the implementation of those APIs.
We can even enable those APIs to accept descriptions of the datatypes
so that the platform can surface those descriptions to the user as to
enable us to build UI which makes it easier for the user to change
configurations and make decisions.

However, we will never be able to cover all the use cases with APIs
like that. There will always be places where app developers can't work
within those APIs, but yet they desperately will want to save users
time and money by not saving data usage while on mobile connections.
And users will just as desperately want applications to do that.

For those cases we need an API which enables apps to make these decisions.

Developers have always been able to innovate faster than platforms.
That's a good thing as it enables us to evolve the platform in more
informed ways.

And I don't think having an API like this will cause us to rest on our
laurels and innovate more slowly on APIs that enables the platform to
make decisions about whether or not to do a data transfer. (If it did
we deserve to be fired anyway). I would argue the contrary that
exposing the connection type and seeing what developers do with it
will enable us to make more informed decisions about where to focus
our efforts in providing better APIs, and what features those APIs
need.

Ok, I'll stop ranting now :)

/ Jonas

[Jeffrey Yasskin]

On that objection: I do think the browser's in a better position than an app to guess whether the user's data is metered and how. I'd argued for a single "metered" bool to reflect that (a'la netinfo-v2), but I'd much rather get connection.type than nothing.

If we wanted the browser to expose metering information, we'd have at least 2 choices of how to do it: give the app some information through the connection object, or let the app "start a background download" that gets scheduled according to the browser's beliefs about the connection. Even if we went with the "start a background download" option, the app could override this for data it believes the user cares about, by simply starting a normal download instead. (To some extent, this does move one "importance" bit into the browser.)

However, providing just the "background download" API goes against the drive to use new APIs to explain the web platform (http://infrequently.org/2012/04/bedrock/). If/when we provide that API, we should try to provide its explanation at the same time. http://w3c.github.io/netinfo/ takes one step in that direction.

So, count this as a vote from the peanut gallery in favor of http://w3c.github.io/netinfo/, even though it's not perfect.

On Wed, Feb 26, 2014 at 1:16 PM, Rafael Weinstein <raf...@google.com> wrote:

[Alex Russell]

I'd like to avoid getting hung up on the metered and bandwith discussions. If we make this API extensible, vendors can provide best-guesses. The v3 outline gives us a strong starting point that lets apps doing decent heuristics.

On an API-design front, I suggest we should be providing signals for anything we'd be using in a "smart" api (e.g., "background sync") to be making decisions about when it's safe to sync, not just the eventual decision as it'll largely be observable from such smart APIs that the runtime thinks one class of things is true and not another.

Good layering demands we explain ourselves. I suggest we start at V3 and add metering/bandwidth guesses later.

[Jonas Sicking]

On Wed, Feb 26, 2014 at 3:55 PM, Jeffrey Yasskin <jyas...@chromium.org> wrote:

> On that objection: I do think the browser's in a better position than an app
> to guess whether the user's data is metered and how. I'd argued for a single
> "metered" bool to reflect that (a'la netinfo-v2), but I'd much rather get
> connection.type than nothing.

The problem with exposing "metered" is making it reliable. I.e. if we
add such a property and use the logic "return true when on a cellular
connection and false when not on a cellular connection" then we
wouldn't add that much value, and we would be lying in cases when
users are on unlimited plans.

Carriers are super bad at providing this information to even their own
devices so I don't know that anyone would be able to not lie.

Then of course there's the issue of "what does metered mean". I.e. in
a plan that's fast the first 2GB per month, but slows down after, is
that metered since there's a 2GB limit, or unmetered because the user
will never get charged? And what about a plan that has a 5GB limit but
the user usually only uses a few hundred MB per month? Is that
unmetered since effectively the limit doesn't matter?

With an implementation where `metered === (type === "cellular")` I
would worry that developers will explicitly avoid using it because
it's lying anyway. And so even if we improve the implementation later,
developers wouldn't know when to trust it and when not to trust it.

We could expose "metered" as a tri-state: "yes", "no", "unknown".
However I don't think any implementations would be able to return
"yes" ever. Would an implementation that just returns "no" and
"unknown" really be valuable? Not to mention the fact that even the
"no" will be wrong when you tether.

I'm happy to add a "metered" property. But I'd like to make sure it's
actually implementable in a way that it provides value first.

/ Jonas

[Jeffrey Yasskin]

On Wed, Feb 26, 2014 at 4:36 PM, Alex Russell <sligh...@google.com> wrote:

I'd like to avoid getting hung up on the metered and bandwith discussions. If we make this API extensible, vendors can provide best-guesses. The v3 outline gives us a strong starting point that lets apps doing decent heuristics.

On an API-design front, I suggest we should be providing signals for anything we'd be using in a "smart" api (e.g., "background sync") to be making decisions about when it's safe to sync, not just the eventual decision as it'll largely be observable from such smart APIs that the runtime thinks one class of things is true and not another.

Good layering demands we explain ourselves. I suggest we start at V3 and add metering/bandwidth guesses later.

Yes, that's what I meant to suggest.

[Marcos Caceres]

On Thursday, February 27, 2014 at 12:36 AM, Alex Russell wrote:

> I'd like to avoid getting hung up on the metered and bandwith discussions. If we make this API extensible, vendors can provide best-guesses. The v3 outline gives us a strong starting point that lets apps doing decent heuristics.
>
> On an API-design front, I suggest we should be providing signals for anything we'd be using in a "smart" api (e.g., "background sync") to be making decisions about when it's safe to sync, not just the eventual decision as it'll largely be observable from such smart APIs that the runtime thinks one class of things is true and not another.
>
> Good layering demands we explain ourselves. I suggest we start at V3 and add metering/bandwidth guesses later.
>

Ok, so unless anyone objects, I'll tell the W3C that we are back on for the NetInfo API using [V3] as the basis. The spec was due to be "shelved" next week.

Thanks!

[V3] http://w3c.github.io/netinfo/

[jka...@chromium.org]

Note that I'm beginning implementation work based on http://w3c.github.io/netinfo/.  It's experimental only for now.  Firefox is implementing but I don't know of any signals from IE or Safari.

OWP: https://code.google.com/p/chromium/issues/detail?id=368358

Entry in Chromium Dashboard: http://www.chromestatus.com/admin/features/edit/6338383617982464

[rosa maria palacios juncosa]

El martes, 26 de noviembre de 2013 17:08:12 UTC+1, Marijn Kruisselbrink escribió:

Contact emails

m...@chromium.org

Spec

Proposed spec is at https://docs.google.com/document/d/1mh3uqyiCntp38jDcoECvKLyy0F1UIZPFafI2N910IQI/edit?usp=sharing

Summary

We want Chrome Apps to know certain characteristics of the current network connection, and be notified when those characteristics change. Originally we intended to implement this as a Chrome Apps API, but it seems more generally useful on the web, hence this proposal.

Motivation

ServiceWorker will (finally) enable an API to persistently cache resources on the client for offline and other use cases. However, once cached, the resources must also be manually updated. Question is, when? We are now entering the realm of applications which persist data between navigations and need to periodically update their assets.

The scheduling of when the update is triggered can have significant impact on battery and bandwidth usage of the device. All of the Android tips on optimizing networking fetching / prefetch are directly applicable. Further, smart prefetch is not just an optimization, but can also be a differentiating feature - e.g. YouTube prefetch was a runaway success.

Combination of ServiceWorker + NetInfo allows the application to optimize when and how much data is prefetched, when resources are updated, etc.

Compatibility Risk

Currently already two versions of this API exist in the wild, v1 and v2 of the NetInfo API. For good reasons neither of these is currently implemented in blink. This proposal attempts to solve the problems with these existing versions, but since this is clearly a hard problem to get right, the idea is to initially only expose this new API to Chrome Apps while we work out any details/things that might not work in practice.

Ongoing technical constraints

None.

Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

The implementation will be different for every platform, but the goal is to support all five platforms.

OWP launch tracking bug?

No (although I'm guessing there should be one)

Link to entry on the feature dashboard

Not sure if there should be one?