Intent to ship: NetworkInformation

[Andrea Marchesini]

Our implementation of the NetworkInformation interface does not follow the
latest version of the spec. I'm planning to work on it. Then, I would like
to enable this interface by default - currently it's behind pref.

Related Bugs:
worker implementation: https://bugzilla.mozilla.org/show_bug.cgi?id=1323172
spec updates: https://bugzilla.mozilla.org/show_bug.cgi?id=1323658
<https://bugzilla.mozilla.org/show_bug.cgi?id=1224422>

Spec: https://w3c.github.io/netinfo/

[Boris Zbarsky]

On 12/15/16 3:28 AM, Andrea Marchesini wrote:
> Spec: https://w3c.github.io/netinfo/

Is there any plan to have this turned into an actual spec, complete with
IPR commitments, testcases, wider review, etc?

Have we done a privacy review of this spec? Why should a webpage ever
know whether I'm connected via "ethernet" vs "wifi" (insofar as we have
any way to determine this at all; I could be connected via "ethernet" to
a bridge that is connected via "wifi")?

Looking at the use cases document at
<http://w3c-webmob.github.io/netinfo-usecases/>, it seems like people
generally care more about things like "bandwidth costs money" and "how
much bandwidth do we expect?" than about the actual physical transport, no?

-Boris

[Eric Rescorla]

On Thu, Dec 15, 2016 at 6:42 AM, Boris Zbarsky <bzba...@mit.edu> wrote:

> On 12/15/16 3:28 AM, Andrea Marchesini wrote:
>
>> Spec: https://w3c.github.io/netinfo/
>>
>
> Is there any plan to have this turned into an actual spec, complete with
> IPR commitments, testcases, wider review, etc?
>
> Have we done a privacy review of this spec? Why should a webpage ever
> know whether I'm connected via "ethernet" vs "wifi" (insofar as we have any
> way to determine this at all; I could be connected via "ethernet" to a
> bridge that is connected via "wifi")?
>

I'm also concerned that this spec does not seem to take into account
multipath or multihoming, both of which seem relevant here. Say that I have
a device with both a cellular and WiFi link and I attempt to use both of
them in some fashion (depending on the remote IP address), what should I be
reporting for Network Connection?

-Ekr

Looking at the use cases document at <http://w3c-webmob.github.io/n
> etinfo-usecases/>, it seems like people generally care more about things
> like "bandwidth costs money" and "how much bandwidth do we expect?" than
> about the actual physical transport, no?
>
> -Boris
>

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Daniel Stenberg]

On Thu, 15 Dec 2016, Boris Zbarsky wrote:

> Looking at the use cases document at
> <http://w3c-webmob.github.io/netinfo-usecases/>, it seems like people
> generally care more about things like "bandwidth costs money" and "how much
> bandwidth do we expect?" than about the actual physical transport, no?

Looking at that collection of existing user, basically all of them want the
user to anser this question:

"Use expensive traffic (y/n)"

so that they can avoid doing "unecessary" things while connected to a network
that is "expensive". (Yes, it is a very binary answer but that is how it is
used normally.)

They do phrase that question as asking for wifi, cellular or 2G/3G etc - even
though it is not actually the type that makes the user click or unclick the
checkboxes.

Also (add to the problems already mentioned), if you tether via wifi over your
phone, are you on wifi or are you on cellular? In most of the use cases that's
"expensive traffic" so you'd have to lie and say cellular even though this API
will say wifi (I presume).

--

/ daniel.haxx.se

[Ben Kelly]

On Thu, Dec 15, 2016 at 3:28 AM, Andrea Marchesini <amarc...@mozilla.com>
wrote:

> Our implementation of the NetworkInformation interface does not follow the
> latest version of the spec. I'm planning to work on it. Then, I would like
> to enable this interface by default - currently it's behind pref.
>

I think we do enable it by default on android, but not desktop.

[Ben Kelly]

On Thu, Dec 15, 2016 at 8:42 AM, Boris Zbarsky <bzba...@mit.edu> wrote:

> On 12/15/16 3:28 AM, Andrea Marchesini wrote:
>
>> Spec: https://w3c.github.io/netinfo/
>>
>
> Is there any plan to have this turned into an actual spec, complete with
> IPR commitments, testcases, wider review, etc?
>

What is an IPR commitment?

It seems we can implement WPT tests. I don't know what you consider "an
actual spec", but I imagine if we show interest in implementing it will
graduate from WICG to its own w3c repo.

> Have we done a privacy review of this spec? Why should a webpage ever
> know whether I'm connected via "ethernet" vs "wifi" (insofar as we have any
> way to determine this at all; I could be connected via "ethernet" to a
> bridge that is connected via "wifi")?
>

We are shipping the connection type information on android already. Since
FF32 as far as I can tell.

The downlink max bandwidth would be just a lookup table from the type info
in our implementation. It could be improved in the future, of course.

Also, I'm not sure how transient data like connection type really helps
with fingerprinting too much compared to the other info already available
to fingerprint.

> Looking at the use cases document at <http://w3c-webmob.github.io/n
> etinfo-usecases/>, it seems like people generally care more about things
> like "bandwidth costs money" and "how much bandwidth do we expect?" than
> about the actual physical transport, no?
>

The spec is pretty clearly written to specify maximum possible downlink
given the first hop interface. It does not make any claims about actual
total throughput. I personally don't agree APIs like this need to provide
perfect information to provide value.

So, while I think we should implement this, I do have one concern. We have
been shipping a `typechange` event on this API while the spec and chrome
use a `change` event. If we start firing `change` as well, do we need to
still fire `typechange` for back-compat?

[Boris Zbarsky]

On 12/15/16 11:00 AM, Ben Kelly wrote:
> What is an IPR commitment?

IPR == "intellectual property rights". In the context of specs, mostly
patent issues.

> It seems we can implement WPT tests. I don't know what you consider "an
> actual spec"

Well, something that gets a wider look than WICG things get, has
multiple implementations, has tests, goes through the general spec
stabilization process to make sure everyone is on the same page, etc.

> We are shipping the connection type information on android already. Since
> FF32 as far as I can tell.

That's... not great. Especially since there was no intent to ship at
the time.

> The downlink max bandwidth would be just a lookup table from the type info
> in our implementation.

