- From: Mounir Lamouri <mounir@lamouri.fr>
- Date: Thu, 29 Dec 2011 16:21:00 +0100
- 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 UTC