Firefox3/OfflineApps Security Review
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.
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.
- 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.
- 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.
- 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.
- 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.
- 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)?
- 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?
- 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