Firefox3/OfflineApps Security Review
Overview
Describe the goals and objectives of the feature here.
- Background links
- feature-tracking bug links
- https://wiki.mozilla.org/User:DCamp/OfflineApps_Security_Review - Security review for the 3.0 feature.
- http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html
Security and Privacy
- What security issues do you address in your project?
- Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?
- Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.
- A manifest can list an explicit entry that is not same-origin with the application. Say we have a manifest at http://application.com/app.manifest that looks like:
CACHE: http://application.com/index.html http://thirdparty.com/frame.html
If http://application.com/index.html includes http://thirdparty.com/frame.html as a child frame, it will be loaded from the application cache and subject to the same network rules as http://www.application.com/index.html (wrt whitelist and fallback entries). Its principal etc. won't change, and it won't have access to its applicationCache object.
Toplevel loads of http://thirdparty.com/frame.html (or subframe loads whose toplevel is not associated with http://application.com/app.manifest) will be handled normally.
Exported APIs
- Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)
- Does it interoperate with a web service? How will it do so?
- Explain the significant file formats, names, syntax, and semantics.
- Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?
- Does it change any existing interfaces?
Module interactions
- What other modules are used (REQUIRES in the makefile, interfaces)
Data
- What data is read or parsed by this feature
- What is the output of this feature
- What storage formats are used
Reliability
- What failure modes or decision points are presented to the user?
No additional decision points are presented to the user. One interaction has been removed - the offline cache is checked even when online, so the need to (sometimes) manually go into offline mode is gone.
- Can its files be corrupted by failures? Does it clean up any locks/files after crashes?
The index is a sqlite database. Active cache entry locks are cleaned up after crashes.
configuration
- Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?
- Are there build options for developers? [#ifdefs, ac_add_options, etc.]
- What ranges for the tunable are appropriate? How are they determined?
- What are its on-going maintenance requirements (e.g. Web links, perishable data files)?
- If so, what is the proposal's relationship to their work? Do you depend on others' work, or vice-versa?
- Are you updating, copying or changing functional areas maintained by other groups? How are you coordinating and communicating with them? Do they "approve" of what you propose?