Firefox3.1/DNS Prefetching Security Review
The goal is improved latency response in situations using DNS by starting the high latency DNS transaction earlier than than normal. Because DNS is low bandwidth it is sometimes advantageous to start these lookups speculatively in order to overlap them with idle time.
early lookups apply to anchor href attributes, a specific dns-prefetch type of link element, and any queued http requests.
- Feature is explored in bugzilla https://bugzilla.mozilla.org/show_bug.cgi?id=453403
- Configuration is further described on my blog http://bitsup.blogspot.com/2008/11/dns-prefetching-for-firefox.html
- It is meant to interop similarly to Google's Chrome implementation, which is described http://dev.chromium.org/developers/design-documents/dns-prefetching
Security and Privacy
- Is this feature a security feature? -- No.
- What potential security issues in your feature have you already considered and addressed? -- lookups require acquiesence of both client and server. Client via pref (default on for http, default off for https contexts), server via http header or meta element (default on). Defaulting to off in an SSL context is part of the security considerations.
- Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing? -- I do not believe so
- How are transitions in/out of Private Browsing mode handled? -- no impact as there is no audit trail.
largely NA, except for
- Does it change any existing interfaces? -- the nsIDNSListener idl accepts two new flags for setting priorities on DNS lookups. Calls not using these flags run at the highest priority. (previously there was only one priority)
- What other modules are used (REQUIRES in the makefile, interfaces)? -- nsIDNSListener, nsIWebProgressListener (used for determining idle browser)
- What data is read or parsed by this feature? -- hrefs, link elements, http headers
- What is the output of this feature? -- a populated dns cache. The calls are all fire and forget
- What storage formats are used? -- the existing DNS cache is unmodified. A fixed size in memory fifo is introduced for queueing until pageload is complete, and the DNS service queue is divided into three (high, med, low).
- What failure modes or decision points are presented to the user? -- none
- Can its files be corrupted by failures? Does it clean up any locks/files after crashes? -- n/a
- Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables? -- only about config, see the blog post for referneces.
- Are there build options for developers? [#ifdefs, ac_add_options, etc.] -- no
- What ranges for the tunable are appropriate? How are they determined? -- boolean, defaults are set for security and efficiency
- What are its on-going maintenance requirements (e.g. Web links, perishable data files)? -- none. Caches are all ram based.
Relationships to other projects
Are there related projects in the community? -- not that I am aware of. Initiated on my end by bug asa filed and my interest in mobile network performance.