I should note that this is pretty useless as a metric for anything
outside maybe cell phones that are actually on a cell network. My
connection type right this moment would presumably come back as "wifi"
and and right this second I'm on an "n" network so we would claim
600Mbit/s. Except my actual wifi connection is at 217Mbit/s, and my
actual connection to anything at all useful (i.e. not the router sitting
on my bookshelf) is no more than 60Mbit/s. Of what possible use is the
"600Mbit/s" number to anyone?

Oh, and any moment now my WiFi connection can switch to the same-SSID
"ac" network, and that "600" would change to "6933.3", except my "ac"
network only goes to "1300"...

> Also, I'm not sure how transient data like connection type really helps
> with fingerprinting too much compared to the other info already available
> to fingerprint.

I'm not talking about fingerprinting, but about general privacy leaks.
Things like "oh, this user is on 10G ethernet, must be at a university"
or "Oh, they're on a brand-new cell network type only one company offers
for $$$$; must be rich".

> The spec is pretty clearly written to specify maximum possible downlink
> given the first hop interface.

Yes, I know that's what it specifies. I just don't think this is the
right thing to specify.

> It does not make any claims about actual
> total throughput. I personally don't agree APIs like this need to provide
> perfect information to provide value.

OK, so how would one use this API in practice?

-Boris

[Ben Kelly]

On Thu, Dec 15, 2016 at 11:14 AM, Boris Zbarsky <bzba...@mit.edu> wrote:

> OK, so how would one use this API in practice?

if (navigator.connect.downlinkMax > 100) {
// perform low-priority background downloads
}

[Boris Zbarsky]

On 12/15/16 11:23 AM, Ben Kelly wrote:
> if (navigator.connect.downlinkMax > 100) {
> // perform low-priority background downloads
> }

Why is the downlinkMax the right thing to be checking here, though?
Again, outside of the "cellphone on a cell network" case, the last-hop
bandwidth tells you pretty much nothing because it's incredibly unlikely
that the last hop is the bottleneck.

I agree that for the "cellphone on a cell network" case the last-hop
bandwidth can be useful.

-Boris

[Ben Kelly]

On Thu, Dec 15, 2016 at 12:06 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

> On 12/15/16 11:23 AM, Ben Kelly wrote:
>
>> if (navigator.connect.downlinkMax > 100) {
>> // perform low-priority background downloads
>> }
>>
>
> Why is the downlinkMax the right thing to be checking here, though? Again,
> outside of the "cellphone on a cell network" case, the last-hop bandwidth
> tells you pretty much nothing because it's incredibly unlikely that the
> last hop is the bottleneck.
>

Its more information than nothing. And saying its a limit on the maximum
is accurate. And its a value that can become more accurate over time with
better OS and network integration. Code using the API gets that for free
without changing anything. If it special cases on "cellular" or "wifi",
then it has to update its list if a new networking type is introduced in
the future.

I agree that for the "cellphone on a cell network" case the last-hop
> bandwidth can be useful.

Bluetooth networking is also a thing.

I think being able to distinguish this stuff provides some value even if
its not perfect for all cases. And I don't see how it causes any harm.

[Jonathan Kew]

On 15/12/2016 17:20, Ben Kelly wrote:
> On Thu, Dec 15, 2016 at 12:06 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
>

>> On 12/15/16 11:23 AM, Ben Kelly wrote:
>>
>>> if (navigator.connect.downlinkMax > 100) {
>>> // perform low-priority background downloads
>>> }
>>>
>>
>> Why is the downlinkMax the right thing to be checking here, though? Again,
>> outside of the "cellphone on a cell network" case, the last-hop bandwidth
>> tells you pretty much nothing because it's incredibly unlikely that the
>> last hop is the bottleneck.
>>
>

> Its more information than nothing.

But if it is seriously inaccurate or misleading information (e.g. it
suggests a fast connection, when the "fast" last-hop is just my laptop
being tethered to a cellphone that has a slow, expensive connection),
then it may be worse than nothing.

> And saying its a limit on the maximum
> is accurate. And its a value that can become more accurate over time with
> better OS and network integration.

