Firefox3/OfflineApps Security Review

From MozillaWiki
Jump to: navigation, search

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

Security and Privacy

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

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
Retrieved from "https://wiki.mozilla.org/index.php?title=Firefox3/OfflineApps_Security_Review&oldid=108048"