Privacy/Reviews/OSIdleAPI: Difference between revisions

 
(22 intermediate revisions by 3 users not shown)
Line 12: Line 12:
|'''Security Contact:''' || Curtis Koenig
|'''Security Contact:''' || Curtis Koenig
|-
|-
|'''Document State:''' || <section begin='status'/>{{risk|risk analysis}}<section end='status'/>
|'''Document State:''' || <section begin='status'/>{{risk| CfC Closed}}<section end='status'/>
|}
|}


Line 51: Line 51:
How it works:  
How it works:  


* Idle observer requested idle times are in seconds.
* Idle observer requested idle times are in seconds. Minimum requested idle time must be 1 second.  
* Randomly generated fuzz times for 'idle' and 'active' events are in milli-seconds.
* Randomly generated fuzz times for 'idle' and 'active' events are in milli-seconds. The range for the randomly generated fuzz time is from 1 milli-second to 90000 milli-seconds. The randomly generated fuzz time will never be 0 milli-seconds.


* Idle Notifications:
* Idle Notifications:
Line 58: Line 58:


* Active Notifications:
* Active Notifications:
**When the user starts using the device again, i.e. becomes 'active', the web page is notified immediately if the the user directly interacted (mouse over event, keyboard event, touch based event) with the web page.  
**When the user starts using the device again, i.e. becomes 'active', the web page is notified immediately if the user directly interacted (mouse over event, keyboard event, touch based event) with the web page.  
** If the user interacts with another application other than the web page, the user has become 'active' but indirectly. When the user becomes indirectly active, 'active' notifications are sent to the registered idle observers after a fuzz time has elapsed. This fuzz time is randomly generated and is generated once per state transition. I.e. when the user transitions from an 'idle' state to an 'active' state a random fuzz time is generated and applied after which time the idle observers are notified that the user is 'active'.
** If the user interacts with another application other than the web page, the user has become 'active' but indirectly. When the user becomes indirectly active, 'active' notifications are sent to the registered idle observers after a fuzz time has elapsed. This fuzz time is randomly generated and is generated once per state transition. I.e. when the user transitions from an 'idle' state to an 'active' state a random fuzz time is generated and applied after which time the idle observers are notified that the user is 'active'.


Line 69: Line 69:


'''Stored Data:'''  
'''Stored Data:'''  
There is no stored data.


{| class="wikitable"
{| class="wikitable"
Line 77: Line 75:
! Where
! Where
|-
|-
| None
| Idle observer requested idle time in seconds
| None
| In memory, not on disk.
|-
| Idle callback function
| In memory, not on disk.
|-
| Active callback function
| In memory, not on disk.
|}
|}


Line 91: Line 95:
|-
|-
| ''In:''  
| ''In:''  
| addIdleObserver()
| addIdleObserver
| Requested idle time in seconds. Idle callback function. Active callback function.
| argument = {time: seconds, onidle: function, onactive: function}
| The requested idle time in seconds is the amount of idle time that needs to elapse before the idle observer receives 'idle'/ 'active' notifications. The notifications are the idle and active callback functions. The mininum requested idle time in seconds must be 1 second.
|  
|-
|-
| ''In:''  
| ''In:''  
| removeIdleObserver()
| removeIdleObserver
| Requested idle time in seconds. Idle callback function. Active callback function.
| argument = {time: seconds, onidle: function, onactive: function}
| The requested idle time in seconds is the amount of idle time that needs to elapse before the idle observer receives 'idle'/ 'active' notifications. The notifications are the idle and active callback functions. The mininum requested idle time in seconds must be 1 second.
| Yes, the idle time is also passed to this function. See the note below.
|-
|-
| ''Out:''  
| ''Out:''  
| Idle callback function. Active callback function.
| Call into Idle/Active callbacks.
| None
| None
| The idle and active callback functions are determined by the front end developer.
| No arguments are passed to the callback functions.
|}
|}


