Last Comment Bug 492196 - Make DNS-Prefetching subject to user-defined policies
: Make DNS-Prefetching subject to user-defined policies
Status: RESOLVED FIXED
[tb3needs]
: fixed1.9.1, privacy, regression
Product: Core
Classification: Components
Component: Networking (show other bugs)
: Trunk
: x86 All
: -- major (vote)
: ---
Assigned To: Boris Zbarsky [:bz]
:
Mentors:
Depends on: 493467
Blocks: 453403 486127 545407
  Show dependency treegraph
 
Reported: 2009-05-09 08:35 PDT by Karsten Düsterloh
Modified: 2012-03-29 02:15 PDT (History)
24 users (show)
jst: blocking1.9.1+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Proposed fix (19.04 KB, patch)
2009-05-15 20:21 PDT, Boris Zbarsky [:bz]
jst: review+
jst: superreview+
Details | Diff | Splinter Review
1.9.1 version (same, but with an extra interface instead of changing nsIDocShell) (21.20 KB, patch)
2009-05-15 21:23 PDT, Boris Zbarsky [:bz]
jst: review+
jst: superreview+
Details | Diff | Splinter Review

Description Karsten Düsterloh 2009-05-09 08:35:59 PDT
Bug 453403 implemented DNS prefetching in Necko, which has severe security implications:
Local HTML pages will generate DNS queries even if other remote content is disabled, e.g. for mere <a href="...">!

This gets even more creepy if we take into account that SeaMonkey and Thunderbird render _all_ messages (even plaintext ones) as HTML documents in a <browser> element. Thus reading a plaintext(!) message will already make you acknowledge the existence of this account (e.g. by using one-time subdomain entries), because even in plaintext mode links are rendered as clickable items. 

Until now, there was a commonly agreed assumption that reading local HTML without remote *content* will keep your privacy intact. This promise is broken now.

While you can turn off the prefetching entirely by using network.dns.disablePrefetch, this is no real option for SeaMonkey (although maybe for TB), because you can't seriously apply one single setting to public websurfing, viewing local HTML documents in the browser and reading mail all alike without affecting user experience.
We could even work around the mail case by trying to produce certain markup, but that is rather band-aiding than fixing the real issue. And, of course, this will not help a bit when viewing local HTML documents in the browser...
Comment 1 Boris Zbarsky [:bz] 2009-05-09 12:50:28 PDT
We don't actually need user-defined policies, here?  What we need is a way to disable DNS prefetch on a per-document basis.  Whether this is done via a setting on the docshell or via content policy or some other mechanism is something to decide on during implementation.  Now that the prefetch is done after document load completes, maybe a content policy check would sorta work, except the content policy API is completely inappropriate here (e.g. we have no URI we plan to load).

This is a serious problem for any Gecko-based app that's not a pure web browser, and I should have caught it in review...  I think this needs to block 1.9.1.
Comment 2 Karsten Düsterloh 2009-05-10 09:45:49 PDT
> We don't actually need user-defined policies, here?  What we need is a way to
> disable DNS prefetch on a per-document basis.

My Necko foo ist not particularly strong, so please correct my wording where necessary. :)
Comment 3 neil@parkwaycc.co.uk 2009-05-10 14:11:00 PDT
Is per-document strong enough? For example, suppose I send an email containing <iframe src=data:text/html,%3Ba%20href=http://unique.evil.com%3D> ?
Comment 4 Boris Zbarsky [:bz] 2009-05-10 19:45:13 PDT
Presumably the disabling would need to inherit to child documents, like other docshell settings.

