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...
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.
> 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. :)
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> ?
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.
Yeah, blocking, but yeah, this is an issue only for some non-Firefox apps.
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.
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).
(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).
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.
(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".
Patrick, do you think you'll have time to look into this before the end of the week?
Would this be "plugged in" to the content policy system? Then Adblock, etc could filter requests DNS too, or is that another bug?
(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.
Thanks for letting me know, Patrick. Boris said he can look at this, reassigning.
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?
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....
Created attachment 377828 [details] [diff] [review] 1.9.1 version (same, but with an extra interface instead of changing nsIDocShell)
Comment on attachment 377824 [details] [diff] [review] Proposed fix Looks good. r+sr=jst
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?
We promised compat after b4, and we have in fact been keeping it.
Pushed http://hg.mozilla.org/releases/mozilla-1.9.1/rev/1cd394f39075 Filed bug 493474 on camino.
8 years ago
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?
Separate bug, please, especially given bug 486127 comment 15.