Re: SysInfo buckets

Thanks John

It seems that actually defining the buckets/groupings explicitly would have meaning, also enable extensibility.

It also makes sense to separate sensors and network  given there are fundamental differences in meaning.

regards, Frederick

Frederick Hirsch
Nokia



On Jun 30, 2010, at 8:23 AM, ext John Morris wrote:

> 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 13:11:06 UTC