Re: [W3C WebMob] Data Info API

Comments below:

> On 14 Oct 2014, at 06:04, SULLIVAN, BRYAN L <bs3131@att.com> wrote:
> 
> 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 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.

I would definitely echo your comments on the usefulness of the Network Info API.  I’m not entirely sure what the perceived down-side is.  The browser people seem to think the Netinfo API is “not needed” but I agree it’s just exposing info that the device has anyway. 

However, I still think a “data plan” info (network) API could also be useful, especially if this info could be surfaced to the (web) application itself, which would know more about the context. For example, a streaming video service could evaluate how much of the user’s data plan would be impacted if they streamed a specific video and warn the user using service-specific meaningful language “you are going to use up 30% of your allowance” or “you’re going to go over your data allowance if you stream this - you might want to switch to Wifi”. So I see this as enabling clearer messaging to the end user which should hopefully be accessible to a wider audience - not only the tech-savvy.

But agreed, knowing the current bearer (and roaming status) would be essential in order for this to make any sense.

By the way, this is all privacy-sensitive and finger-print-enabling information so it plays into the whole permissions question as well, see the latest TAG discussion on this topic here https://github.com/w3ctag/meetings/blob/gh-pages/2014/sept29-oct1/09-30-f2f-minutes.md#permissions with proposal from Alex Russell https://gist.github.com/slightlyoff/43cd8c2f64a0719358fe. 

Dan

Received on Tuesday, 14 October 2014 13:45:37 UTC