W3C home > Mailing lists > Public > public-coremob@w3.org > July 2012

RE: Network Information Use Cases

From: Josh Soref <jsoref@rim.com>
Date: Wed, 4 Jul 2012 20:31:11 +0000
To: Core Mobile <public-coremob@w3.org>
CC: DAP <public-device-apis@w3.org>
Message-ID: <957F1ECDA90E004B8DBDE23CFC94E3A33A4CBB23@XMB103ECNC.rim.net>
Jean Francois Moy <jeanfrancois.moy@orange.com> wrote:
> Sent: Wednesday, July 04, 2012 10:45 AM
> To: public-coremob@w3.org
> Subject: Network Information Use Cases
> 
> Hello everyone,
> 
> I had been assigned an action point that consists of describing use cases that
> would encourage the inclusion of the Network Information APIs
> <http://www.w3.org/TR/netinfo-api/>  in the Core Mobile level 1 specification.

Thanks for the information.

> I will list a few below:
> *         Visual Voicemail platforms: Visual voicemail platforms are commonly
> accessible only through 3G (platform access is restricted from the Internet).
> The NetworkInformation APIs are required to detect the current interface, and
> switch to 3G if a voicemail needs to be fetched. The Orange OMTP platforms
> notably work like that.

This is a bug in the platforms (or you could call it a "missing feature"). Switching the general connection could break a streaming video or other active links. The correct thing to do is for Orange (and friends) to add proper authentication for their platform so that it can deliver a token to the application which it can then use while it isn't on Cellular.

Google Mail / Google Voice are able to do this (SMS 2FA / Application tokens).

> *         TV Services: TV services and streams are secured and encrypted and use
> the SIM and 3G network  for the authentication process. After the
> authentication has been performed, it is possible to offload through the Wi-Fi
> connection.

This is a horrible abuse of 3G. It sounds like you want access to the Secure Element (SE). That's either in scope for the new Crypto WG, for NFC (but hopefully not) which might be abused for SE access, or Sys Apps.

> *         Usage Applications: Most carriers provide applications that give real time
> minutes and data usage for a user, as well as the possibility to
> subscribe/unsubscribe to/from various options. Servers storing these
> information can only be accessed through 3G access.

This is a bug (Like the first). I can subscribe/unsubscribe to services by calling Wind Mobile (Canada) from a land line and giving them sufficient information to authenticate me. I shouldn't have to use your 3G network to check status. If I'm outside of your coverage zone ("roaming", e.g. to Japan), why shouldn't I be able to use WiFi to check used minutes?

> As you see, it is important for carriers to know the current network, mostly for
> authentication purposes, but also as some of our platforms are not accessible
> from the Internet. It would also be nice to be capable of routing a connection
> through an interface, but that's another story.

Authentication purposes are not a remotely valid use case. Send an SMS to the device, let the user use that to answer a challenge. It works for Google, it works for Facebook. There's also SMS push or something which Bryan is asking for. That would actually be a more acceptable path forward than abusing Network Information.

Please note that you don't need network information to find out if you're on cellular for these use cases, your local dns address will tell you, and the act of talking to the server is sufficient to tell you to go away.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Received on Wednesday, 4 July 2012 20:31:47 UTC

This archive was generated by hypermail 2.3.1 : Friday, 19 April 2013 17:36:46 UTC