Confirmed users
2,615
edits
User:Dmose:Protocol Handler Security Review: Difference between revisions
User:Dmose:Protocol Handler Security Review (view source)
Revision as of 02:22, 25 October 2007
, 25 October 2007no edit summary
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
= 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 == | == Security and Privacy == | ||
| Line 32: | Line 72: | ||
*** credential leakage spec verbiage sounds unimplementable | *** credential leakage spec verbiage sounds unimplementable | ||
*** figure out what URI schemes are acceptable for both source and target | *** 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'' | |||