From MozillaWiki
< Security‎ | Reviews‎ | Gaia
Jump to: navigation, search

App Review Details

  • App: clock
  • Review Date: 2013-09-23 (commit)
  • Review Lead: Frederik Braun (:freddyb)
  • Review Bug: bug 754737



Menu to view current time, date and currently set alarms. Interaction via add-alarm button or change-alarm on an existing alarm.

Events set to trigger an alarm.

Relevant Source Code

Source code available on GitHub

Reviewed all JavaScript code in js/


These permissions are set in the manifest:

  • "storage": indexeddb/appcache without size limitations
  • "alarms": self-explanatory
  • "settings": required to add/remove alarms
  • "attention": required to allow alarm window to be placed on top
  • "audio-channel-alarm": self-explanatory

The app has full read/write permissions to the Settings in order to add and remove alarms. It also stores whether the clock is shown as a digital or an analog clock.

It might be desirable to have more granular settings capabilities in general, bug 841071

Web Activity Handlers

in ./active_alarm.js:20, to handle all alarm messages,

Web Activity Usage


Notable Event Handlers


Code Review Notes

1. XSS & HTML Injection attacks

The name of an alarm is escaped using a temporary span element and then setting and extracting it's textContent. No other text input is being handled.

2. Secure Communications

Communication with internal alarm handler code happens, but it's verification process as follows (dchan pointed this out correctly):

  1. Child process / app calls AlarmsManager.js add(). [1] This sends a message to the jsm file. The message includes the manifestURL of the current app
  2. AlarmsService.jsm handles the message, checking that the sender has the alarms permission and that the sender is actually the correct app for the specified manifestURL [2]
  3. The alarm is pushed onto a queue. AlarmHALService is reponsible for triggering the alarms at the correct time [3]
  4. A system message is fired using the data from the alarmDB. This sends a message to the manifestURL that was originally stored [4]
  5. More checks that the app registerd to listen for the alarm message [5] [6]

3. Secure data storage

No storage of sensible data.

4. Denial of Service


5. Use of Privileged APIs


6. Interfaces with other Apps/Content


Security Risks & Mitigating Controls

Actions & Recommendations