Firefox3/OfflineApps Security Review

Overview

Firefox 3.0's offline cache implementation was missing a few features from the current HTML5 spec that we're working on for 3.1:

• Each offline manifest should have an independent application cache. These caches should be versioned - the update process creates new caches, and old caches are expired when there are no more active windows loaded from that cache.

• Fallback entries specify pages to load when a given URI can't be loaded.

• Opportunistic caching specify pages to be placed in application caches when they are loaded.

We're also implementing the new localStorage. localStorage is similar to globalStorage, but is one-storage-per-origin.

Background links

• bug 442806 - separate, versioned application caches
• bug 442813 - fallback/opportunistic entries
• bug 422526 - localStorage
• 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

• 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.

• Toplevel loads are the only loads that are associated with a cache. If site A puts site B in a subframe, site B will be loaded from site A's cache, even if site B lists a manifest. If site A does not list a manifest, site B will not be loaded from its offline cache.

• Application cache selection algorithm uses the principal URI, not the channel URI. (https://bugzilla.mozilla.org/show_bug.cgi?id=442812#c31)

• Fallback entries are currently treated like a temporary redirect. The loaded document gets the fallback uri's principal, and the fallback URI is used for bookmarks/history/location bar. As specified, the original URI should be used for bookmarks/history/location bar.

Exported APIs

• Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)
  • nsIApplicationCache - Access to a single version of an application cache.
  • nsIApplicationCacheService - Access to the set of application caches.
  • nsIApplicationCacheContainer - Implemented by objects (channels and documents, currently) that can be associated with an application cache.
  • Manifest file, format documented in the spec.

Module interactions

• What other modules are used (REQUIRES in the makefile, interfaces)
  • The implementations of nsSecurityManager::SecurityCompareURIs and nsContentUtils::OfflineAppAllowed were moved into nsNetUtil.h so that it could be used in netwerk/
  • content/base/src added a REQUIRES on nkcache to access nsICachingChannel.h during cache selection.

Data

• What storage formats are used

As before, index information for the offline cache is stored in sqlite, actual cache entries are stored in files on disk. localStorage is stored in a sqlite database alongside globalStorage information.

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?

No new configuration was added.

• Are there build options for developers? [#ifdefs, ac_add_options, etc.]

No new build options added.

• 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)?

Relationships to other projects - are there related projects in the community?

• 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?

Review Comments

• caching rules differ from regular cache? Will always load cached copy if there is one.
• are SSL pages cached, even though we normally don't?
• What about cache-control: settings?
• Once a page has an "offlineable" cache, all network loads must be specified in the manifest.
• opt-in is per domain...
  • Should AT LEAST be scheme-host-port origins.
  • should it be per-manifest?
• if we crash during caching, file will be written but not indexed. Will it get cleaned up?
• fallback mode seems under-specified
• fallback must be limited to same-origin