Not necessarily, if it is explicitly spec'd to refer to the speed of the
last hop. ("The spec is pretty clearly written to specify maximum
possible downlink given the first hop interface.")

> Code using the API gets that for free
> without changing anything. If it special cases on "cellular" or "wifi",
> then it has to update its list if a new networking type is introduced in
> the future.

If better network integration means that in future, we can reliably
report the overall bandwidth of the connection to a given server (for
example), or the cost per byte transferred (perhaps more interesting, in
many cases), that would presumably be exposed via a new API, not by
redefining what this API does. But that means code doesn't "get that for
free", it will need to be updated.

>
> I agree that for the "cellphone on a cell network" case the last-hop
>> bandwidth can be useful.
>
>

> Bluetooth networking is also a thing.
>
> I think being able to distinguish this stuff provides some value even if
> its not perfect for all cases. And I don't see how it causes any harm.

It causes harm if it (mis)leads a site/web-app into doing things -- such
as large downloads over a metered connection, because the last hop
happens to look fast -- that are not appropriate for the true nature of
the user's connection.

Arguably, it might be better to not expose such potentially misleading
information at all; then such a site or app would not be tempted to rely
on it, and would have to find an alternative approach (perhaps simply
asking the user "do you want to download X megabytes of stuff?").

JK

[Patrick McManus]

Hi All -

Generally speaking releasing more information about what's behind the
firewall is an anti-goal. I have the same reaction others in this thread
have - this api is much more information than what is really needed, and
the information it provides is of questionable usefulness anyhow.

The design choice on the server often seems to want to know "is this data
metered or not" - which clearly has utility. There are many algorithms in
necko I want to apply the same criteria to. I'm still kind of queasy about
leaking this but if dan, or richard, or ekr who are all sufficiently
cynical about such things thought it was ok I would feel better about that
much.

But the performance variance of what 3g vs 4g vs wifi vs wired actually
means in any instance is so broad and has so much overlap that its simply
not a useful performance input. And as long as you're using constant
numbers from a table, there really is little you can do with certainty
about that other than maybe segregating 2g/bt from everything else.. even
that conclusion might be bogus.

Further, end to end bandwidth prediction simply does not exist with any
specificity - if it did the work of congestion controllers would be
un-necessary. Folks in this thread have talked about bridges, vpns, etc,
and that's just part of the story. The spec side steps that by assuming the
last mile is the bottleneck link, that the last mile is otherwise unused,
and assuming weirdly that multipath is a normal thing. That's handy for the
spec, but doesn't bear much on reality while it leaks local information.
Indeed it ignores the fundamental organization of IP networks as packet
switched connections of networks of varying types. (give me a POTS line I
hear you crying - but even that is likely faked circuit switching on voip
now).

>From an implementation pov, the browser could over time give a reasonable
metric about latency and bandwidth 'to the internet' just through passive
observation.. maybe as a 3x3 l/m/h matrix. but this would be for the client
in general and not really for the path between the client and the origin -
the latter is really what the origin wants. Without adding per-origin
overhead of a new speed test I would think the ResourceTiming already
available to it would be as good of a guide as anything else. So even
though it would be a cool engineering task to look at this whole-browser,
its of questionable utility imo.. and doing so leaks performance
observations cross-origin.

I guess the other thing I would want to consider here is the competitive
aspect of this API, but I wouldn't feel obligated to ship it for checklist
reasons.

tl;dr; is the metered-data bit enough and if so, can we just implement this
by always returning 1 of 2 configs (cell vs wifi e.g.) with const bw?

-P

[Ehsan Akhgari]

On 2016-12-15 11:14 AM, Boris Zbarsky wrote:
> On 12/15/16 11:00 AM, Ben Kelly wrote:
>> We are shipping the connection type information on android already.
>> Since
>> FF32 as far as I can tell.
>
> That's... not great. Especially since there was no intent to ship at
> the time.

FWIW Chromium also ships this API on Android and ChromeOS:
<https://chromium.googlesource.com/chromium/src/+blame/e1f453c8038dd60f17847dc37603c64835f9d865/content/child/runtime_features.cc#51>.
It seems that they ship both the type and typechange events:
<https://chromium.googlesource.com/chromium/src/+blame/e1f453c8038dd60f17847dc37603c64835f9d865/third_party/WebKit/Source/modules/netinfo/NetworkInformation.idl>.

FWIW I was one of the people who were involved in the discussions around
this for Firefox OS. From what I remember, the argument for shipping
this API was that web developers have been asking for this for years,
and they are basically happy to know the distinction between cellular
data and other transports, and infer whether the connection "costs
money". On Android at least native apps also use the same crude
measure. I think there was also an argument around the lines of asking
this being so common that a subset of users who actually do have paid
cellular data plans are used to rely on this distinction.

The limitations of this API and how little meaning it is actually
conveying to the developers was generally well understood, but the
counter argument for that would be that it's pretty clear we're never
going to be able to give the app accurate information unless we know
about what servers they want to talk to, and perhaps other load
characteristics, and even then we'd probably need to measure the
bandwidth, which could cost money, defeating the whole purpose; and with
that in mind, it's better to expose something now rather than nothing.

I have to say I personally don't find the last argument reasonable for
downlinkMax, but I can understand it for type.

Cheers,
Ehsan

[Ehsan Akhgari]

On 2016-12-15 11:14 AM, Boris Zbarsky wrote:

> On 12/15/16 11:00 AM, Ben Kelly wrote:
>> We are shipping the connection type information on android already.
>> Since
>> FF32 as far as I can tell.
>
> That's... not great. Especially since there was no intent to ship at
> the time.

[Boris Zbarsky]

On 12/15/16 12:20 PM, Ben Kelly wrote:
> Its more information than nothing.

I'm not sure it is. At least when you have nothing you _know_ you have
nothing, so might think about other ways to find out what you want to
know. This way you think you know something but you don't.

> Bluetooth networking is also a thing.

That's a good point.

> I think being able to distinguish this stuff provides some value even if
> its not perfect for all cases. And I don't see how it causes any harm.

I think it causes harm to give people information they have no business
having ("wifi" vs "ethernet") and it does harm to given them information
that's likely to be bogus (the last hop speed in the wifi/ethernet cases).

Maybe the answer is that we should just reconsider the set of types that
gets exposed and how they get mapped to connection speeds....

-Boris

[Boris Zbarsky]

On 12/15/16 2:39 PM, Ehsan Akhgari wrote:
> FWIW I was one of the people who were involved in the discussions around
> this for Firefox OS. From what I remember, the argument for shipping
> this API was that web developers have been asking for this for years,
> and they are basically happy to know the distinction between cellular
> data and other transports, and infer whether the connection "costs
> money".

OK. That does seem like a useful thing to expose, but it's precisely
one bit of information, right? Why are we exposing all this other stuff
instead?

-Boris

[Tantek Çelik]

On Thu, Dec 15, 2016 at 11:51 AM, Boris Zbarsky <bzba...@mit.edu> wrote:
> On 12/15/16 12:20 PM, Ben Kelly wrote:
>>
>> Its more information than nothing.
>
>
> I'm not sure it is. At least when you have nothing you _know_ you have
> nothing, so might think about other ways to find out what you want to know.
> This way you think you know something but you don't.

Agreed with Boris. "more information than nothing" is not an absolute
value, when that information is deceiving, which as others have
pointed out in this thread, is quite likely to occur with non-trivial
frequency in common uses of this API (the "if bandwidth>x then slow
download" example proves this point).

E.g. a high % of the time, (most of the time when I'm not at home or
work), I am on a 4G (high bandwidth) mifi (metered cost).

This API would report misleading results for me 100% of the time I am
on my mifi, and for anyone else on a 4G mifi.

Real experience, all (AFAIK) the "sync to cloud automatically" code
out there makes this mistake, e.g. iCloud, DropBox etc., so I've had
to turn all of it off or just not use it.

Let's learn from the error of "native" implementations/uses of this
kind of API / use thereof and not repeat that mistake on web,
certainly not ship an API that misleads web developers into doing the
wrong thing.

>> Bluetooth networking is also a thing.
>
>
> That's a good point.
>
>> I think being able to distinguish this stuff provides some value even if
>> its not perfect for all cases. And I don't see how it causes any harm.
>
>
> I think it causes harm to give people information they have no business
> having ("wifi" vs "ethernet") and it does harm to given them information
> that's likely to be bogus (the last hop speed in the wifi/ethernet cases).

Precisely. Obvious harms:

1. Privacy compromise without obvious user benefit
2. Causes web apps to waste user bandwidth/financial resources

If the response to that is "but doing it right is too hard", then
don't do it all.

> Maybe the answer is that we should just reconsider the set of types that
> gets exposed and how they get mapped to connection speeds....

I'm not sure that would sufficiently address harm 2.

As far as I can tell, the only useful bit of information (as bz
pointed out) is the

Am I on a cell data connection "for sure or maybe not"?
a) Where cell data "for sure" -> will *almost certainly cost the user*
b) Whereas "or maybe not" -> you have no idea whether it will cost the
user or not, do not make any assumptions.

Given that the one pseudo-code example provided earlier in this thread
makes the mistake of using case (b) to errantly initiate bandwidth/$
wasting downloads (which may not even be necessary), I think this API
has not been well thought through in terms of actual user benefit, and
needs further incubation.

Not to mention we shouldn't even be getting to an "Intent to *ship*"
on something we expect to standardize that hasn't even been published
as a FPWD yet (which only *starts* the count-down clock to IPR
commitment).

Implementing behind a flag should be good enough for prototyping
purposes to advocate for moving this from WICG to WPWG, and if that
transition doesn't happen for whatever reason it's a very clear sign
the tech is insufficiently incubated (or otherwise problematic) and we
shouldn't be shipping this. We're not even at that point yet!

Tantek

[smaug]

Even "costs money" based on the transport type is very unreliable. Coming from a country where basically all the mobile data plans
are unlimited (and cheap), it mostly just annoys when some OSes warn about use of mobile data to download lots of data (like updates) because of its
possible cost. Rather bad UX.

[Ehsan Akhgari]

On 2016-12-15 2:53 PM, Boris Zbarsky wrote:
> On 12/15/16 2:39 PM, Ehsan Akhgari wrote:
>> FWIW I was one of the people who were involved in the discussions around
>> this for Firefox OS. From what I remember, the argument for shipping
>> this API was that web developers have been asking for this for years,
>> and they are basically happy to know the distinction between cellular
>> data and other transports, and infer whether the connection "costs
>> money".
>
> OK. That does seem like a useful thing to expose, but it's precisely
> one bit of information, right?

Yes.

> Why are we exposing all this other stuff
> instead?

I'm not personally trying to advocate for this API, I was merely
reflecting the other side of the conversation from my memory.

(I personally agree with most of what you said, except that I'm
convinced that we should expose that one bit.)

>From a more practical perspective, we have two shipping implementations
of this API. What are you proposing to do with that for starters?

Note that Chrome has some use counters on this API:

* https://www.chromestatus.com/metrics/feature/popularity#NetInfo
* https://www.chromestatus.com/metrics/feature/popularity#NetInfoType
*
https://www.chromestatus.com/metrics/feature/popularity#NetInfoOnTypeChange
* https://www.chromestatus.com/metrics/feature/popularity#NetInfoOnChange
*https://www.chromestatus.com/metrics/feature/popularity#NetInfoDownlinkMax

[Boris Zbarsky]

On 12/15/16 6:15 PM, Ehsan Akhgari wrote:
> (I personally agree with most of what you said, except that I'm
> convinced that we should expose that one bit.)

Exposing this one bit makes a lot of sense to me.

> From a more practical perspective, we have two shipping implementations
> of this API. What are you proposing to do with that for starters?

After we finish crying? I think we fundamentally have two options:

1) Create a new API, convince everyone to ship it and deprecate the
other thing, and eventually hopefully remove it.

2) Figure out a way to map the one bit of information we actually want
to expose into some sort of values that look like the existing API.
Change the spec as needed to allow tweaks we want to make here (e.g. to
allow having the max speed thing not be defined or always be 0 or always
+Infinity, or always NaN, or always 42 or something).

> Note that Chrome has some use counters on this API:

Right, those are all above their removal thresholds. But I should note
that we've recently removed other things with high use counters once we
determined that a lot of that was from tracking scripts... That said,
the NetInfoOnChange counter is not likely to be tracking script.

I assume this is just data from Chrome, not webviews?

-Boris

P.S. I wish our DOM counters had a display like this, both in terms of
searchability and performance. :(

[Martin Thomson]

On Fri, Dec 16, 2016 at 10:28 AM, Boris Zbarsky <bzba...@mit.edu> wrote:
> 2) Figure out a way to map the one bit of information we actually want to
> expose into some sort of values that look like the existing API. Change the
> spec as needed to allow tweaks we want to make here (e.g. to allow having
> the max speed thing not be defined or always be 0 or always +Infinity, or
> always NaN, or always 42 or something).

Patrick suggested that we send a fixed downlink (+Infinity is always
correct by the spec) always and use wifi/cellular. I assume that we
need to pick one of those in the case that we can't/don't know, but I
like that plan.

We could create a new API as well, but I'm not sure what it would *do*.

[Eric Rescorla]

It seems pretty premature in this process to trying to hack around the API
not expressing what we wanted to make. If what we want to express is "is
this link free" then let's make the API say that.

-Ekr


On Thu, Dec 15, 2016 at 4:17 PM, Martin Thomson <m...@mozilla.com> wrote:

> On Fri, Dec 16, 2016 at 10:28 AM, Boris Zbarsky <bzba...@mit.edu> wrote:
> > 2) Figure out a way to map the one bit of information we actually want
> to
> > expose into some sort of values that look like the existing API. Change
> the
> > spec as needed to allow tweaks we want to make here (e.g. to allow having
> > the max speed thing not be defined or always be 0 or always +Infinity, or
> > always NaN, or always 42 or something).
>

> Patrick suggested that we send a fixed downlink (+Infinity is always
> correct by the spec) always and use wifi/cellular. I assume that we
> need to pick one of those in the case that we can't/don't know, but I
> like that plan.
>
> We could create a new API as well, but I'm not sure what it would *do*.

[Ehsan Akhgari]

