Re: Sys Info network attributes

Some notes from the phonegap team for consideration:

- MAC addresses can be used to uniquely identify a network device
which we can/have/do use for some apps. I can give some specific use
cases here if neccessary. We feel this is useful in the spec and not
really a threat.
- Also: MAC addresses can be spoofed!
- IP Addresses only give a rough estimate of where a person is...and
if we don't include it can be easily retrieved with
http://whatismyipaddress.com anyhow. We should include in the spec.
- Of possible interest: NONE of the prev mentioned api calls can be
achieved on an iPhone! (w/ the "public" apis anyhow) only the "Device
unique ID"
- In Canada on Rogers network and ALL Blackberry devices the IP
address is the same for all devices! *facepalm*






Brian LeRoux, Nitobi Software
---
Office: +1 (604) 685-9287
Toll-Free (North America Only): 1-866-632-2777
Cell: +1 (604) 868-1978
http://blogs.nitobi.com/brian
http://www.nitobi.com
http://twitter.com/brianleroux



On Thu, May 20, 2010 at 9:22 AM, Alissa Cooper <acooper@cdt.org> wrote:
> 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 21:24:13 UTC