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