Re: Intent to ship: NetworkInformation

[Martin Thomson]

On Sat, May 20, 2017 at 2:05 AM, Ben Kelly  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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[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  wrote:

> On Thu, Dec 22, 2016 at 10:31 PM,  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
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Eric Rescorla]

On Thu, Dec 22, 2016 at 10:31 PM,  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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Boris Zbarsky]

On 12/22/16 10:31 PM, mcace...@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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[mcaceres]

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).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[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.


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Eric Rescorla]

On Mon, Dec 19, 2016 at 10:58 PM,  wrote:

> 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).
>
> > >> 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.
>
> 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 

Re: Intent to ship: NetworkInformation

[mcaceres]

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.  
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[mcaceres]

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.
 
> As things stand now, neither of the above are true to the best of my
> knowledge.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[mcaceres]

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). 

> >> 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.

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 

Re: Intent to ship: NetworkInformation

[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.














___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Martin Thomson]

On Mon, Dec 19, 2016 at 8:23 PM, 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?"...?

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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[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  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.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Karl Dubost]

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

Le 16 déc. 2016 à 04:39, Ehsan Akhgari  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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[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 
> 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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Ralph Giles]

On Fri, Dec 16, 2016 at 12:25 PM, Jason Duell  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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Jason Duell]

On Fri, Dec 16, 2016 at 11:35 AM, Tantek Çelik 
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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Tantek Çelik]

On Fri, Dec 16, 2016 at 10:51 AM, Gervase Markham  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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[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...  :/

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[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  wrote:

> On Fri, Dec 16, 2016 at 10:28 AM, Boris Zbarsky  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*.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Martin Thomson]

On Fri, Dec 16, 2016 at 10:28 AM, Boris Zbarsky  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*.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[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.  :(

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[smaug]

On 12/15/2016 09: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?  Why are we exposing all this other stuff instead?

-Boris



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.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Tantek Çelik]

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.

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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[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:
.
 It seems that they ship both the type and typechange events:
.

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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[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:
.
 It seems that they ship both the type and typechange events:
.

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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Jonathan Kew]

On 15/12/2016 17:20, Ben Kelly wrote:

On Thu, Dec 15, 2016 at 12:06 PM, Boris Zbarsky  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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Ben Kelly]

On Thu, Dec 15, 2016 at 12:06 PM, Boris Zbarsky  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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Ben Kelly]

On Thu, Dec 15, 2016 at 11:14 AM, Boris Zbarsky  wrote:

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


if (navigator.connect.downlinkMax > 100) {
  // perform low-priority background downloads
}
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Ben Kelly]

On Thu, Dec 15, 2016 at 8:42 AM, Boris Zbarsky  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  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?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Ben Kelly]

On Thu, Dec 15, 2016 at 3:28 AM, Andrea Marchesini 
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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Daniel Stenberg]

On Thu, 15 Dec 2016, Boris Zbarsky wrote:

Looking at the use cases document at 
, 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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Eric Rescorla]

On Thu, Dec 15, 2016 at 6:42 AM, Boris Zbarsky  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  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-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[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 
, 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-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform