User:Dmose:Protocol Handler Security Review

Status

Feature tracking bug

• bug 380415

Has a design review been completed?

The design has been reviewed incrementally in bug 380415, its dependent bugs, and ongoing discussions in and newsgroups. A single, comprehensive, high-level review has not happened, and is not currently planned (other than this security review).

When do you anticipate the feature landing

We were feature-complete in mid-September. Bug-fixing is ongoing.

Any relevant status comments for the feature can be placed here.

Overview

It is now possible to have URIs with protocol schemes that are not handled internally (e.g. webcal:, mailto:, news:, etc.) handed off to web-based handlers in addition to desktop applications.

Use Cases

• Users who primarily use web mail should be able to click mailto: links and have them do the right thing (open their webmail applications in compose mode) rather than opening a compose window in a mail app that they don't use (e.g. Outlook Express).
• Users who primarily use web calendars should be able to click webcal: links and have them subscribe to the ICS calendars in question.
• (etc.)

Requirements

• Support web-based protocol handlers in the backend bug 380415
• Handlers should be selectable/configure from a dialog similar to the unknown content type handler for MIME types.
• Allow web sites to register new content handlers, including prompting user whether or not add requested protocol handlers
• Preferences API should exist for managing configured content handlers

UI Design Documentation

use cases and expected user knowledge (terminology, metaphors, etc)

design mockups (of whatever fidelity is easiest)

ContentHandling:User_Interface

links to relevant user data, bugs, reports, examples, etc

Design Impact

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?
  • mime-types.rdf corruption / missing
  • application prefs.js missing
  • user prefs.js missing
  • ISP DNS expiration
  • non-SSL handlers

• Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.
  • Assumptions
  • Capabilities
  • Potential Risks
    • Phishy? (Encourages in-browser auth?)
    • The HTML5 spec has a http://www.whatwg.org/specs/web-apps/current-work/#security3 list of possible security issues] that should be gone through
    • Uses of web-handled URIs in contexts other than in href attribute of a element
      • object
      • embed
      • iframe (no status bar; even phishier than usual?)
      • script
      • img
      • others?
    • old warning dialog has been removed
      • Logic:
        • if it's that risky we shouldn't be doing it
        • unclear how much a warning dialog helps anyway"
  • Misc
    • spec: "should NEVER send https URIs to third-party sites"; need to design fallback behavior or change. todo: ask hixie what this protects
    • how do we handle URI leakage as per HTML5 4.10.2.1. todo: does fx2 handle this? sounds hard (impossible?) to fix
    • credential leakage spec verbiage sounds unimplementable
    • figure out what URI schemes are acceptable for both source and target

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?

Web Compatibility

• Does the feature had any impact on Web compatibility?

Performance

• How will the project contribute (positively or negatively) to "perceived performance"?
• What are the performance goals of the project? How were they evaluated? What is the test or reference platform and baseline results?
• Will it require large files/databases (for example, browsing history)?

Reliability

• What failure modes or decision points are presented to the user?
• Can its files be corrupted by failures? Does it clean up any locks/files after crashes?

l10n and a11y

• are any strings being changed or added?
• are all UI elements available through accessibility technologies?

Installation, Upgrade/Downgrade/Sidegrade, and platform requirements

• Does it equally support all Tier-1 platforms?
• Does is have a hardware requirement (or increase minimum requirements)?
• Does it require changes to the installer?
• Does it impact updates?
• list the expected behavior of this feature/function when Firefox is upgraded to a newer minor release, downgraded by installation of an earlier revision, or re-installed (same version)

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

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?

Documentation

• Do built-in Help pages need modified?
• Documentation for developer.mozilla.org?

Other

any other implementation or design related documentation

Discussion & Implications

Caveats / What We've Tried Before

links to previous design documents, discussions, etc.

References

links to external documents that could inform the design of the feature