As for comment 2, the point is that we don't need either something users can easily set or something that can be set on a per-site basis, as far as I can tell.  Something set on the docshell tree root level should be fine.
Comment 5 Johnny Stenback (:jst, jst@mozilla.com) 2009-05-11 17:40:07 PDT
Yeah, blocking, but yeah, this is an issue only for some non-Firefox apps.
Comment 6 Jason Duell [:jduell] (needinfo me) 2009-05-12 11:43:41 PDT
Boris, who's the right person to work on this?  Patrick McManus has touched the DNS code recently, but from your comments it sounds like the code might be more in docshell.   I'm guessing the right way to proceed to is to have Patrick or someone else add a necko "don't prefetch DNS for this" API, and then someone else might be the right person to do the docshell work.
Comment 7 Boris Zbarsky [:bz] 2009-05-12 12:04:55 PDT
Patrick is almost certainly the right person to work on this...  There's no reason not to learn a bit about the docshell code if you're doing necko work (and in fact, it's a good idea).
Comment 8 Karsten Düsterloh 2009-05-12 14:50:28 PDT
(In reply to comment #5)
> Yeah, blocking, but yeah, this is an issue only for some non-Firefox apps.

Wrong. 
Watching a local HTML file with any <a href="link"> in it will result in a DNS query. Of course you can turn off DNS prefetching entirely, but you can't distinguish between wanted prefetching (web) and unwanted ones (local).
Comment 9 Boris Zbarsky [:bz] 2009-05-12 14:55:23 PDT
Hold on.  Which problems are we trying to solve?  The local file case needs a totally different solution, in general, than the mail case.  Or rather, the local file solution (pluggable per-origin behavior of some sort) would also solve the mail case, maybe, but the best solution for the mail case will NOT solve your local file issue, almost certainly.

Given that you can't have "other remote content" disabled without an extension for local file pages, I don't think we necessarily need to worry about that case.  That same extension can disable DNS prefetch (yes, you get a performance penalty, but you already have a major performance penalty from the extension's existence; globally disabling DNS prefetch may well be a smaller penalty than running a bunch of JS for every single link on the page).

So I think we should focus on the mail-and-such case here, myself.
Comment 10 Karsten Düsterloh 2009-05-12 15:18:37 PDT
(In reply to comment #9)
> So I think we should focus on the mail-and-such case here, myself.

Yes, sure. I just want to avoid the notion that DNS prefetching issues are "just" a problem of "some non-Firefox apps".
Comment 11 Johnny Stenback (:jst, jst@mozilla.com) 2009-05-12 19:27:47 PDT
Patrick, do you think you'll have time to look into this before the end of the week?
Comment 12 James May [:fowl] 2009-05-13 00:09:01 PDT
Would this be "plugged in" to the content policy system? 

Then Adblock, etc could filter requests DNS too, or is that another bug?
Comment 13 Patrick McManus [:mcmanus] 2009-05-13 06:16:47 PDT
(In reply to comment #11)
> Patrick, do you think you'll have time to look into this before the end of the
> week?

Sorry, fraid not. Someone else should probably look at it.
Comment 14 Johnny Stenback (:jst, jst@mozilla.com) 2009-05-13 18:48:13 PDT
Thanks for letting me know, Patrick. Boris said he can look at this, reassigning.
Comment 15 Damon Sicore (:damons) 2009-05-15 11:48:33 PDT
Boris, you think you are going to be able to make the freeze date of Wed, May 20th here?  Just want to make sure we're being realistic, and if you haven't started on this one yet, it makes me worry.  Thoughts?
Comment 16 Boris Zbarsky [:bz] 2009-05-15 20:21:16 PDT
Created attachment 377824 [details] [diff] [review]
Proposed fix

A few things going on here.

1)  Add a boolean member on documents that indicates whether prefetch is allowed
    for that document.  This defaults to true.
2)  Set this member to false if the document gets a window and the docshell is
    not allowing prefetch, if the document has an HTTP header or equivalent
    META tag disallowing prefetch, or if the "no DNS prefetch from secure" pref
    is set and the document gets a principal that has no URI or has an https
    URI.  This makes document.write from https do the right thing no matter
    what we do with the document URI, for example.  The code corresponding to
    all this in nsHTMLDNSPrefetch goes away.
3)  Docshell defaults to allowing prefetch and exposes an nsIDocShell API to
    change this.  It also defaults to disallowing prefetch if someone sets the
    app type to mail or editor.  This should immediately fix the issues
    thunderbird and seamonkey have, I would think.
4)  nsWebBrowser defaults to NOT allowing prefetch, since those APIs are
    frozen, but adds a way to enable it via nsIWebBrowserSetup.  If this flies,
    I'll file a bug on Cammino to enable it on their end.

I revved the docshell iid, but the other interface changes shouldn't need IID revs, I would think.  The nsIDocument one is debatable; if desired I can put this member all the way at the end of the nsIDocument members, in which case it will certainly be ok.

I can't think of a sane way to test this automatically, but I did verify via printfs that I get DNS prefetch in Firefox with this patch, but that if I flip the default value in docshell that stops happening....
Comment 17 Boris Zbarsky [:bz] 2009-05-15 21:23:57 PDT
Created attachment 377828 [details] [diff] [review]
1.9.1 version (same, but with an extra interface instead of changing nsIDocShell)
Comment 18 Johnny Stenback (:jst, jst@mozilla.com) 2009-05-16 13:48:38 PDT
Comment on attachment 377824 [details] [diff] [review]
Proposed fix

Looks good. r+sr=jst
Comment 19 Johnny Stenback (:jst, jst@mozilla.com) 2009-05-16 13:50:44 PDT
Comment on attachment 377828 [details] [diff] [review]
1.9.1 version (same, but with an extra interface instead of changing nsIDocShell)

r+sr=jst for this one too, but do we really care about not changing interfaces for 1.9.1 already? Was that decided, if so, I missed it. And have we really kept any such claims?
Comment 20 Boris Zbarsky [:bz] 2009-05-16 15:13:59 PDT
We promised compat after b4, and we have in fact been keeping it.
Comment 21 Boris Zbarsky [:bz] 2009-05-17 10:15:37 PDT
Pushed http://hg.mozilla.org/mozilla-central/rev/cab8d8a075da
Comment 22 Boris Zbarsky [:bz] 2009-05-17 12:46:50 PDT
Pushed http://hg.mozilla.org/releases/mozilla-1.9.1/rev/1cd394f39075

Filed bug 493474 on camino.
Comment 23 Owen Marshall (Not reading bugmail) 2010-02-08 10:31:33 PST
Bug 544745 indicates that DNS prefetching is still occurring for messages on Thunderbird 3.0.1 as well as TB3.1 beta.

I'm not up on my BMO QA: should we dupe that one over to here and reopen this bug, or just leave that as a separate bug?
Comment 24 Boris Zbarsky [:bz] 2010-02-08 10:48:19 PST
Separate bug, please, especially given bug 486127 comment 15.

Note You need to log in before you can comment on or make changes to this bug.