WebAPI/IdleAPI: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
 
(3 intermediate revisions by one other user not shown)
Line 2: Line 2:


  partial interface Navigator {
  partial interface Navigator {
   readonly attribute boolean mozUserIdle;
   void addIdleObserver(IdleObserver);
  void removeIdleObserver(IdleObserver);
  };
  };
   
   
  partial interface Window {
  [NoInterfaceObject]
   attribute Function onmozuseridle;
interface IdleObserver {
   attribute Function onmozuseractive;
   attribute long time; // seconds
   void onidle();
  void onactive();
  };
  };


When the user has remained inactive for a period of time we schedule a task to set mozUserIdle to true and fire a "mozuseridle" event on the window (this matches the online/offline events).
Using this APi would look something like:


When the user becomes active again, we set mozUserIdle to false and fires a "mozuseractive" event on the window. Note that this happens *before* the mouse/keyboard/touch event which caused the user to become active.
navigator.addIdleObserver({ time: 4, onidle: myIdleHandler, onactive: myActiveHandler});
 
This will call the myIdleHandler function once the user has been inactive for 4 seconds. Once the user goes active again we'd call the myActiveHandler function. You can of course use any means of producing the object passed to the function, such as:
 
navigator.addIdleObserver(new WidgetUpdateThingy(...));
navigator.addIdleObserver(getIdleObserver());


== Security/Privacy considerations ==
== Security/Privacy considerations ==
Line 20: Line 28:
In order to fix this we switch to "user is idle" mode in each window with a small amount of "fuzz". I.e. we delay the switch by a few seconds or minutes. This delay is different in different tabs. This affects both the timing of when the mozUserIdle boolean changes value and when the "mozuseridle" event fires.
In order to fix this we switch to "user is idle" mode in each window with a small amount of "fuzz". I.e. we delay the switch by a few seconds or minutes. This delay is different in different tabs. This affects both the timing of when the mozUserIdle boolean changes value and when the "mozuseridle" event fires.


Same thing when switching back to active mode. This should happen with a small randomized delay. However, if the user interacts with a tab, the page in the tab can clearly detect that the user is no longer idle. In this scenario we switch the user to active mode immediately before firing the mouse/keyboard/touch event. This *only* affects the tab the user interacted with. But if the user switches between multiple tabs, we can be forced to do this early switch in several tabs.
Same thing when switching back to active mode. This happens with a small randomized delay. However, if the user interacts with a tab, the page in the tab can clearly detect that the user is no longer idle. In this scenario we switch the user to active mode immediately before firing the mouse/keyboard/touch event. This *only* affects the tab the user interacted with. But if the user switches between multiple tabs, we can be forced to do this early switch in several tabs.


When switching between idle/active modes, we should ideally do that for a whole tab at a time. I.e. it should affect all windows in a given tab at the same time.
When switching between idle/active modes, we should ideally do that for a whole tab at a time. I.e. it should affect all windows in a given tab at the same time.


We might also want to display UI which allows the user to choose if he/she wants to expose idle/active status to page. This is something we still need to figure out.
We might also want to display UI which allows the user to choose if he/she wants to expose idle/active status to page. This is something we still need to figure out.
[[Category:Web APIs]]

Latest revision as of 23:53, 1 October 2014

API

partial interface Navigator {
  void addIdleObserver(IdleObserver);
  void removeIdleObserver(IdleObserver);
};

[NoInterfaceObject]
interface IdleObserver {
  attribute long time; // seconds
  void onidle();
  void onactive();
};

Using this APi would look something like:

navigator.addIdleObserver({ time: 4, onidle: myIdleHandler, onactive: myActiveHandler});

This will call the myIdleHandler function once the user has been inactive for 4 seconds. Once the user goes active again we'd call the myActiveHandler function. You can of course use any means of producing the object passed to the function, such as:

navigator.addIdleObserver(new WidgetUpdateThingy(...));
navigator.addIdleObserver(getIdleObserver());

Security/Privacy considerations

For normal webpages the timing of when the user goes idle can be used to correlate identities used in separate windows. I.e. if the user has two windows open to two separate websites and one window is in privacy mode, the websites can figure out the user's identity even in the privacy-mode window by noticing that the user goes idle in both windows at the exact same time.

In order to fix this we switch to "user is idle" mode in each window with a small amount of "fuzz". I.e. we delay the switch by a few seconds or minutes. This delay is different in different tabs. This affects both the timing of when the mozUserIdle boolean changes value and when the "mozuseridle" event fires.

Same thing when switching back to active mode. This happens with a small randomized delay. However, if the user interacts with a tab, the page in the tab can clearly detect that the user is no longer idle. In this scenario we switch the user to active mode immediately before firing the mouse/keyboard/touch event. This *only* affects the tab the user interacted with. But if the user switches between multiple tabs, we can be forced to do this early switch in several tabs.

When switching between idle/active modes, we should ideally do that for a whole tab at a time. I.e. it should affect all windows in a given tab at the same time.

We might also want to display UI which allows the user to choose if he/she wants to expose idle/active status to page. This is something we still need to figure out.