On 2016-12-15 6:28 PM, Boris Zbarsky wrote:
> On 12/15/16 6:15 PM, Ehsan Akhgari wrote:
>> (I personally agree with most of what you said, except that I'm
>> convinced that we should expose that one bit.)
>
> Exposing this one bit makes a lot of sense to me.
>
>> From a more practical perspective, we have two shipping implementations
>> of this API. What are you proposing to do with that for starters?
>
> After we finish crying? I think we fundamentally have two options:
>
> 1) Create a new API, convince everyone to ship it and deprecate the
> other thing, and eventually hopefully remove it.

CCing Marcos, as he may have an idea about the practicality of this
approach.

> 2) Figure out a way to map the one bit of information we actually want
> to expose into some sort of values that look like the existing API.
> Change the spec as needed to allow tweaks we want to make here (e.g. to
> allow having the max speed thing not be defined or always be 0 or always
> +Infinity, or always NaN, or always 42 or something).

This would be interesting to think about...

Would it be safe to conclude that at this point we should not be
exposing this API to more contexts (such as workers, and/or non-Android
platforms)?

>> Note that Chrome has some use counters on this API:
>
> Right, those are all above their removal thresholds. But I should note
> that we've recently removed other things with high use counters once we
> determined that a lot of that was from tracking scripts... That said,
> the NetInfoOnChange counter is not likely to be tracking script.

Right.

> I assume this is just data from Chrome, not webviews?

Honestly I don't know. The UseCounter code I've seen in Blink seems to
collect counters unconditionally, but they may very well filter out data
from webviews somewhere in their pipeline.

We should probably consider collecting our own telemetry for this.

> -Boris
>
> P.S. I wish our DOM counters had a display like this, both in terms of
> searchability and performance. :(

Amen to that... :/

[Gervase Markham]

On 15/12/16 14:20, Daniel Stenberg wrote:
> Looking at that collection of existing user, basically all of them want
> the user to anser this question:
>
> "Use expensive traffic (y/n)"

And this should be an OS-level switch which the browser and other apps
both respect and reflect. Doesn't Android already have a "background
data" switch?

If I'm on the train wifi, I want to turn off all unnecessary traffic,
both to show love to other users, and because it'll make what I'm
actually focussed on doing faster. Now is not the time to run a backup.
I'd love such a switch on my laptop which my apps and web pages respected.

Gerv

[Tantek Çelik]

On Fri, Dec 16, 2016 at 10:51 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 15/12/16 14:20, Daniel Stenberg wrote:
>> Looking at that collection of existing user, basically all of them want
>> the user to anser this question:
>>
>> "Use expensive traffic (y/n)"
>
> And this should be an OS-level switch which the browser and other apps
> both respect and reflect. Doesn't Android already have a "background
> data" switch?

Until an OS-level switch happens, I think a browser level switch could
work well.

> If I'm on the train wifi, I want to turn off all unnecessary traffic,
> both to show love to other users, and because it'll make what I'm
> actually focussed on doing faster. Now is not the time to run a backup.
> I'd love such a switch on my laptop which my apps and web pages respected.

Gerv points out another good use-case. Train/plane and other shared
limited wifi.

Honestly this is starting to sound more and more like a need for a
"Minimal Network" variant of the "Work Offline" option we have in
Firefox (which AFAIK no other current browser has), since no amount of
OS-level guess-work is going to give you a reliable answer (as this
thread has documented).

Tantek

[Jason Duell]

On Fri, Dec 16, 2016 at 11:35 AM, Tantek Çelik <tan...@cs.stanford.edu>
wrote:

>
> Honestly this is starting to sound more and more like a need for a
> "Minimal Network" variant of the "Work Offline" option we have in
> Firefox (which AFAIK no other current browser has), since no amount of
> OS-level guess-work is going to give you a reliable answer (as this
> thread has documented).
>

So a switch that toggles the "network is expensive" bit, plus turns off
browser updates, phishing list fetches, etc? I can see how this would be
nice for power users on a tethered cell phone network. One issue would be
to make sure users don't forget to turn it off (and never update their
browser again, etc). Maybe it could time out.

Jason

[Ralph Giles]

On Fri, Dec 16, 2016 at 12:25 PM, Jason Duell <jdu...@mozilla.com> wrote:

> So a switch that toggles the "network is expensive" bit, plus turns off
> browser updates, phishing list fetches, etc?

Windows 10 has such a switch, although I suspect it's up to
applications to opt-in. An API to query 'metered connection' status
for each interface has been available since Windows 8. See
https://msdn.microsoft.com/en-us/library/windows/desktop/hh437593(v=vs.85).aspx

FWIW,
-r

[Mike Hommey]

On Fri, Dec 16, 2016 at 12:25:03PM -0800, Jason Duell wrote:
> On Fri, Dec 16, 2016 at 11:35 AM, Tantek Çelik <tan...@cs.stanford.edu>
> wrote:
>
> >
> > Honestly this is starting to sound more and more like a need for a
> > "Minimal Network" variant of the "Work Offline" option we have in
> > Firefox (which AFAIK no other current browser has), since no amount of
> > OS-level guess-work is going to give you a reliable answer (as this
> > thread has documented).
> >
>

> So a switch that toggles the "network is expensive" bit, plus turns off

> browser updates, phishing list fetches, etc? I can see how this would be
> nice for power users on a tethered cell phone network. One issue would be
> to make sure users don't forget to turn it off (and never update their
> browser again, etc). Maybe it could time out.

One thing asking the OS can do, other than give information of dubious
accuracy for the purpose of the API discussed here, is allow to tell if
things changed. So the browser could turn this off automatically (or ask
to) when the network connection changes.

Mike

[Karl Dubost]

When reading a thread about a new API or feature such as…

Le 16 déc. 2016 à 04:39, Ehsan Akhgari <ehsan....@gmail.com> a écrit :
> From what I remember, the argument for shipping
> this API was that web developers have been asking for this for years,
> and they are basically happy to know the distinction between cellular
> data and other transports, and infer whether the connection "costs
> money".

I have always in the back of my mind:

* How does it give control (benefits) to
- users?
- web developers?
- UX/Designers?
- marketers/analytics crunchers/BD?

Maybe there is a bit more user research (or maybe Marcos knows this already) to do in what users want to do? I guess we all have our own ideas about it.

Mine would be more give me a possibility to choose in the chrome what type of assets/performances I desire. I am on high performance bandwidth/latency network, but I want low-res, because I just want speed (the same way I would access a mobile domain m. for quick access on desktop). Or give me the high-res pictures on my slow network because I really need this high quality images I want to share with someone else and/or print.

I see a lot of benefits in user control. I see a lot of privacy issues at the other end of the spectrum. Privacy issues are not (often) a use case for service providers in the current business model. And we really never know what those will be before someone had an idea to "pervert" the usage of the API.


--
Karl Dubost, Mozilla
http://www.la-grange.net/karl/moz

[Gervase Markham]

On 16/12/16 20:25, Jason Duell wrote:
> So a switch that toggles the "network is expensive" bit, plus turns off
> browser updates, phishing list fetches, etc? I can see how this would be
> nice for power users on a tethered cell phone network. One issue would be
> to make sure users don't forget to turn it off (and never update their
> browser again, etc). Maybe it could time out.

We already do network change detection now, ISTR; could we pop a
doorhanger when we get a network change event, of the form of something
like "maintain 'expensive data' status Y/N?"...?

Gerv

[Daniel Stenberg]

On Mon, 19 Dec 2016, Gervase Markham wrote:

> We already do network change detection now, ISTR; could we pop a doorhanger
> when we get a network change event, of the form of something like "maintain
> 'expensive data' status Y/N?"...?

Nice idea!

However the network changes we detect currently are a bit too frequent and not
precise enough to be good enough for something like that. (Like we also
trigger them for example when we come back from sleep plus the fact that
occasional false positives don't hurt a lot when there's nothing visible
showing them.)

Once we get network detection done[*] in a satisfying manner it would be cool
to have such a bit remembered on a per-network basis so that we could have
Firefox remember the status when tethered and then switch back automatically
when going back to regular wire/ethernet etc!

[*] = I have basic work of this landed but the error rate is still too high to
build on it but there are more things to do to improve the situation. The idea
is to find network details that help us identify which network we're on and
then subsequently detect when we come back to a network we've been on before.
Details such as MAC address of the default gateway or the global IPv6 prefix.

--

/ daniel.haxx.se

[Ehsan Akhgari]

On 2016-12-18 4:16 PM, Karl Dubost wrote:
> When reading a thread about a new API or feature such as…
>
> Le 16 déc. 2016 à 04:39, Ehsan Akhgari <ehsan....@gmail.com> a écrit :
>> From what I remember, the argument for shipping
>> this API was that web developers have been asking for this for years,
>> and they are basically happy to know the distinction between cellular
>> data and other transports, and infer whether the connection "costs
>> money".
>
>
> I have always in the back of my mind:
>
> * How does it give control (benefits) to
> - users?
> - web developers?
> - UX/Designers?
> - marketers/analytics crunchers/BD?
>
> Maybe there is a bit more user research (or maybe Marcos knows this already) to do in what users want to do? I guess we all have our own ideas about it.
>
> Mine would be more give me a possibility to choose in the chrome what type of assets/performances I desire. I am on high performance bandwidth/latency network, but I want low-res, because I just want speed (the same way I would access a mobile domain m. for quick access on desktop). Or give me the high-res pictures on my slow network because I really need this high quality images I want to share with someone else and/or print.

The only potential for user control through this API is if a noticeable
portion of websites used this API to decide whether to give the users a
"low-res" version, and for the browser to provide some kind of a UI to
allow the user to override the information the browser receives from the
OS about your network connection.

As things stand now, neither of the above are true to the best of my
knowledge.

[Martin Thomson]

On Mon, Dec 19, 2016 at 8:23 PM, Gervase Markham <ge...@mozilla.org> wrote:
> We already do network change detection now, ISTR; could we pop a
> doorhanger when we get a network change event, of the form of something
> like "maintain 'expensive data' status Y/N?"...?

No more doorhangers please. I have no issue with providing UX around
this, but we need to be careful about how often we bother users.
Especially with things that we should be handling for them.

[Edmund Wong]

Eric Rescorla wrote:
>
> I'm also concerned that this spec does not seem to take into account
> multipath or multihoming, both of which seem relevant here. Say that I have
> a device with both a cellular and WiFi link and I attempt to use both of
> them in some fashion (depending on the remote IP address), what should I be
> reporting for Network Connection?

Why does it matter to Firefox what network connection I use? I would
understand Firefox needing telemetry on system specs and how it runs
against this spec, but network information? Really?

I mean... what's wrong with:

Firefox: Can I connect to the Internet?

Yes: Great. Proceed to connect.
No: Cannot connect. Display message. Wait for user to fix issue.

Why does Firefox (or anyone other than me) CARE I have 1, 2, or a
billion network interfaces or what type they are? Its job is to browse
the Internet. THAT'S IT. If Chrome wants to add it, that's their
business.

So, in conclusion, Firefox or, in fact, ANY browser, has NO business
knowing how many connections I have and what types they are. Mobile
browsers should act just like desktop browser. Can it connect to
the website? Yes or No.

[mcac...@mozilla.com]

On Friday, December 16, 2016 at 8:33:48 AM UTC+11, Tantek Çelik wrote:

