Re: Pre-LC Review Requested: System Information API

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 16:16:23 UTC