RoundCube should ask browsers to disable DNS prefetching to protect user privacy #2639

rcubetrac opened this Issue Jan 25, 2010 · 7 comments

1 participant


Reported by trisk on 25 Jan 2010 05:50 UTC as Trac ticket #1486449

Mozilla and Chromium browsers perform DNS prefetching to reduce the latency users experience in navigating links. This makes the browsers vulnerable to information leakage through links that are embedded in messages displayed in a webmail client like RoundCube. The implications for privacy and for spam address harvesting are similar to those of embedded images in HTML, as it is possible for the sender of a message to determine when and by whom a message was read.

The browser developers have added some means for a content provider to explictly request DNS prefetching to be disabled (or enabled). The Mozilla convention (compatible with Chromium) is documented here:
The primary mechanism is a {{X-DNS-Prefetch-Control}} HTTP header.

The attached patch adds this header to all RoundCube pages. Plugins that access external resources can still opt-in domain names to prefetch:

private $rcmail;

function init()
  $this->rcmail = rcmail::get_instance();
  $this->add_hook('render_page', array($this, 'render_page'));

function render_page($p)
    html::tag('link', array('rel' => 'dns-prefetch',
                            'href' => '')));

Keywords: dns prefetch, privacy, spam


Comment by trisk on 8 Feb 2010 22:07 UTC

I noticed someone has filed a CVE ( for this issue, and several packagers have incorporated the patch.

Can this be merged?


Comment by @alecpl on 25 Feb 2010 13:50 UTC

I think we should set X-DNS-Prefetch-Control header in send_nocaching_headers() function. That should be enough.


Comment by trisk on 25 Feb 2010 21:18 UTC

The updated patch moves the X-DNS-Prefetch-Control header to send_nocacheing_headers as suggested and calls send_nocacheing_headers in more cases (regardless of whether the message in a frame, or we are viewing only a message part).


Comment by @alecpl on 26 Feb 2010 07:14 UTC

The patch looks not changed.


Comment by trisk on 26 Feb 2010 07:43 UTC

Seems to have gone through this time.


Comment by @alecpl on 26 Feb 2010 08:07 UTC

Applied in ebc619c.


Status changed by @alecpl on 26 Feb 2010 08:07 UTC

new => closed

@rcubetrac rcubetrac closed this Feb 26, 2010
@rcubetrac rcubetrac added this to the 0.4-beta milestone Mar 20, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment