Re: Network Information API published as FPWD

On 06/14/2011 01:12 PM, 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.
>
>> 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.
>
>> - The operational state of an interface. An interface may be absent,
>> present-but-disabled, present-but-unconnected, or present-and-connected.
>
> See above.
>
>> - 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.


Even the current API allows a bit too much fingerprinting, I think.
The fact that web app can know that user is using 2G connection
is a quite strong hint (at least in some countries) that user is
somewhere in the countryside. (There are perhaps already other ways to
detect that, but this is a new way)
The connection type is yet more information about user and his devices
the web apps can get, and so it perhaps should be accessible only
if user gives the permission.


-Olli




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

Received on Tuesday, 14 June 2011 13:59:46 UTC