- From: Alissa Cooper <acooper@cdt.org>
- Date: Thu, 20 May 2010 17:22:48 +0100
- 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 UTC