RE: [W3C WebMob] Data Info API

Hi Natasha,

Some quick comments. I'll send it around also for more.

This is something that the GSMA Personal Data program could consider as part of the OneAPI Exchange program, e.g. enabled by Mobile Connect<http://gsmamobileeconomy.com/gsmamc/> as the basic OpenID Connect based framework through which a personal data scoped query can be made into the subscriber's data plan. But that would IMO be the easy part...

Such an API would likely not rely upon header injection for authentication, as that anachronistic approach would not work anyway for secure API's (which this would certainly be). Authentication methods can be out of scope/orthogonal, e.g. as in OpenID Connect and Mobile Connect.

But more importantly...

*         Even with knowledge about the data plan, it's still not so simple to assess the impact of any particular service as that depends upon the context and the service itself. Context can include e.g. roaming status and the relationship if any of the service providers or referenced resources to "toll free data" arrangements.

*         Displaying this information to the user may not be all that helpful also, if the user is expected to make some decision given current context. The meaning of the information would need to be explained carefully, and still there would likely be misunderstanding. Clearly tech-savvy road-warrior types would be able to understand, but do we really want to add such decision burdens to the average user?

*         Finally, knowing what type of network connection would ultimately be used for a service would be essential to really making this useful. We have tried for a long time to get browser vendors to support this info (e.g. simply the type of attached network, or a "WiFi" boolean) e.g. through the Network Information API, to no avail.  This despite the info being easily available from device platforms, and simple to understand in terms of value to developers. Further, letting an app choose the type of network connection that should be used for a service/XHR/websocket/etc would be the real nirvana, but is even less likely.

I would suggest that W3C revisit the Network Information API and add the features above, before we give additional information to apps through other network APIs, especially information that leaves the developer still unsure of the impact in the current context, or without options to change the current context programmatically.

Thanks,
Bryan Sullivan | Service Standards | AT&T

From: Natasha Rooney [mailto:nrooney@gsma.com]
Sent: Monday, October 13, 2014 8:26 PM
To: W3C Webmob Public
Subject: [W3C WebMob] Data Info API

Hi team!

I wanted to let you know that a few people from Mozilla, Google and Marcos and I have been chatting about a possible Data Info API. The API would return information about a user's network data plan - this can then be used within the app to (for example) serve content which serves up less resources or maybe display the network status to the user so they don't start watching a high-def movie on the train! We imagine there could be even more uses for this API, including using the API within web-based platforms to display details of the user's plan directly to the user.

I have spoken with some operators directly on this, and thanks to those who have given a great response on this so far! I would like all members of the group to take a look at the API rough plan (attached) and let us know what you think. If you're a telecomms company member (and especially an operator) and you'd like to be involved in building or testing this, definitely get involved soon!

Thanks everyone!

Natasha


Natasha Rooney | Web Technologist | GSMA | nrooney@gsma.com<mailto:nrooney@gsma.com> | +44 (0) 7730 219 765 | @thisNatasha | Skype: nrooney@gsm.org<mailto:nrooney@gsm.org>
7th Floor, 5 New Street Square, London EC4A 3BF


This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 356 0600 and highlight the error.