- From: Robin Berjon <robin@robineko.com>
- Date: Wed, 26 May 2010 13:17:50 +0200
- To: Alissa Cooper <acooper@cdt.org>
- Cc: W3C Device APIs and Policy WG <public-device-apis@w3.org>
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 Wednesday, 26 May 2010 11:18:18 UTC