''TODO: what is the actual API (messages and parameters)?  We want to see the function signature and the types of data (or sample data) passed in.  Example: see [[Privacy/Reviews/BrowserID.org#Implementation_Server]]''
Note: The idleObserverObject is passed as a paramater to function addIdleObserver(). 'someIntValInSeconds' is the requested idle time in seconds that needs to elapse before the idle observer receives 'idle' notifications. 'someIntValInSeconds' must be a minimum of 1 seconds and a maximum of a PRUint32. 'someIdleCallbackFunction' is the front-end developer defined callback function that is to be called when the user is idle for 'someIntValInSeconds'. 'someActiveCallbackFunction' is the front-end developer defined callback function that is to be called when the user transitions from an idle state to an active state. Please see sample test file: http://mxr.mozilla.org/mozilla-central/source/dom/base/test/test_bug715041.xul
 


<br>
<br>
Line 114: Line 117:


In this section, the privacy champion will identify areas of user data risk and recommendations for minimizing the risk.
In this section, the privacy champion will identify areas of user data risk and recommendations for minimizing the risk.
The risks seem fairly contained; mainly they revolve around users' surprise about sites knowing this information.  Users should have direct control over the feature's availability, and perhaps receive an indication that idle-ness is being measured, but other than that the benefit from new functionality outweighs any risk of deploying this feature on by default.


= Alignment with Privacy Operating Principles =
= Alignment with Privacy Operating Principles =
Line 122: Line 127:


====Principle: Transparency / No Surprises====
====Principle: Transparency / No Surprises====
(How the feature addresses this)
Callbacks are triggered when the user stops interacting with the computer/Firefox, and then again when they start interacting again (plus or minus a fuzz factor).  It might not be intuitive to users that a web site can discern whether the user has stopped interacting or comes back from a break.


''Recommendations'': (what can be improved)
''The Risk'' is that users will be surprised that an app noticed them walk away from their computer or when they sit back down to use it again.  Sites currently cannot do this.


''Recommendations'': provide some sort of indication to the user about their idle state or that their active/idle state is being used by a web site.
{{ResolutionBox|{{new|}}}}


====Principle: Real Choice====
====Principle: Real Choice====
Users who are surprised that web sites can identify their idle/active state may want to disable the feature. 
''The Risk'': is that users feel compelled to stop using a site because it knows whether they are idle or not.


''Recommendations'':  
''Requirement'': Provide a way for users to disable this feature so sites callbacks are not called.


{{ResolutionBox|{{new|}}}}


====Principle: Sensible Defaults====
====Principle: Sensible Defaults====
The data obtained by sites is not very individual, though it does hint at user behavior that sites currently don't measure.  This feature is active by default because it's not very invasive (and includes a fuzz factor).


''Recommendations'':
''Recommendations'': none.




====Principle: Limited Data====
====Principle: Limited Data====
The data passed to callbacks is minimal (there's not really any).  The data passed to the site about users' behavior is minimal for the feature requested (idle state).


''Recommendations'':
''Recommendations'': none.


= Follow-up Tasks and tracking =
= Follow-up Tasks and tracking =
Line 149: Line 163:
! Details
! Details
|-
|-
| {{new|Initial Overview Discussion}}
| {{done|Initial Overview Documentation}}
| Bonnie Surender, Jonas Sicking
| Bonnie Surender, Jonas Sicking
|  
|  
| Meeting time TBD
| April-2012 to July-2012
|-
| {{done|Initial Risk Analysis}}
| Sid Stamm
|
| 11-July-2012
|-
| {{done|[https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.planning/u0KF9fGd48A public review]}}
| dev.planning
|
| 19-July-2012
|}
|}




[[Category:Privacy/Reviews|OSIdleAPI]]
[[Category:Privacy/Reviews|OSIdleAPI]]
canmove, Confirmed users, Bureaucrats and Sysops emeriti
2,776

edits