W3C home > Mailing lists > Public > public-device-status@w3.org > December 2011

Network Information API: Mozilla's proposal

From: Mounir Lamouri <mounir@lamouri.fr>
Date: Thu, 29 Dec 2011 16:21:00 +0100
Message-ID: <4EFC855C.5000601@lamouri.fr>
To: "public-device-status@w3.org" <public-device-status@w3.org>
Hi,

Mozilla has been working on a Network API (counter-)proposal [1] and we 
believe it's time to get some feedback from the task force.

The major goal of our proposal is to not show the connection type to the 
content for various reasons cited below.
First of all, it could be easily used to fingerprint and track users: in 
addition of adding new bits of information to fingerprint users, it can 
help know where they are and how they behave. For example, mobile 
devices are usually connecting to a wifi at home and to a mobile network 
outside.

In addition, it could be mis-used to assume that a specific connection 
is too slow or fast. With .type, authors would do stuff like:
if (connection.type == '2g' || connection.type == '3g') {
   doSlowStuff()
} else {
   doFastStuff();
}
But some other connections can be slow (like public wifi) and some 3g 
connections can be fast. For information, what is under the "3G" 
umbrella includes connections from a few hundred kB/s speed (~400 for 
UMTS) to 20Mb/s for HSPA+ or ~50Mb/s for LTE [2].
Unfortunately, Modernizr already has code like above [3]...

Furthermore, .type is not future-proof. Because the web platform is very 
different from other platforms, we have to keep in mind future-proofing 
our APIs and this one is unfortunately not. For example, the code above 
is not future proof because we do not know if another type of slow 
connection is going to appear. In addition, code like this isn't future 
proof:
if (/^[2-9]g$/.test(connection.type)) {
   // We are using a mobile connection so we are not going to put too
   // much stuff in localStorage.
}
This also apply for fast connections: someone might try to test for 4G, 
wifi or ethernet but we can bet that other kind of fast connections are 
going to appear.

The goal of Mozilla's proposal is to have a Network API that doesn't 
expose the connection type but still fulfill all valid use cases. We 
think this is doable with two attributes:
- .bandwidth that gives an estimation of the current download speed of 
the device (in Mb/s), Infinity if unknown and 0 if offline.
- .metered that tells if the current connection is metered. Typically 
when the connection is subject to a pay-per-use contract (you pay for 
each Mb) or a (monthly) quota restrictive enough to prevent heavy 
downloads (for example, a quota of 100G/month isn't restrictive). false 
if unknown or offline.

In addition of those two attributes, there is a change event fired on 
the connection object when .bandwidth or .metered changes.

For implementors, those two attributes might be a bit more complex than 
.type because the bandwidth isn't a simple information to get. For 
Gecko, we assume that precision is neither wanted nor recommended (for 
privacy reasons) so we are going to use estimations based on the current 
connection. This is an implementation detail that should have no impact 
for websites.
.metered has a similar issue: we can't know programmaticaly whether the 
mobile connection used by the user is subject to quota so Firefox might 
ask users and reflect that to websites.

Anyhow, we believe that those two attributes should be able to replace 
.type but we might be missing something so please, feel free to give any 
feedback.

[1] https://wiki.mozilla.org/WebAPI/NetworkAPI
[2] LTE is advertised as 4G but LTE Advanced is actually 4G. LTE is 
"nearly 4G" aka 3.9G.
[3] 
https://github.com/Modernizr/Modernizr/blob/master/feature-detects/network-connection.js

Thank you for reading,
--
Mounir
Received on Thursday, 29 December 2011 15:21:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 29 December 2011 15:21:43 GMT