Firefox3.1/TSF Security Review

From MozillaWiki
Jump to: navigation, search


Integrate support for Windows' Text Services Framework into Gecko. TSF is a framework for text input. It supports "input methods" for complex text, and also speech input and handwriting input.

Background links

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?

No. The only preference is which disables the whole feature for testing purposes only.

  • Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.

TSF is a trusted system framework. Web content (including chrome content) does not get direct access to TSF APIs; TSF support is automatic based on existing text editing facilities in Gecko. Other applications in the system could use TSF to access Gecko internals, such as the contents of text fields, but there are already other ways to do that (e.g. accessibility APIs). TSF can affect interactions with password form fields, but at first glance, not in any troublesome way.

Exported APIs

  • Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)

No new APIs or UI (other than UI provided by TSF and its components, such as IMEs).

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

There are none. TSF components can communicate with Gecko like any other TSF-aware application.

  • Does it change any existing interfaces?


Module interactions

  • What other modules are used (REQUIRES in the makefile, interfaces)

Windows widget, and content.


  • What data is read or parsed by this feature


  • What is the output of this feature

None except for output produced by TSF

  • What storage formats are used



  • What failure modes or decision points are presented to the user?

None other than those presented by TSF (e.g. Language Bar)

  • Can its files be corrupted by failures? Does it clean up any locksfiles after crashes?

No, No


  • Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?

Yes. The hidden preference can be used to disable the feature entirely. We envisage this would only be used for testing.

  • Are there build options for developers? [#ifdefs, ac_add_options, etc.]

Yes, MOZ_ENABLE_TSF can be used to disable the entire feature at build time.

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

Everything this depends on is on trunk already.

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

Masayuki Nakano and Robert O'Callahan are usually responsible for this area, and we're reviewing Jim's patch.

Review comments