Confirmed users
2,615
edits
User:Dmose:Protocol Handler Security Review: Difference between revisions
Jump to navigation
Jump to search
User:Dmose:Protocol Handler Security Review (view source)
Revision as of 15:30, 25 October 2007
, 25 October 2007no edit summary
No edit summary |
|||
| Line 26: | Line 26: | ||
* Allow web sites to register new content handlers, including prompting user whether or not add requested protocol handlers | * 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 | * Preferences API should exist for managing configured content handlers | ||
* Be able to inject possible handlers into new and existing profiles | |||
== UI Design Documentation == | == UI Design Documentation == | ||
| Line 35: | Line 36: | ||
'' links to relevant user data, bugs, reports, examples, etc '' | '' links to relevant user data, bugs, reports, examples, etc '' | ||
To actually see the registration in action, go to [http://people.mozilla.com/~ctalbert/] and select one of the web mail handlers. After you've accepted the registration, click the test link. It should bring up the compose window for the webmail app, though the header fields will not (at the moment) be populated correctly. Another example is to click on a webcal: link in a nightly; this will take you to a test handler that we have set up. | |||
= Design Impact = | = Design Impact = | ||
| Line 46: | Line 49: | ||
** application pref file (firefox.js or equivalent) missing | ** application pref file (firefox.js or equivalent) missing | ||
** user prefs.js missing | ** user prefs.js missing | ||
** ISP DNS expiration | |||
** ISP DNS expiration and pounce | |||
** non-SSL handlers | ** non-SSL handlers | ||
| Line 62: | Line 66: | ||
**** img | **** img | ||
**** others? | **** others? | ||
*** old warning dialog has been removed | *** old warning dialog has been removed: | ||
***** if it's unacceptably risky, we shouldn't be doing it at all | |||
***** if it's | ***** unclear how much a warning dialog helps anyway | ||
***** unclear how much a warning dialog helps anyway | *** handler ISP DNS expiration and pounce | ||
*** non-SSL handlers in combination with DNS MiTM attacks (eg bogus Wifi APs) | |||
** Misc | ** Misc | ||
*** spec: "should NEVER send https URIs to third-party sites"; need to design fallback behavior or change. todo: ask hixie what this protects | *** spec: "should NEVER send https URIs to third-party sites"; need to design fallback behavior or change. todo: ask hixie what this protects | ||
| Line 98: | Line 104: | ||
*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) | *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? | * Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables? | ||
Yes. In the case of accepting protocol handlers being registered for web-sites, there is a notification bar. The new protocol handling dialog | |||
offers choices as needed for URI schemes whose handling is not already defaulted. There is preferences UI to manage how particular schemes are handled at any time. There is not, and perhaps should be, any way to remove already accepted web-handlers from the preferences and dialog. | |||
* Are there build options for developers? [#ifdefs, ac_add_options, etc.] | * Are there build options for developers? [#ifdefs, ac_add_options, etc.] | ||
If MOZ_RDF is not defined, web-based protocol handlers will currently fail. There are no options specific to this feature. | |||
* What ranges for the tunable are appropriate? How are they determined? | * What ranges for the tunable are appropriate? How are they determined? | ||
There are currently no real tunables. There is a [wanted-firefox3] bug for experimenting with giving the dialog / dropdowns some MRU list love, which would probably introduce a few tunables. | |||
* What are its on-going maintenance requirements (e.g. Web links, perishable data files)? | * What are its on-going maintenance requirements (e.g. Web links, perishable data files)? | ||
None currently. | |||
== Relationships to other projects - are there related projects in the community? == | == 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? | * 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? | We are implementing the proposal from the WhatWG HTML5 spec, so we depend on them. However, as the first known implementor, we're feeding back comments to their mailing list in an ongoing way. | ||
* Are you updating, copying or changing functional areas maintained by other groups? | |||
No. | |||
== Documentation == | == Documentation == | ||
* Do built-in Help pages need modified? | * Do built-in Help pages need modified? | ||
A coin toss. There was no documentation for the old protocol handler dialog, but that one was pretty simple. We could potentially add some, but even the new dialog isn't terribly complex. | |||
* Documentation for developer.mozilla.org? | * Documentation for developer.mozilla.org? | ||
Basic documentation for navigator.registerProtocolHandler [http://developer.mozilla.org/en/docs/DOM:window.navigator.registerProtocolHandler exists]. We hope to ask the evangelism team for some cycles to put together a small tutorial on building an example server-side protocol handler. | |||
== Other == | == Other == | ||
| Line 117: | Line 133: | ||
== Caveats / What We've Tried Before == | == Caveats / What We've Tried Before == | ||
* The old protocol handling dialog was a simple nsIPrompt which only allowed things to be handed off to the system default. The new dialog is essentially a cleanup and evolution of unknown content-type handler dialog for MIME-types. In a future version, the plan is to use this new dialog to replace that old one too. | |||
* In {{bug|380415}, the backend changes were originally done as a redirect on the nsExtProtocolChannel after AsyncOpen was called. This had some structural problems, so the code got pushed into the nsHandlerInfo::LaunchWithWebHandler where it switched to simply creating a new channel and sending it to the URI loader. Further refactoring pushed this into nsIWebHandlerApp.launchWithURI where it really belongs. | |||
== References == | == References == | ||
The [https://addons.mozilla.org/firefox/4498/ MIME Edit] addon has some example UI that is more complete than the Firefox 2 UI, though not particularly friendly to non-technical users. | |||
[http://www.whatwg.org/specs/web-apps/current-work/#custom-handlers WhatWG Web Applications spec] | |||
[http://groups.google.com/group/mozilla.dev.apps.firefox/msg/99762afeb38859d0 API request from an extension author for dialog extensibility] | |||