SysInfo buckets

On last week's call, I said that I would put onto the list a possible  
grouping of SysInfo properties that could be used for getting user  
permission to pass on those properties.  Apologies for getting this to  
the list only a couple of hours before today's call.

These buckets would begin to address the questions of "do you need a  
consent for each separate SysInfo element" or "does one consent from  
the user authorize the passing of all SysInfo elements."  My proposal  
is to group the properties into three groups, requiring a separate  
user consent for each group.  The first two groups mentioned below are  
fairly straight forward, while I acknowledge that some may argue that  
the third group could be folded into the first.

Using the 16 June 2010 draft as the starting point, I would group the  
properties as follows:

Bucket 1: Device characteristics and capabilities (data points that  
describe features or limits of the user's device), including:

4.4 Power
4.5 CPU
4.6 Thermal
4.9 Audio and Video Codecs
4.10 Storage Access
4.11 Output Devices
4.12 Input Devices

Bucket 2:  Environmental sensor results (data points that describe  
things about the user's environment external to the device), including:

4.8 Sensors

Bucket 3:  Network characteristics (data points that describe features  
or limits of the network connection(s) that is available to the  
device), including:

4.7 Network

I believe that, in general, all of the properties in Bucket 1 have a  
very low level of sensitivity, and in terms of user understanding, can  
be easily grouped together.  Both Sensors (in Bucket 2) and Network  
(in Bucket 3) raise more privacy concerns, and also I think are fairly  
distinct things in terms of user understanding.

Sensors can reveal potentially sensitive info about where the user is  
(both "inside a building" versus "outside a building," as well as "in  
Iceland" versus "in Honduras").  I also think in terms of user  
expectation and surprise, the Sensors property have the highest chance  
of feeling (to use a highly technical term) spooky to users.

Especially because the current draft appropriately removed a number of  
potentially sensitive enumerable properties, Network is certainly less  
sensitive than it used to be.  But I would still argue that Network  
properties can still reveal potentially sensitive info about where the  
user is, such as both "in your home territory" versus "roaming," as  
well as in some contexts "in your home or office itself (where you  
have a higher speed data connection)" versus "away from your home or  
office (where you are relying on a slower network)."  I also think in  
terms of user understanding, Network properties do not fall neatly  
into "Device characteristics" or "Environmental results," and that  
some (particularly corporate security directors) would be quite  
sensitive to the information that these properties can reveal.  So  
although one could argue that Network properties should be lumped into  
Device characteristics, I would argue for a separate user interaction/ 
decision point before these properties can be passed.

I also appreciate that one could accomplish everything suggested above  
without the idea of "buckets" or "groups" -- by saying that "you only  
need one permission for all SysInfo properties EXCEPT for two  
sensitive properties (Sensor and Network) which require their own user  
permission".  I do not feel strongly about how the groupings are  
accomplished within the spec.

John


On Jun 29, 2010, at 8:16 PM, Doug Turner wrote:

> same.  regrets.  i typically don't call in due to conflicts, but i  
> look forward to reading about the permissions js api that I put  
> forward.
>
> Doug Turner
>
>
> On Jun 29, 2010, at 5:13 PM, Suresh Chitturi wrote:
>
>> Hi Frederick, all,
>>
>> Please accept my regrets due to travel.
>>
>> Regarding the Contacts API publication note that I have a couple of  
>> emails sent to the reflector re serviceId and the use of PoCo  
>> schema, which I would like to add to the agenda for group discussion.
>>
>> Thanks,
>> Suresh
>>
>> ----- Original Message -----
>> From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com]
>> Sent: Tuesday, June 29, 2010 06:12 PM
>> To: public-device-apis@w3.org <public-device-apis@w3.org>
>> Cc: Frederick.Hirsch@nokia.com <Frederick.Hirsch@nokia.com>
>> Subject: Agenda - Distributed Meeting 2010-06-30
>>
>> Agenda — Device APIs and Policy Working Group — Distributed  
>> Meeting  #34  2010-06-30
>>
>> Regrets: Dominique_Hazael-Massieux, Thomas_Roessler, Dzung_Tran
>>
>> Meeting details at the bottom of this email.
>>
>> 1) Welcome, agenda review, scribe selection
>> • Note any additions or changes to agenda
>> • Select scribe: <http://www.w3.org/2009/dap/victims-list.html>
>>
>> 2) Announcements, meeting planning, logistics
>>
>> F2F in London
>>
>> Please complete DAP registration form (even if you do not plan to  
>> attend)
>> <http://www.w3.org/2002/09/wbs/43696/london2010/>
>>
>> F2F Agenda - suggested agenda items, other suggestions?
>>
>> TPAC registration and information available (F2F after London F2F,  
>> 4-5 November )
>>
>> <http://lists.w3.org/Archives/Member/member-device-apis/2010Jun/0001.html 
>> >
>>
>> Policy and Privacy requirements published
>>
>> http://www.w3.org/News/2010#entry-8845
>>
>> 3) Minutes approval
>>
>> • 23 June 2010
>>
>> <http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/att-0266/minutes-2010-06-23.html 
>> >
>>
>> 4) Policy -  "checkPermissions"
>>
>> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0279.html 
>>  (Dom)
>>
>> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0285.html 
>>  (Frederick)
>>
>> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0286.html 
>>  (Doug)
>>
>> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0289.html 
>>  (Doug)
>>
>> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0304.html 
>>  (Robin)
>>
>> 5) Policy - WICDA
>>
>> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0280.html 
>>  (Robin)
>>
>> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0281.html 
>>  (Dom)
>>
>> 6) APIs - Contacts
>>
>> serviceId
>> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0269.html 
>>  (Dom)
>>
>> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0278.html 
>>  (Richard)
>>
>> Next steps, publication?
>>
>> 7) APIs - SysInfo
>>
>> updates, bearer proposal
>> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0301.html 
>>  (Bryan)
>>
>> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0310.html 
>>  (James)
>>
>> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0314.html 
>>  (James)
>>
>> Next steps
>>
>> 8) APIs Capture
>>
>> Changes needed based on feedback?
>>
>> 9) Other API discussion
>>
>> FileAPI updates http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0288.html 
>>  (Arun)
>>
>> 10) Pending actions - closed without discussion unless concern  
>> raised.
>>
>> ACTION-193: Bryan Sullivan to Respond to Dom's comments before next  
>> week, http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0133.html 
>>  , http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0132.html
>>
>> ACTION-197: Robin Berjon to Add to agenda next week to agree to  
>> publish updated contacts WD on 29 June
>>
>> ACTION-201: Frederick Hirsch to Review WARP from perspective of use  
>> for DAP
>>
>> 11) AOB
>>
>> 12) Adjourn
>>
>> Meeting Details:
>>
>> Zakim Bridge: +1.617.761.6200, +33.4.89.06.34.99, or +44.117.370.6152
>> Conference code: 3279 ("DAPW", or "EASY")
>> IRC channel: irc://irc.w3.org:6665/dap
>>
>> Instructions on meetings : http://www.w3.org/2009/dap/#meetings
>>
>> Attendance of WG members or at discretion of chairs.
>>
>> --
>>
>>
>> regards, Frederick
>>
>> Frederick Hirsch, Nokia
>> Co-Chair, W3C DAP Working Group
>>
>> ---------------------------------------------------------------------
>> This transmission (including any attachments) may contain  
>> confidential information, privileged material (including material  
>> protected by the solicitor-client or other applicable privileges),  
>> or constitute non-public information. Any use of this information  
>> by anyone other than the intended recipient is prohibited. If you  
>> have received this transmission in error, please immediately reply  
>> to the sender and delete this information from your system. Use,  
>> dissemination, distribution, or reproduction of this transmission  
>> by unintended recipients is not authorized and may be unlawful.
>
>
>

Received on Wednesday, 30 June 2010 12:24:04 UTC