Document Overview

Timeline:

Architecture

In this section, the product's architecture is described. Any individual components or actors are identified, their "knowledge" or what data they store is identified, and data flow between components and external entities is described.

The main objective of this feature/product is: to inform general web content within tabs and windows of the user's idle and active state.

Design Documents: https://bugzilla.mozilla.org/show_bug.cgi?id=715041#c21

Components

This feature is a new API in Firefox that web sites may interact with. The API shares information about users' interactions through a set of callbacks registered by websites.

• Web browser/Firefox
• Websites
  • Websites loaded onto the browser tab within the browswer window or the window itself.

Users are a component here (they communicate with the browser) but interactions between browser and user are not changed by this feature.

Firefox

• Prevent the web page from knowing the real timing of when the user goes idle. A fuzz factor/time has been added to the 'idle' and 'active' notifications to mitigate this risk.

How it works:

• 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. 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:
  • When the user stops using the device, i.e. becomes 'idle' the web page is notified after the requested idle time registered with the Idle API plus a random fuzz time have elapsed. This random fuzz time is generated once per state transition. i.e. when the user transitions from the 'active' state to 'idle' state.

• Active Notifications:
  • 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'.

• The user 'idle' and 'active' status is platform specific.
  • On platforms that do NOT support obtaining system idle time, if the user stops using the web browser but continues to use another application currently executing on the device then the web page is specifically notified that the user is idle despite the fact that the user is using another application. E.g. Linux, Android.
  • The web page is notified immediately that the user is 'active' only when the user specifically interacts with the web page.
  • On platforms that do support obtaining system idle time such as Windows, the web page is notified of user idle status only when the user is completely away from the device.
  • The web page is notified that the user is 'active' with a fuzz time added when the user interacts with any application executing on the device. The user is not directly interacting with the web page.

Stored Data:

Communication with websites via Idle API

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

User Data Risk Minimization

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

In this section, the privacy champion will identify how the feature lines up with Mozilla's privacy operating principles.

See Also: Privacy/Roadmap_2011#Operating_Principles:

Principle: Transparency / No Surprises

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.

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.

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.

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

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: none.

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: none.

Follow-up Tasks and tracking