- 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