> On Thu, Dec 15, 2016 at 11:51 AM, Boris Zbarsky <> wrote:
> > On 12/15/16 12:20 PM, Ben Kelly wrote:
> >>
> >> Its more information than nothing.
> >
> >
> > I'm not sure it is. At least when you have nothing you _know_ you have
> > nothing, so might think about other ways to find out what you want to know.
> > This way you think you know something but you don't.
>
> Agreed with Boris. "more information than nothing" is not an absolute
> value, when that information is deceiving, which as others have
> pointed out in this thread, is quite likely to occur with non-trivial
> frequency in common uses of this API (the "if bandwidth>x then slow
> download" example proves this point).
>
> E.g. a high % of the time, (most of the time when I'm not at home or
> work), I am on a 4G (high bandwidth) mifi (metered cost).
>
> This API would report misleading results for me 100% of the time I am
> on my mifi, and for anyone else on a 4G mifi.

But you know you are on a mifi as a user: you bought the mifi, you paid for the mifi's contract, you connected to the mifi. Same with hotel wifi, etc. which may be metered.

The point of the API is to allow the end-user and the application to negotiate when it's best to perform a download (not to make decisions about what is best and what is going to cost money). There is nothing preventing an app from asking the user what network type would be best to perform synchronization over.

The general assumption that WIFI is cheap and 3G/4G may be sometimes wrong, but it holds for most users.

> Real experience, all (AFAIK) the "sync to cloud automatically" code
> out there makes this mistake, e.g. iCloud, DropBox etc., so I've had
> to turn all of it off or just not use it.

Sure, but that goes back to Ehsan's point about perfect information: we can't currently get that until we get better WIFI standards or whatever. Until then, your mifi will look like WIFI - but that's not the APIs fault.

Again, see the use cases document.

> Let's learn from the error of "native" implementations/uses of this
> kind of API / use thereof and not repeat that mistake on web,
> certainly not ship an API that misleads web developers into doing the
> wrong thing.

The use cases document shows that native apps get this right a lot of the time.

We are weighting the iCloud/DropBox problem against all the app examples given in the document. Right now, sites use a bunch of hacks to figure out if you are on a metered connection or not (see BBC example in the document).

Yeah, that's why it's currently in the WICG.

> Not to mention we shouldn't even be getting to an "Intent to *ship*"
> on something we expect to standardize that hasn't even been published
> as a FPWD yet (which only *starts* the count-down clock to IPR
> commitment).

It was originally part of DAP, so it's actually gone through years of publication (first published in mid 2011):
https://www.w3.org/TR/2011/WD-netinfo-api-20110607/

All the arguments presented here also got raised by the WG, which made it go nowhere... so we took it to the WICG for further incubation - because Google shipped it, and thus we were hoping for buy in from some other browser vendor.

> Implementing behind a flag should be good enough for prototyping
> purposes to advocate for moving this from WICG to WPWG, and if that
> transition doesn't happen for whatever reason it's a very clear sign
> the tech is insufficiently incubated (or otherwise problematic) and we
> shouldn't be shipping this. We're not even at that point yet!

As above. This API has a very very very long history. It's been discussed to death and is suffering from standards-fatigue.

Yes, it's kinda crap... but can get the job done for the documented use cases:
https://www.w3.org/TR/netinfo-usecases/

[mcac...@mozilla.com]

On Tuesday, December 20, 2016 at 3:48:10 AM UTC+11, Ehsan Akhgari wrote:
> The only potential for user control through this API is if a noticeable
> portion of websites used this API to decide whether to give the users a
> "low-res" version, and for the browser to provide some kind of a UI to
> allow the user to override the information the browser receives from the
> OS about your network connection.

Agree... and that's the footgun of the API.

[mcac...@mozilla.com]

On Saturday, December 17, 2016 at 3:38:45 AM UTC+11, Ehsan Akhgari wrote:
> On 2016-12-15 6:28 PM, Boris Zbarsky wrote:
> > On 12/15/16 6:15 PM, Ehsan Akhgari wrote:
> >> (I personally agree with most of what you said, except that I'm
> >> convinced that we should expose that one bit.)
> >
> > Exposing this one bit makes a lot of sense to me.
> >
> >> From a more practical perspective, we have two shipping implementations
> >> of this API. What are you proposing to do with that for starters?
> >
> > After we finish crying? I think we fundamentally have two options:
> >
> > 1) Create a new API, convince everyone to ship it and deprecate the
> > other thing, and eventually hopefully remove it.
>
> CCing Marcos, as he may have an idea about the practicality of this
> approach.

I don't know tbh... given that there has been no agreement about this since 2011 (it's definitely the most controversial API I've ever been involved with - and I only got involved when we moved it to the WICG). We can definitely try to improve the current one - and learn from what Google shipped (by talking to them and see if we can find out a bit more about who is using it and how). I think Facebook was using it to not load video for ads when the connection is 2G, for example.

If other people want to have a go at trying to come up with something sensible, then by all means they can try... but be warned... it's a political s***show for something that has such clear use case on mobile.

> > 2) Figure out a way to map the one bit of information we actually want
> > to expose into some sort of values that look like the existing API.
> > Change the spec as needed to allow tweaks we want to make here (e.g. to
> > allow having the max speed thing not be defined or always be 0 or always
> > +Infinity, or always NaN, or always 42 or something).
>
> This would be interesting to think about...

I'm all ears... I'm sure Ilya would be super open to that too on the Chrome side.

[Eric Rescorla]

I'm not really following this argument. Usually when a document has been
floating
around a long time but clearly has basic design issues and can't get
consensus,
even when a major vendor has implemented it, that's a sign that it
*shouldn't*
be standardized until those issues are resolved. That's not standards
fatigue,
it's the process working as designed.

None of this seems to add up to a strong argument that this functionality
should
be in Firefox

-Ekr

[Steve Fink]

On 12/19/2016 06:21 PM, Edmund Wong wrote:
> Eric Rescorla wrote:
>> I'm also concerned that this spec does not seem to take into account
>> multipath or multihoming, both of which seem relevant here. Say that I have
>> a device with both a cellular and WiFi link and I attempt to use both of
>> them in some fashion (depending on the remote IP address), what should I be
>> reporting for Network Connection?
> Why does it matter to Firefox what network connection I use? I would
> understand Firefox needing telemetry on system specs and how it runs
> against this spec, but network information? Really?
>
> I mean... what's wrong with:
>
> Firefox: Can I connect to the Internet?
>
> Yes: Great. Proceed to connect.
> No: Cannot connect. Display message. Wait for user to fix issue.
>
> Why does Firefox (or anyone other than me) CARE I have 1, 2, or a
> billion network interfaces or what type they are? Its job is to browse
> the Internet. THAT'S IT. If Chrome wants to add it, that's their
> business.
>

Because if extra bandwidth is going to cost me a week's wages, I would
rather Firefox not prefetch all the links it sees on a page and look up
DNS info for all of them plus anything found in them. And unfortunately,
there's no simple way to guess whether the marginal bandwidth cost is
zero or my meal budget for the next month. Simply looking at the type of
one network interface isn't really enough.

That's not really a fair example, btw, since we're talking about a
content-exposed API here. But the same idea holds -- the web site I'm
visiting might not want to annoy me with 200 full motion thumbnail gifs
if it knows I'm on a metered connection.

[mcac...@mozilla.com]

