Re: Network Information API published as FPWD

On 06/14/11 12:12, Dominique Hazael-Massieux wrote:
> Le mardi 14 juin 2011 à 11:56 +0200, Harald Alvestrand a écrit :
>> This draft is mercifully short, but is also likely to be so simplistic
>> as to be less than useful.
> Are you saying it is useless, or harmful? It seems to me to be
> fulfilling a number of use cases (so I don't think it's useless), but I
> could be missing points that make it harmful.
More useless than harmful, I think.
>> The API is not able to represent:
>> - Boxes with multiple, simultaneously operational interfaces. This
>> occurs frequently with laptops, and is theoretically possible even on
>> Android.
> The current notion is that the API would expose whichever connection the
> browser is currently using. That doesn't preclude us from exposing more
> connections later on, but that specific connection is likely the one on
> which the developer is most likely to want to know about.
>
But that (the connection the browser is currently using) is actually not 
a well-defined notion.

A not atypical case is an Android phone that's acting as a tethered 
access point - both its wlan and 3G interfaces will be active, and 
passing data, and the browser may in fact be accessing servers on both 
interfaces.

If the spec is modified to say that this interface exposes the hardware 
on the *default* interface, my grumblings will be modified.
>> - The operational state of an interface. An interface may be absent,
>> present-but-disabled, present-but-unconnected, or present-and-connected.
> See above.
>
So the browser would only fire the "online" event when a device is 
actually entered into the IP routing table as the default device, and 
fire the "offline" event when there is no default route to an active 
device in the routing table? That would at least be well-defined.

("routing table" is a well defined term on both Linux and Windows boxes 
- and in this aspect, Android is a Linux box. I don't know that much 
about other platforms.)
>> - Any handle to get more information about the interface.
> What kind of further information do you have in mind? One of the reasons
> the interface is very simple is that we want to avoid exposing too much
> information, e.g. to prevent further input for "fingerprinting"
> browsers.
IP addresses would be one obvious candidate. If the people who argue for 
ICE candidate collection in the Javascript over at RTCWEB come out as 
the "winner", they will need the ability to learn addresses from interfaces.

Protocols supported is another - IPv4 and IPv6 are the two big ones 
today; there have been others in the past, and there may be others in 
the future.
>> This simplicity may be justified if the purpose is to designate the type
>> of interface that the device is currently routing packets out of in the
>> absence of specific other information (the default route), but then the
>> specification needs to say that this is what the API is supposed to
>> represent.
> Fair point, indeed. I expect Robin or Suresh will want to fix this.
As long as it's well defined what it's supposed to represent, I'm less 
worried.

Received on Tuesday, 14 June 2011 10:49:08 UTC