RE: Sys Info network attributes

> I can see how apn, operatorName, roaming, mcc, and mnc could be useful for tailoring services for specific networks. One question is whether having apn, operatorName, and mnc is redundant.

I would vote to remove mcc and mnc since these are redundant from my quick research. It seems like you can represent apn as:

Examples of APN are:

    Example: internet.mnc012.mcc345.gprs
    Example: internet (NOTE: This APN example does not contain an operator identifier part)

As for operatorName, it might also be redundant also since you can derive it from the mnc and mcc within the apn string, but I vote that we keep this otherwise the web app needs to do a mapping or table lookup of operatorName based on mnc and mcc.

Thanks
Dzung Tran


-----Original Message-----
From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of Robin Berjon
Sent: Wednesday, May 26, 2010 04:18 AM
To: Alissa Cooper
Cc: W3C Device APIs and Policy WG
Subject: Re: Sys Info network attributes

On May 20, 2010, at 18:22 , Alissa Cooper wrote:
> 1. Remove macAddress and SSID from the API altogether. The rationales for exposing hardware identifiers are slim to none, IMO. The only use I can think of for SSID is to geolocate the device and the W3C is standardizing a way to do that separately, so there's no need to expose SSID.

+1

> 2. Probably remove ipAddress as well. For web-based apps, won't they already have an IP address for the device (since they got the code there somehow)? For widgets running locally, what will they do with the IP address? Won't outbound communications be handled at the OS layer?  Moreover, in lots of cases the IP address known to the device is likely to be a non-public IP address (behind a router or gateway), which might make it even less useful to apps and widgets in those cases (and revealing details about internal networks might raise red flags for some network security configurations in certain contexts, like corporate enterprises).

+1 If you need the IP address of the endpoint you're seeing you can already get it of course, but if the user is NATed that won't be her IP. If you get the NAT's IP *and* the internal IP this becomes information that can be very easily used to track people (in a lot of enterprise networks, a workstation would not see its IP change, or only infrequently which can be circumvented with other means).

> 3. I can see how apn, operatorName, roaming, mcc, and mnc could be useful for tailoring services for specific networks. One question is whether having apn, operatorName, and mnc is redundant. What can an app learn from one of those that it can't glean from one of the others? I don't know enough about cell networks to answer that question, but if they are redundant, it probably makes sense to only include the one that subsumes the others. (And here again, I wonder whether revealing private APNs would create security warnings.)

I can definitely see use cases for roaming (e.g. don't load that sexy but heavy font). I'm unclear on use cases for the others.

> 4. I think the remaining attributes -- type, currentDownloadBandwidth, currentUploadBandwidth, maxDownloadBandwidth, maxUploadBandwidth, currentSignalStrength -- are both useful and incur little privacy risk, and thus it makes sense to return them in response to a single get() call.

+1

--
Robin Berjon
  robineko - hired gun, higher standards
  http://robineko.com/

Received on Thursday, 27 May 2010 04:25:17 UTC