Re: Pre-LC Review Requested: System Information API

why is an array of active connections a problem?

if indeed there is more than one, then you have to be able to refer to the one of interest, which would imply choosing by type or name?


regards, Frederick

Frederick Hirsch, Nokia



On May 18, 2010, at 3:57 PM, ext Alissa Cooper wrote:

> Hi Frederick,
> 
> I was working off of the editor's draft (http://dev.w3.org/2009/dap/system-info
> ), but you reference the FPWD below, so if I'm supposed to be
> referencing that instead, let me know (the Network/Connection
> attributes are different between the two versions).
> 
> I think steps 1-3 that you enumerate below sound good.
> 
> On the issue of minimizing Network data that is collected, there are a
> few changes I can think of, but some of them kind of depend on what
> the envisioned use cases are for SSID/APN/operator/MCC/MNC, so it
> would be helpful to hear more from the group about that.
> 
> The most straightforward thing to do would be to only provide access
> to the active connection, and to break out MAC address, IP address,
> and possibly SSID, at the very least, into their own properties. So
> the Network property would go back to looking more like it did in the
> FPWD (although perhaps more properly called "ActiveConnection"), minus
> a few attributes that are properties of their own and pertain only to
> the active connection:
> 
> interface ActiveConnectionAttributes: SystemProperty {
>     attribute String         type;
>     attribute unsigned long  currentDownloadBandwidth;
>     attribute unsigned long  currentUploadBandwidth;
>     attribute unsigned long  maxDownloadBandwidth;
>     attribute unsigned long  maxUploadBandwidth;
>     attribute float          currentSignalStrength;
>     attribute DOMString      apn;
>     attribute DOMString      operatorName;
>     attribute boolean        roaming;
>     attribute unsigned short mcc;
>     attribute unsigned short mnc;
> }
> 
> interface ActiveMACAttributes: SystemProperty {
>     attribute DOMString      address;
> }
> 
> interface ActiveIPAttributes: SystemProperty {
>     attribute DOMString      address;
> }
> 
> interface ActiveSSIDAttributes: SystemProperty {
>     attribute DOMString      id;
> }
> I like this sort of approach, but obviously there are potential
> problems with it: (1) there is an open issue about whether to have an
> array of multiple active connections, which would negate this
> approach, and (2) I'm assuming there was some reason for providing
> access to all connections, not just active ones (although a quick
> search through the list did not reveal the reason to me). Putting
> aside (1) since it has yet to be resolved, one way to address (2)
> would be to still provide an array of non-active connections, but not
> include IP, MAC, SSID, or the operator-related attributes in the
> Connection property, and instead provide those attributes only for the
> active connection, like so:
> 
> interface NetworkAttributes : SystemProperty {
>     attribute Connection connections[];
>     attribute Connection activeConnection;
> };
> 
> interface ConnectionAttributes : SystemProperty {
>     attribute String         type;
>     attribute unsigned long  currentDownloadBandwidth;
>     attribute unsigned long  currentUploadBandwidth;
>     attribute unsigned long  maxDownloadBandwidth;
>     attribute unsigned long  maxUploadBandwidth;
>     attribute float          currentSignalStrength;
> };
> 
> 
> interface ActiveMACAttributes: SystemProperty {
>        attribute DOMString      address;
> }
> 
> interface ActiveIPAttributes: SystemProperty {
>        attribute DOMString      address;
> }
> 
> interface ActiveSSIDAttributes: SystemProperty {
>        attribute DOMString      id;
> }
> 
> interface ActiveOperatorAttributes: SystemProperty {
>     attribute DOMString      apn;
>     attribute DOMString      operatorName;
>     attribute boolean        roaming;
>     attribute unsigned short mcc;
>     attribute unsigned short mnc;
> };
> 
> I understand that these aren't the prettiest solutions in the world,
> but I think either would strike a better balance than the editor's
> draft does between giving developers what they might be looking for
> and not giving away too much information needlessly.
> 
> Alissa
> 
> On May 17, 2010, at 9:45 PM, <Frederick.Hirsch@nokia.com> <Frederick.Hirsch@nokia.com
>> wrote:
> 
>> Alissa
>> 
>> Thanks for the comments. It seems we still have the following steps
>> before Last Call of SysInfo:
>> 
>> 1 Add a note to the draft regarding the risk of fingerprinting. (I
>> thought I saw this before but now cannot find it)
>> 
>> 2 Restore the original privacy text, (all or a portion of it, in
>> addition to the new note)
>> 
>> 3 deal with privacy concerns you note regarding the network property
>> 
>> At a minimum, the attributes listed after currentSignalStrength
>> should probably each have a note that user consent is required to
>> share due to the fact that they can identify the user:
>> 
>> macAddress
>> ipAddress
>> ESSID
>> apn
>> 
>> 
>> The following also probably need such note as well since this again
>> is information that probably is sensitive:
>> 
>> operatorName
>> roaming
>> 
>> Alissa, do you have any concrete suggestions for changes to the
>> current draft specification?
>> 
>> http://www.w3.org/TR/2010/WD-system-info-api-20100202/#network
>> 
>> regards, Frederick
>> 
>> Frederick Hirsch, Nokia
>> co-chair DAP WG
>> 
>> 
>> 
>> On May 17, 2010, at 12:15 PM, ext Alissa Cooper wrote:
>> 
>>> I have some thoughts about this API given the conversations we've had
>>> in this group about data minimization. Viewed one way, this API
>>> doesn't really do much to help developers minimize data collection.
>>> To
>>> take just one example, consider an app that only needs to know
>>> whether
>>> the device supports multitouch (as in the example in 4.12). The only
>>> way that the app can find this out --
>>> naviagtor.system.get("InputDevices", . . .) -- will return not only a
>>> list of pointingDevices with supportsMultiTouch properties, but also
>>> all of the other InputDevices attributes and all of their properties:
>>> pointingDevices[], activePointingDevices[], keyboards[],
>>> activeKeyboards[], cameras[], activeCameras[], microphones[], and
>>> activeMicrophones[]. This is basically the opposite of minimization
>>> --
>>> giving the app a whole bunch of data that it doesn't need and
>>> therefore should not have had in the first place.
>>> 
>>> But, viewed another way, a lot of this data is pretty benign from a
>>> privacy perspective. I might go so far as to say that Input, Output,
>>> Codecs, Storage, and Power are all fairly innocuous from a privacy
>>> perspective (putting aside the fingerprinting issue discussed below).
>>> They just don't say much about the user or his/her use of the device.
>>> So the fact that lots of details about the input devices or the
>>> codecs
>>> or the power supply get shared in response to a single API call is
>>> not
>>> likely to be problematic.
>>> 
>>> Unfortunately, the same cannot be said for the Network property.
>>> Taking the example from the spec, an app that simply wants to monitor
>>> WiFi signal strength will, with a single get() or monitor(),
>>> automatically obtain all of the MAC addresses and IP addresses
>>> assigned to the device. As MAC addresses are unique per interface and
>>> IP addresses are potentially unique per interface, this amounts to
>>> handing multiple unique device identifiers to every app that wants to
>>> monitor signal strength, or check download bandwidth, or find out the
>>> cell operator's name, or do a hundred other things that do not
>>> require
>>> knowing the MACs and IPs of every single network interface on the
>>> device.
>>> 
>>> This strikes me as a major overreach. If it were possible to inquire
>>> only about a single network connection, that would make more sense
>>> from a privacy perspective. What would be even better would be to
>>> establish IP address and MAC address as individual properties to be
>>> requested separately from the rest of the network connection
>>> attributes.
>>> 
>>> For SSID, I'm having a hard time understanding what the use cases
>>> are,
>>> other than apps that want to use SSID as a proxy for the user's
>>> location (e.g., to know if the user is connected to a network named
>>> "home"). Is that the idea behind exposing the SSID, given that we
>>> already have the type attribute that can be set to "WiFi"? If so, it
>>> again seems as though a separate request would be more suitable. And
>>> as APN, operator name, MCC, and MNC all reveal some coarse location
>>> information, it seems like those at the very least should be exposed
>>> only for a single network connection per request.
>>> 
>>> The fact that these issues crop up much more for the Network property
>>> than the other properties points to another potential issue: user
>>> permission. I was surprised that Max removed the entire privacy
>>> considerations section and replaced it with the issue that is there
>>> now; I had thought that we would keep both the text and the issue. In
>>> any event, at some point we will have to deal with whether to obtain
>>> user permission before sharing sys info properties through the API.
>>> As
>>> I said above, lots of these properties seem pretty benign, and I
>>> worry
>>> that if we require user permission for each one, we will only
>>> exacerbate user fatigue with consent screens and cause people to
>>> ignore them more than they already do. With that said, I think at the
>>> very least MAC address and SSID rise to the level of needing user
>>> permission. The case could perhaps also be made for user permission
>>> for the sensor attributes, which could easily be used to determine
>>> where someone is NOT, and in some circumstances where someone IS. So
>>> to my mind the question is whether we will distinguish between
>>> different properties when it comes to requiring user permission. It
>>> seems like the right thing to do.
>>> 
>>> (Side note on proximity: I know the WG had some discussions about
>>> what
>>> the proximity sensor is meant to measure, but for someone who just
>>> picks up the spec without having been on the mailing list, I think
>>> the
>>> description of the proximity property is really vague. What does it
>>> mean to "the measured distance between the device and a nearby
>>> object"? I think some explanatory text about the whole phone-near-
>>> the-
>>> ear situation would be helpful.)
>>> 
>>> Finally, I know we closed ISSUE-79 about the use of sys info for
>>> fingerprinting the device, but I thought at some point we talked
>>> about
>>> at least noting the fact that combining lots of these properties
>>> could
>>> allow apps to uniquely fingerprint devices, and perhaps discouraging
>>> apps from doing so? I think this is particularly warranted if the API
>>> takes its current non-minimization approach of providing every
>>> attribute for a property even when they are not all needed by the
>>> app.
>>> As it stands, the API could actually be facilitating fingerprinting
>>> by
>>> supplying more vectors of uniqueness to apps than it needs to. Plus,
>>> UAs that implement this API will be exacerbating the fingerprinting
>>> issue that they're already facing [1] since so many of the device
>>> properties are not user-changeable, and thus once your device has
>>> been
>>> fingerprinted, there won't be much you can do to de-identify it.
>>> 
>>> Alissa
>>> 
>>> [1] https://panopticlick.eff.org/
>>> 
>>> On May 5, 2010, at 4:24 PM, Robin Berjon wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> as part of its work the DAP WG has been developing a System
>>>> Information API. The abstract describes it thus:
>>>> 
>>>> """
>>>> This specification defines an API to provide Web applications with
>>>> access to various properties of the system which they are running
>>>> on. Specifically, properties pertaining to the device hardware are
>>>> addressed. Examples include battery status, current network
>>>> bandwidth. Additionally, some of those properties offer access to
>>>> the environment around the device, such as ambient brightness or
>>>> atmospheric pressure.
>>>> """
>>>> 
>>>> We are looking at pushing that document into Last Call soon, if all
>>>> goes well in two weeks' time. In order to help things go smoothly,
>>>> if you have an interest in this simply take a good look at it and
>>>> send us any feedback that you may have.
>>>> 
>>>> You can read the current Editor's Draft at:
>>>> 
>>>> http://dev.w3.org/2009/dap/system-info/
>>>> 
>>>> One specific question that we have is whether maxZoomFactor is
>>>> enough (with the assumed minimal factor of 1) or whether there are
>>>> cases in which zoom factors below 1 or (Eris forbid) below 0 are
>>>> ever used (perhaps for wide angle shots). But of course, all topic
>>>> are open.
>>>> 
>>>> Thanks a lot for any input!
>>>> 
>>>> --
>>>> Robin Berjon - http://berjon.com/
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
>

Received on Wednesday, 19 May 2010 13:34:18 UTC