Networking/DNS/Prefetching

Prefetching-related bugs

• bug 40082 - Domain Guessing: should call resolver explicitly (and not trigger DNS search domains)
• bug 481503 - do DNS prefetch for awesomebar matches
• bug 580099 - Prefetch DNS for hosts needed during startup
• bug 580104 - Keep hostname cache for more aggressive DNS prefetching
• bug 580117 - Prefetch DNS for links that the mouse gets close to

Privacy Issues and Prefetching

Note: Before discussing privacy, it is important to reiterate that while only a small group of folks may notice privacy issues, it is the large majority of (non-techically savvy) users who are affected. So, the point of discussing privacy issues and policy is not to appease a vocal minority, but to determine the legitimate complaints and respond appropriately. Of primary concern here is leaking information about sites a user has visited or regularly visits via hostname resolution requests. Mitigations and solutions that have been suggested include:

• Prefetch only those sites which were accessed on the same network. For example, timestamp history entries, and only use DNS prefetch for an entry if the network has not been changed since it was created (or last used). However, this means we have to store another large int for each entry, retrieve and check it
• Use a config pref to enable/disable such prefetching from history/bookmarks.
• Allow easy opt-out, maybe even by a allow/deny notification on first locationbar use (similar to geolocation).

Points to consider about past decisions:

• Current href prefetching already leaks information about searches that a user is performing
• Href prefetching is disabled by default on securely connected sites.
• History is not stored in private browsing sessions, so awesome bar suggestions from private browsing should already be excluded from such prefetching.

Note: Private Browsing shouldn't impact DNS prefetching - Private Browsing is there to keep the browser's local state unaffected while the mode is on. It does not mean that the network is unaware of what the user is doing.

Suggestions for moving forward

• Categorize prefetching options according to privacy-risk.

• User Study for grey areas

Find out about users' comfort level with DNS prefetching; speed versus leaking tracking information.

• Telemetry Data for Measurable Improvements
  • Put together some math theory to describe variables etc. and get telemetry based on this for real world, useful values.
  • Modeling (using Tp list of sites - getting DNS depends on DNS server, but each site will have a different number of DNS RTT depending on number of links etc.) Different models depending on different solutions.
  • May be overkill to get too much data: basic knowledge of HTTP networking is enough to show that getting DNS results earlier is better. But, it would be good to have some data to measure and present improvement (or potential improvement if a user study were needed).