Firefox3/Viewport Security Review
The feature adds content-side parsing of the viewport meta tag.
- Background links
Security and Privacy
- What security issues do you address in your project?
- A META tag that was previously ignored is now parsed with string iterators. The parsed strings are stored as document headers, which are accessible only with UniversalXPConnect. The code is short and looks fine.
- Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?
- Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.
- The code assumes that the string can be iterated over until the end is reached. It does not assume that the string is valid in any way.
- 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?
- What other modules are used (REQUIRES in the makefile, interfaces)
- Currently the document header is ignored by everything but the Fennec Chrome, which uses it to size the window.
- What data is read or parsed by this feature
- Meta values are parsed into key=value pairs
- What is the output of this feature
- Data is stored in the nsDocument header data
- What storage formats are used
- 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?
- 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)?
no, though it's based on an apple spec for the iPhone
- Values are stored as pseudo-headers on the document which might conflict with real HTTP headers in the future -- not hard to imagine that if this concept catches on it might standardize as headers rather than <meta> tags. Should change names to some kind of namespace ("X-Moz-" prefix?) just in case. Bug 450474
- obeying "user-scalable=no" seems contrary to the Mozilla spirit of keeping the user in control (just an observation, this review didn't cover the chrome implementation which uses the parsed settings)
- The implementation should be sure the underlying layout already deals with extreme values (size and scaling) in a reasonable manner, or perhaps even enforce it's own caps for sanity.