W3C home > Mailing lists > Public > public-device-apis@w3.org > May 2010

Sys Info network attributes

From: Alissa Cooper <acooper@cdt.org>
Date: Thu, 20 May 2010 17:22:48 +0100
Message-Id: <6BEB465A-A2E8-457B-9842-0EB71F43E305@cdt.org>
To: W3C Device APIs and Policy WG <public-device-apis@w3.org>
These are the attributes in the Network property right now:

    attribute String         type;
    attribute unsigned long  currentDownloadBandwidth;
    attribute unsigned long  currentUploadBandwidth;
    attribute unsigned long  maxDownloadBandwidth;
    attribute unsigned long  maxUploadBandwidth;
    attribute DOMString      macAddress;
    attribute DOMString      ipAddress;
    attribute float          currentSignalStrength;
    attribute DOMString     SSID;
    attribute DOMString      apn;
    attribute DOMString      operatorName;
    attribute boolean        roaming;
    attribute unsigned short mcc;
    attribute unsigned short mnc;

Here is what I would recommend with an eye toward balancing privacy  
with functionality:

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.

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).

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.)

As noted earlier [1], these five attributes give some coarse location  
information, and therefore I think they (or whatever subset of them we  
keep) should, as a group, be separately queryable via get() from all  
of the other properties. That is, an app that just needs to know  
download bandwidth or signal strength should not also receive the  
operator-related values, but I think its fine to bundle the operator- 
related values together as a single property, since apps are likely to  
need multiple of them at once if they need any of them at all.

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. If we keep SSID, I would worry about the combination of  
SSID and signal strength being used to do an out-of-band query to  
something like the Skyhook WiFi database to obtain geolocation info on  
the sly. But signal strength absent SSID seems like a useful item.

Alissa
Received on Thursday, 20 May 2010 16:23:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:09 GMT