Unwanted DNS queries when opening mail, potential privacy issue

RESOLVED FIXED

Status

--
major
RESOLVED FIXED
9 years ago
7 years ago

People

(Reporter: lj308, Assigned: standard8)

Tracking

({privacy})

SeaMonkey 2.0 Branch
privacy
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fixed by bug 544745])

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.6) Gecko/20091218 SeaMonkey/2.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.6) Gecko/20091218 SeaMonkey/2.0.1

When you open a mail message, Seamonkey2 seems to do  a DNS query for the 
hostname in every URL in the message. This happens even for text format 
messages.  These are unwanted and unnecessary.

This also creates a potential privacy problem.  Seamonkey normally blocks
loading remote content from messages, to defeat "web bugs" and the like.
With this new Seamonkey2 DNS lookup feature, spammers and other privacy
violators may soon realize they can use this feature to detect when their
messages are opened. All they have to do is include a unique hostname in a
URL in their message. Like this:
   http://user12345678.mytracker.mysite.example.com
With a DNS server that records all lookups to the subdomain 
mytracker.mysite.example.com, they now can tell when you opened their message.


Reproducible: Always

Steps to Reproduce:
1. Start up a network analyzer program like wireshark.
2. Open any email, even text/plain, that contains a URL. For example:
  "You must have Adobe Reader installed on your PC to view the press releases.
  Adobe Reader can be downloaded free of charge at http://www.adobe.com"
3. Examine the network analyzer display.
Actual Results:  
A DNS lookup for www.adobe.com was sent from Seamonkey.

Expected Results:  
No network traffic, unless I click on a link in the message.

I have network.prefetch-next=false, in case it matters.

Seamonkey1.1 and Thunderbird2.0.0.23 do not have this issue.
Does Thunderbird 3 have this issue? It's probably DNS prefetching. What if you change the network.dns.disablePrefetch pref to true? Do you still see the DNS queries then?

Comment 2

9 years ago
That would be a clear regression of bug 492196, where we explicitly fixed this issue for MailNews...

Comment 3

9 years ago
Also see bug 486127.

I can NOT confirm this with a self-built debug SeaMonkey "Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7pre) Gecko/20091219 SeaMonkey/2.0.2pre" off the 1.9.1 branch, I'll check with a public build later.
(Reporter)

Comment 4

9 years ago
Sorry I do not have Thunderbird 3 available to try it.

There is no existing preference network.dns.disablePrefetch so I added it with boolean type, value False, and yes it does stop the DNS lookups when messages are opened.

Those two bug reports are this same problem (but they are reported as fixed?)
(I did search but failed to find either of those bugs. Sorry. "dns seamonkey mail query" does not find them. Had I tried "dns seamonkey mail queries" it would have popped right up.)

Comment 5

9 years ago
OK, I can confirm that in "show as plain text" mode, my SeaMonkey 2.0.x requests DNS data for any URL it encounters when I read email.

I don't see how it would invade privacy without someone malicious logging my network traffic, owning my DNS server or MITMing my DNS requests, but  the described behavior is there.

Comment 6

9 years ago
Actually, I see how bug 492196 allowed different docshells to allow or disallow DNS prefetch, I haven't found where anything besides the microsummary service sets it deliberately - I haven't yet looked through all results of http://mxr.mozilla.org/comm-central/search?string=AllowDNSPrefetch but nothing obvious strikes out.

Comment 7

9 years ago
Oops, one look later, I found http://mxr.mozilla.org/comm-central/source/mozilla/docshell/base/nsDocShell.cpp#1950 - now the question is why that seems to not work.
Severity: normal → major
Depends on: 486127
Keywords: privacy
Version: unspecified → SeaMonkey 2.0 Branch

Comment 8

9 years ago
Workaround is to switch of all DNS prefetching with the preference network.dns.disablePrefetch = true
Status: UNCONFIRMED → NEW
Ever confirmed: true
Duplicate of this bug: 545393
Assignee: nobody → bugzilla
OS: Linux → All
Hardware: x86 → All
Blocks: 545407
Depends on: 544745
This has been fixed by the patch on bug 544745.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by bug 544745]
You need to log in before you can comment on or make changes to this bug.