Bridged connections

[marcoscaceres]

We need to work out how to deal with bridged connections... as shown below:

[marcoscaceres]

Related comment from @slightlyoff on BlinkDev: https://groups.google.com/a/chromium.org/d/msg/blink-dev/R5yYtHEPiw4/VGHKgcnxOFEJ

[johnshih]

HI, I'm guessing this case is to identify the connection type is "external" or "internal". The connection type in current proposal such as "ethernet", "wifi", "cellular" are all assumed to be "external" connection. However, connection type could also be "internal" if a computer connects to internet through bridged connections (as you mentioned) or tethering. Is it right?

[marcoscaceres]

@johnshih, yes, that is right. I don't know what impact that has on the API, if any.

[johnshih]

My concern is does the API really need to provide information about whether the connection is "internal" or not? Is there any use case? If yes, maybe we could provide one more type for such kind of connection to keep the API simple. Otherwise it can just be classified into type "unkown".

[sicking]

I don't think it's possible to detect that the wifi network you are connecting to is just bridging to a cellular network. I.e. I don't think the wifi protocols have the ability to forward that information, or at least contemporary tethering implementations doesn't do that.

So I think we're forced to ignore bridging networks for now. Devices that connect through such a bridge will think they are on wifi, while they in reality is on cellular.

As far as I can tell this is what iOS and Android already do.

[igrigorik]

@sicking I'm not sure what the mechanism is... haven't had a chance to dig into it. But I'm told that Android can infer when its on a bridged connection: namely, if an Android device is connected to a WiFi AP which itself is a hotspot powered by another Android device, then the Wi-Fi connection is automatically treated as "metered".

[ferjm]

Is this really relevant for the API design? I agree with @sicking's comment at https://bugzilla.mozilla.org/show_bug.cgi?id=960426#c8 This looks like an implementation detail and even if the UA is able to infer when it is on a bridged connection, it seems that the correct thing to do might be to expose only the type of the upstream connection. Is there any use case where additional information other than the upstream connection type is needed?

[marcoscaceres]

It would only be relevant if the UA was able to communicate over 2+ network connections at the same time. That would change the API a little bit.

[sicking]

2+ networks at the same time is not a usecase that I think we should care about for now. Few if any popular devices do this today. And even if the odd piece of hardware exists that support it, it's unlikely that anyone is going to write code that uses the network information API to behave differently in response to it.

If it becomes commonplace in the future we can add to the API then.

[marcoscaceres]

If we are going to care about it later, then it's better to design the API as if it might happen. Having to change data types for the connection type attribute (e.g., from a string to a sequence) would make things messy. Better to make it a sequence rom the start, even if it just returns 1 item.

[sicking]

It's not obvious to me what an API that exposes 2+ connections would look like. As an author, it likely doesn't help to know "user is connected to wifi and cellular right now". What you want to know is "will the download of this big/non-critical resource happen over cellular". This might be a function of where you're connecting, or where you're connecting from. Or something else.

In other words, attempting to future-proof the API can cause as much harm as it does good since we might misunderstand the requirements of those future features.

[marcoscaceres]

Yeah, fair enough.

[johnshih]

It seems no further progress for the discussion in BlinkDev, should we work on our proposal (idl part) and have some discussion & feedback first?

[marcoscaceres]

Sure, why not :) Closing this.