This document covers distribution-related requirements for Firefox 3.0. It includes information regarding requirements and upgrade paths for existing Fx 2.0-based distros.

Overview & Background

Why does Mozilla do partner distributions?

Wide-scale and targeted distribution of Firefox is critical for the continued success of Firefox in order to achieve Mozilla’s marketshare goals. The Firefox user base must be expanded through partnerships with like-minded partners. Such companies may include software companies, content publishers, Internet Service Providers (ISPs), search engines, web sites, PC OEMs, companies that target particular groups and individual affinity groups. These are collectively referred to as “partners”.

What can distribution partners do?

Depending upon the type of partner, they may be allowed a selected/limited set of customizations to Firefox. Selected partners may distribute Firefox as-is or potentially with additional software as part of a "value-added offering".

To date, partners have done distributions of three varieties:

• Type I: Firefox as-is (no changes)
• Type II: Firefox with selected customizations (e.g. additional bookmarks, different default search engine, etc...)
• Type III: Firefox with additional software (and oftentimes partner customizations)

Why would a partner want to distribute Firefox?

This varies by partner, but some of the value that Mozilla and Firefox provides to a partner include:

• Power/strength in brand association with Mozilla/Firefox
• Opportunities for integration (e.g. changing the default home to point to the partner’s website means more traffic to the site)
• Offering an overall better user experience
• Offering an alternative to IE7 for differentiation purposes (e.g. in the case of PC OEM’s)
• Simplifying the getting-going process (e.g. AllPeers software requires users to have Firefox)

Low-Touch Partners

Low-touch partners are those partners that will be catered to through a self-service interface or process. These are potentially 100’s or 1000’s in numbers (if we are successful).

Once a vetting process (TBD) or legal agreement is accepted, the partner is then offered the ability to customize how they want their Firefox to be customized.

[An outstanding policy question of how we decide if a particular partner is suitable for distributing Firefox. E.g. is it overall positive for Mozilla to be associated with this partner. How do we know that they won’t distribute malware, etc...?]

Low-touch partners may be performing Type I, II or III distributions.

Potentially a website/customization wizard or command line tool might be used to allow a restricted set of customizations to take place. Being fully automated, this process would allow few Mozilla representatives to be involved. The output would be a set of Firefox builds that include the customizations (and extra software if needed) in for all requested platforms and locales.

In general, Mozilla should be keeping track of who these low-touch partners are and be able to communicate with them (via email). A database of low-touch partner information should be maintained whether or not we offer web-based customization or a downloadable tool.

High-Touch Partners

High-touch partners are very few in number relative to the low-touch partners. These arrangements typically require term sheets and contracts to be drafted and accepted. They may involve financial arrangements and obligations/commitment for Mozilla and the partner.

The degree of customization for high-touch partners is likely to include a large set of changes than low-touch partners can make. High-touch partners may also require “intermediate” Firefox build artifacts that can be integrated into their own installers.

To date the high-touch partners have been: Google (and its distros), Yahoo, Yahoo Japan, BigCommercePartner, Kodak, T-Online, Seznam and PCHome. We should use every opportunity to convert high-touch partners to low-touch partners if possible.

Common Requirements

• DIST-001a: Settings from distros will need to be persisted across minor (and ideally for major) updates made to Firefox via Automatic Update Service (AUS). (P1)
• DIST-001b: Branding will not be easily removable by end users except through a full uninstall of the branded Firefox (P1)
• DIST-001c: Security and stability releases/upgrades to Firefox will be smoothly delivered without requiring customized partner builds to be generated (P1)
• DIST-001d: When end users use a distro, settings from the distro will need to be persisted when a new OS user invokes Firefox for the first time and/or when a new Firefox user profile is created. (P1)
• DIST-001e: All customizations of text must include full support of Unicode (UTF-8) (P1)
• DIST-001f: Support an indicator that a particular build is a partner build rather than a vanilla Mozilla distribution from inside Firefox (about box). (P1)
• DIST-001g: Support attributes on Firefox setup installer in order to distinguish various partner builds from vanilla builds (P3)
• DIST-002a: Ability to customize vanilla Firefox with a group of settings (P1)
• DIST-002b: Support for creating distributions that support Windows (.exe) (P1)
• DIST-002c: Support for creating distributions taht support Mac (.DMG) and Linux (.tar) (P2)
• DIST-002d: Support for creating distributions of any existing Firefox locale build (P1)
• DIST-003a: Support of low-touch customization features through low-touch interface (web UI, customization tool, etc...) (P1)
• DIST-003b: Support for high-touch customization features through tools (P2)
• DIST-004a: Ability to create a “master switch” that can disable a distro (P2)
• DIST-004b: Ability to repatriate a distro to vanilla settings remotely by Mozilla or partner (e.g. in the case of default by partner) (P2)

