Re: Pre-LC Review Requested: System Information API

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 Monday, 17 May 2010 20:47:29 UTC