On Wednesday, December 21, 2016 at 12:51:10 AM UTC+11, Eric Rescorla wrote:
> I'm not really following this argument. Usually when a document has been
> floating
> around a long time but clearly has basic design issues and can't get
> consensus,
> even when a major vendor has implemented it, that's a sign that it
> *shouldn't*
> be standardized until those issues are resolved. That's not standards
> fatigue,
> it's the process working as designed.

The API addresses the use cases, but people here see those use cases as too basic because they don't represent average users (e.g., Boris' somewhat esoteric network setup). Most people have wifi at home, which is somewhat unmetered - and access to mobile data, which often costs more (but not always true).

The API, though ".type", allows the user and app to have a conversation about that: "you want me to download stuff over mobile? Its might cost ya, but if you are ok with it...".

> None of this seems to add up to a strong argument that this functionality
> should be in Firefox

Certainly things could be improved - but again, the API just addresses the basic use cases (i.e., the 80% case - that gives us parity with native apps). The web still can't do most of the things this API is actually needed for (e.g., enabling apps like audio books, magazine subscriptions, etc.) so it's not too much of a big deal right now that it's not available.

However, if we do get better native integration in the platform (particularly as it relates to multimedia assets), then this will be needed (or people will just use Chrome, as it will provide better control over downloads on mobile - which will be sad).

[Boris Zbarsky]

On 12/22/16 10:31 PM, mcac...@mozilla.com wrote:
> (e.g., Boris' somewhat esoteric network setup)

Just to check, are you talking about my typical setup for accessing the
internet (which is totally non-esoteric laptop talks to wifi talks to
ISP) or the "privacy leak" cases?

> Most people have wifi at home

Right, that is _precisely_ my setup. (And claiming that it's a 600Mbit
or 6933.3 MBit connection as this API spec would require us to do is
nonsense on a pie plate, but maybe we're not talking about that column
of the nice table anymore?)

> which is somewhat unmetered - and access to mobile data, which often costs more (but not always true).

OK, sure, so we want the "does the user have to pay for this?" boolean.

The API sure goes out of its way to hide that information (e.g. you have
to know which of those transport types are typically metered or not)
_and_ make it not forward compatible (new types being added? business
models for existing types changing?).

> The API, though ".type", allows the user and app to have a conversation about that: "you want me to download stuff over mobile? Its might cost ya, but if you are ok with it...".

If this is the use case we're trying to address, a "mayBeMetered"
boolean is the way to go, I believe.

> Certainly things could be improved - but again, the API just addresses the basic use cases

It addresses them _really_ badly, in my opinion.

> However, if we do get better native integration in the platform (particularly as it relates to multimedia assets), then this will be needed

Or a better API that provides the information people actually care
about? Yes, I realize there is a bit of an uphill battle to get people
to actually adopt the better API. I think in this case, this API is
sufficiently horrible that it's worth it...

-Boris

[Eric Rescorla]

On Thu, Dec 22, 2016 at 10:31 PM, <mcac...@mozilla.com> wrote:

> On Wednesday, December 21, 2016 at 12:51:10 AM UTC+11, Eric Rescorla wrote:
> > I'm not really following this argument. Usually when a document has been
> > floating
> > around a long time but clearly has basic design issues and can't get
> > consensus,
> > even when a major vendor has implemented it, that's a sign that it
> > *shouldn't*
> > be standardized until those issues are resolved. That's not standards
> > fatigue,
> > it's the process working as designed.
>
> The API addresses the use cases, but people here see those use cases as
> too basic because they don't represent average users (e.g., Boris' somewhat
> esoteric network setup). Most people have wifi at home, which is somewhat
> unmetered - and access to mobile data, which often costs more (but not
> always true).
>
> The API, though ".type", allows the user and app to have a conversation
> about that: "you want me to download stuff over mobile? Its might cost ya,
> but if you are ok with it...".
>

I don't really think this addresses my argument, which is not about any of
the technical details, but is rather about whether we should adopt
something that's clearly not very good -- which it seems clear you are
conceding here -- just because it's been floating around a long time and
people are tired.

-Ekr

[Ben Kelly]

Can the people who have concerns about the NetworkInformation API please
provide the feedback to google on this blink-dev thread:

https://groups.google.com/a/chromium.org/d/msg/blink-dev/UVfNMH50aaQ/CXY6S39TBQAJ

In particular, I think they tried to consider privacy in this part of the
spec:

https://wicg.github.io/netinfo/#privacy-considerations

Thanks.

Ben

On Fri, Dec 23, 2016 at 10:43 AM, Eric Rescorla <e...@rtfm.com> wrote:

> On Thu, Dec 22, 2016 at 10:31 PM, <mcac...@mozilla.com> wrote:
>

> > On Wednesday, December 21, 2016 at 12:51:10 AM UTC+11, Eric Rescorla
> wrote:
> > > I'm not really following this argument. Usually when a document has
> been
> > > floating
> > > around a long time but clearly has basic design issues and can't get
> > > consensus,
> > > even when a major vendor has implemented it, that's a sign that it
> > > *shouldn't*
> > > be standardized until those issues are resolved. That's not standards
> > > fatigue,
> > > it's the process working as designed.
> >
> > The API addresses the use cases, but people here see those use cases as
> > too basic because they don't represent average users (e.g., Boris'
> somewhat
> > esoteric network setup). Most people have wifi at home, which is somewhat
> > unmetered - and access to mobile data, which often costs more (but not
> > always true).
> >
> > The API, though ".type", allows the user and app to have a conversation
> > about that: "you want me to download stuff over mobile? Its might cost
> ya,
> > but if you are ok with it...".
> >
>

> I don't really think this addresses my argument, which is not about any of
> the technical details, but is rather about whether we should adopt
> something that's clearly not very good -- which it seems clear you are
> conceding here -- just because it's been floating around a long time and
> people are tired.
>
> -Ekr

[Martin Thomson]

On Sat, May 20, 2017 at 2:05 AM, Ben Kelly <bke...@mozilla.com> wrote:
> Can the people who have concerns about the NetworkInformation API please
> provide the feedback to google on this blink-dev thread:

https://groups.google.com/a/chromium.org/d/msg/blink-dev/UVfNMH50aaQ/FEQNujAuBgAJ

In short, I don't think that the privacy concerns are that
significant. It's just that in assessing value against cost they seem
much more significant.