High-Touch Requirements

• DIST-005a: Ability to script the installation of Firefox from a command line (P1)
• DIST-005b: Ability to install Firefox silently (ie, with zero UI appearing) [Windows only] (P1)
• DIST-005c: Change the text of the Windows shortcut on the desktop (P2)
• DIST-006: Support for separation of core Firefox and locale packs (P2)
• DIST-007: Support for command line tools for rebranding on Windows (predominantly) (P1)
• DIST-008: Digital signature on builds (P1?)

Customization Checklist

Additional Customizations

These are customizations that have been requested or performed in the past but will not be supported: removing popup blocking, adding domain/site to XPI white list, adding help menu item.

Requests for: compatibility checking prior to install, detecting existing installations

The CCK Wizard includes support for the following:

• Set default proxy configuration
• Change title bar text
• Change animated logo, web page and tooltip used for the animated logo

Distribution Mechanism Identified

• Distribute online via HTTP/FTP download
• Distribute via CD/DVD
• Distribute via USB, hard disk or other storage medium
• Pre-install on PC (e.g. OEM)
• Pre-install on a USB drive
• Stream/download interactively and launch (through installation program)

End of Life Policy

We need a policy that determines what happens when a partner decides that they no longer want to distribute Firefox or have ceased offering services to their Firefox users. (e.g. partner decides to shutdown and remove the default home page for Firefox users). Can we deliver them an update or re-patriate them to vanilla Firefox?

Partner Clash

We need a policy that determines what happens when an existing partner installation is layered with another partner installation.

Upgrades from Firefox 1.5

It is expected that users of Firefox 1.5 (vanilla or partner distributions) would first upgrade to a Firefox 2.0-based released prior to upgrading to a Firefox 3.0-based release.

Note: Users who opt to download Firefox 3 and force install over an existing Firefox 1.5-based installation will have unpredictable outcomes. Upgrades from Firefox 2.0

Additional sidegrade, upgrade and downgrade cases are outlined in the Upgrade Document.

Questions

• Do we need customization of the Firefox installer? (e.g. EULA, more screens, customized text, language support?)
  • Support for a stub installer (allows optional components to be download and installed)
  • Support for the stub downloader (as used by DivX)
• Trackability
  • After user has downloaded Firefox, should we track the following user actions on some central mozilla.com site?
  • Successful installation of setup installer
  • Cancellation of setup installation
  • First-time startup/activation of Firefox (once per machine)
  • First-time startup by a Firefox user (once per OS user)
  • First-time startup by a Firefox user profile (once per Firefox profile)
  • First-time search by a Firefox user (once per Firefox profile)
  • Should we register a GUID for each user? (So that we don’t have to rely on the AUS ping)
• Digital signing of builds - should we sign low-touch builds? Shall we use 2 different certificates for signing?
• Should we include a separate process for detecting existing installations and warning users prior to installation?
• Need to outline a process for dealing with malicious rebranders
• Need to policy to deal with home page resetting
  • Is a partner entitled to change the users’ home page (a new default) without prompting the user?
  • Is partner allowed to do a server-side redirect?
  • Is partner allowed to migrate to a new page after prompting
  • When a partner disappears, is Mozilla allowed to prevent users from getting 404’s? How does Mozilla determine this?