We have a new API that allows speculative connections, to speed up cases where we have a reasonable expectation that we will be loading a site in the future (but the load hasn't been triggered yet). Some users may want to disable that behavior due to privacy concerns or other reasons, so we should have a global pref that controls whether or not speculative connection occurs in these cases. See bug 790882 comment 22 for related discussion.

I don't really know how to test this, short of starting some other test http server within browser-chrome.

Comment on attachment 684197 [details] [diff] [review] patch I'm not sure that we should honor the pref in the case of the search bar. I'd like to raise the bar for when we'd honor the pref such that the driving factor is privacy, and make that clear in the comment, the property name and the pref name.

Focusing the search bar does not guarantee that you will perform a search, right? So the possibility of connection is not 100%. Trying to put the bar somewhere other than 100% seems potentially tricky... (The reporter of bug 803970 didn't expect it to happen for search, which is what motivated this.)

(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #3) > Focusing the search bar does not guarantee that you will perform a search, > right? So the possibility of connection is not 100%. Trying to put the bar > somewhere other than 100% seems potentially tricky... Right, I have no particular percentage in mind. I think the bar should be "has some privacy impact". Bug 803970 comment 11 mentions privacy implications, but it's not clear to me what they are.

(In reply to Dão Gottwald [:dao] from comment #4) > Bug 803970 comment 11 mentions privacy implications, but it's not clear to > me what they are. Calling them "privacy implications" is probably the wrong term. I'm talking about people being upset that a site they didn't intend to load gets connected to, either because they don't want that site to be aware of their online "presence" or for some other reason. Some people can be very sensitive about software doing things on their behalf without their consent; this preference would be for those people.

(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #5) > (In reply to Dão Gottwald [:dao] from comment #4) > > Bug 803970 comment 11 mentions privacy implications, but it's not clear to > > me what they are. > > Calling them "privacy implications" is probably the wrong term. I'm talking > about people being upset that a site they didn't intend to load gets > connected to, either because they don't want that site to be aware of their > online "presence" or for some other reason. Some people can be very > sensitive about software doing things on their behalf without their consent; > this preference would be for those people. That bug was however filed specifically because the user thought we'd leak the typed string while typing. The pref would affirm such misguided concerns and help spreading FUD.

(In reply to Dão Gottwald [:dao] from comment #6) > That bug was however filed specifically because the user thought we'd leak > the typed string while typing. The pref would affirm such misguided concerns > and help spreading FUD. I understand the concern, but I think that's a bit of a stretch. The bar for us adding hidden preferences for power users has to be lower than "can't possibly be misunderstood", because no pref meets that criterion. Weighing the benefit to configurability vs. the risk of misunderstanding seems very subjective. The primary goal here was to give the (vocal) minority concerned about the fixes for the depending bugs an easy way out. If you're not concerned about those fixes, and think we shouldn't cater to the users who are, then I guess we can WONTFIX this.

I'm not even sure the users you're describing exist, let alone that it's a vocal group. At least they don't seem to have reached bugzilla yet, given that bug 803970 was based on a misunderstanding.

FWIW Chrome has an option to disable TCP pre-connections. If this is the case, we should have such an option too. http://code.google.com/p/chromium/issues/detail?id=116982#c4

I disagree; Chrome having a pref, on its own, isn't reason enough to add a pref to Firefox.

I would surely want such a pref in Firefox and even more in Thunderbird.

I also would like this pref to exist. As a user on an extremely limited connection, I have all methods of prefetching, pre-opening, and anything else that creates unnecessary overhead disabled. While you may not think a simple opening TCP connection request is much overhead, it is to many of us. My ISP in particular requires more than just TCP communication to initiate a connection, all of which is counted against my total allotted usage. It does not matter if it's a single bit or a gigabyte, it counts against me, and I need every bit I can get.

Please reconsider your decision about WONTFIXing this. Mozilla have long been associated with privacy/security, so giving users an option to control unrequested/automatic connections is essential IMO. I also think Firefox should honor the pref in the case of the search bar. Firefox privacy policy and this article http://mzl.la/Mxv856 should also mention speculative pre-connections. Maybe open a new topic on firefox-dev mailing list?

Note that this is an issue for performance measurement extensions as well (including Firebug, apparently). In our case we have an extension that measures all the requests on a given page, and since speculative connections were implemented, we are no longer able to get reliable statistics about DNS resolution and connection times. IMO a global pref to turn this behavior off would be a very useful feature, irrespective of privacy concerns.

Try setting 'network.http.speculative-parallel-limit' to 0.

Hey, here’s a potential tracking scenario: * Mallory has a database of unverified email addresses. He wants to know which of them are read regularly. * Mallory associates with each unverified email address a unique IPv6 address within his /64 network. * Mallory sends each unverified recipient a message which consists of a hyperlink to this unique IPv6 address, wrapped around a lot of text. * Alice views this message in a web mail client in Firefox. She inadvertently leaves the mouse in the area where the message is to be displayed. * Firefox speculatively connects to the address of the link. * Mallory’s router receives all connection attempts and logs destination addresses. * Because each recipient got a unique IPv6 address, Mallory marks Alice’s email address as verified.

Please let me add my vote for this being in PRIVACY prefs. Email Spam typically includes an attempt to track receipt of the email with at least one large remote-loaded image, or an embedded image that is also clickable. The URLs for these things contain unique tracking IDs. Responsible webmail providers rewrite the page so remote-load images are blank squares only loaded with explicit user consent. (Don't get me started on web-gmail, though they do allow you to disable the image pre-fetch 'feature' and I certainly did). But whether loaded or not these large areas remain 'clickable'. Upshot is, the user has a *reasonable expectation* that merely hovering over a clickable link or clickable image in webmail -- one so large it is possible the user is just mousing past it -- will not trigger activity that allows tracking. Let me add to Yuri Khan's IPv6 tracking scenario a simpler one where the spammers operate their own DNS servers and their domain is wildcarded handing out zero TTL A records, and tracking URLs embedded in emails have unique hostnames 'UniqueIDxxx.spammerdomain.com'. A mere DNS lookup supplies spammers with a gateway ip address and positive ID of the email address. There is also the scenario where the brower is locked down with NoScript, or a locally saved version is being displayed. Once the page has loaded statically or locally there is a *reasonable expectation* that remote tracking on hover cannot happen in real time. Speculative pre-connections allow that line to be crossed.

[wish there was an 'edit'] > A mere DNS lookup supplies spammers with a gateway ip address and positive ID > of the email address." To clarify, the DNS lookup would provide positive ID of an active email address which is what spammers most desire. An actual speculative pre-connection would also leak the gateway ip, allowing them to know your approximate location, icing on the cake.

I use Firefox with RequestPolicy to load the pages I want without notifying servers I don't want (typically, google or facebook don't have to know that I read this or that article). This is to tell that I am quite concerned about which servers my computer send information (a connection is a piece of information). But without even being aware of, I learned on slashdot¹ that Firefox (and Iceweasel) contacts a server as soon as I hover a link… This is quite annoying to have such a default behavior. I often hover links in order to check the url in the status bar, not to inform silently the server pointed to by the link. This is for me an unwanted behavior. I think the user should be able to trust its browser not to silently send information, on its own, to arbitrary remote server (any link would trigger a speculative connection). ¹ http://news.slashdot.org/story/15/08/14/2321202/how-to-quash-firefoxs-silent-requests

So stuff with non-negligible security impact gets WONTFIXed these days? Nice to know.

This can be used to instantly identify a user using a site's private messaging feature, or identify users viewing a thread in a web forum. Just like 18 says: https://bugzilla.mozilla.org/show_bug.cgi?id=814169#c18 An attacker can send a private message to a user on say, reddit, or on a forum (any medium that accepts user submitted links), containing a unique ipv4 or ipv6 url. The victim does not even have to click the url. If they hover over the link, the attacked can know who they are. I predict that this feature will only be of benefit to attackers wishing to cause their victims to generate traffic for marketing and de-anonymization purposes. http1.1 / tcp is slow. Pre fetching / handshaking will give marginal round trip speedups to users on slow networks at the cost of privacy and massive amounts of wasted bandwidth due to accidental hovers. A more effective way of helping these users is to push for http/2 and QUIC and stateless protocols in general to be used by default on the major web-server distributions. Apache, Nginx, iis, etc. Demonstrably harder than pushing 814169. But it's the right thing to do. Please only turn this on when a slow network is detected. Or at least, give us an option to turn it off in the preferences. Thanks for your help.

The trouble I have with features like this is that I suspect there's very little thinking going on along these lines: - Is the added complexity (and thus maintainability and potential for bugs) cost worth the benefit of this feature? - Is the increase in security attack surface worth the benefit of this feature? My fear is that this will one day provide a very easy way to massively exploit or amplify a new security hole in, say, the javascript engine, HTTP, TLS, the TCP/IP stack itself, or maybe something else entirely that we haven't thought of yet. And for what? A tiny or imperceptible improvement in page load times? On pages people haven't even requested, and 9 times out of 10, won't? I have a hard time seeing all the extra overhead of this being worth it. And I suspect some people will react to that paragraph by saying (at least in their heads), "hah; overhead! he's so misinformed; all we're doing is opening the connection; we're not even sending a request!" That's not what I mean by overhead -- I mean that in order to make this work, you had to add some lines of code to the source. In order to make it work, someone had to debug and test those lines of code (and they probably didn't test it very thoroughly, because "it's not the real page load request; it's just an empty connection; what could go wrong?"). And in subsequent new versions, someone is going to have to regression test this feature (but again, "it's such a low-impact feature; what could go wrong? there's no way a change in other blocks of code could affect such a tiny block over here; I'm going to save time and not even look at it"). That's a *lot* of programmer hours and brain time for something that has, as far as I'm concerned, very little practical benefit to anyone. So decisions will be made that the overhead isn't worth it, and tests will get skipped, and it'll get omitted during code reviews, because frankly, it *isn't* worth all that time... and then a few months or a year or two from now, someone will discover a *completely* off the wall bug in, for argument's sake, let's say the way SYN cookies work in some OS's TCP flood protection, and that under certain conditions it's possible to cause an obscure crash in the firmware of some common brand of NIC when the default combination of TCP checksum offloading is enabled during a set of TCP connections that cause SYN cookies to be sent, and that normally you'd have to get a user to connect to a specific, infrequently used high port number to take advantage of this... but oh look, here's this little bit of code in Firefox that makes this super easy to do by (wait for it), link hovering. How can even the possibility of this feature contributing to such a scenario be worth it? Little things like this, done over and over, is why modern software is so full of holes, it really is.

Following on my previous comment, it occurs to me that this 'feature' might be a way to bypass SYN cookie protection -- i.e. someone could use this to cause what is effectively a SYN flood against a target server, but because Firefox is "legitimately" opening these connections, it will respond with the correct sequence number and force the target server to open a real connection. So, for instance, if I want to attack someone, I spread a link around, maybe via some online game I invent whose objective is to move the mouse around (and layer a bunch of hidden links all over the page), or even just posting something with a clickbait title on a popular comments page, and let people hovering over the link to see where it goes do my work for me. (I do find it funny that something about SYN cookies might actually be exploitable with this, considering I only chose SYN cookies for my example by mental dice-roll. Wonder what else might be possible with this feature?) If Firefox doesn't disable this feature, I wonder if we'll soon see "defeat speculative page load" as a feature in web servers, where the server will aggressively close connections if it doesn't get a request, and maybe block subsequent ones for a little while if the next connection is also speculative (on the assumption that someone is mousing and unlikely to click), and what exciting little bugs we'll see as a result of that. Or maybe we'll see it as a default feature in personal firewall apps, sold as protecting privacy or reducing bandwidth. And in all of those cases, that's more code being added, more stuff that needs testing, and more potential for exploits and bugs.

Edit: Damn it! Posted this to the wrong bug. Need more coffee! #c25 Thank you for your reply and link Gavin. I have read https://support.mozilla.org/en-US/kb/how-stop-firefox-making-automatic-connections and I agree that if a user follows all these steps, they can stop firefox from pre fetching or pre connecting to malicious servers. Unfortunately most users will not even think to look for this page because firefox gives no responsive UI indications that it is currently pre fetching a link. Be it Dns or tcp connections. You could fix this problem by making pre fetching on hover EXPLICIT: Every time firefox autonomously connects to something, the user should receive a visual indication of this. This way, the user will be informed that these features are active. And interested users will know to look for the page you have just linked. This could be anything from triggering the "page loading" animation in the address bar, to simply adding the word "PRELOADING" next to the url in the "status bar" / "status popup" at the bottom of the page when the user hovers a link. Or you could add a single checkbox in the Preferences in the privacy section that turns all pre-fetching on or off. This way users who are curious about privacy settings will be informed of this behavior and have the choice to protect themselves at the cost of one round trip ping time in performance gains per connection. Please don't ignore these issues Gavin. The trade-off between performance and privacy must AT LEAST be made EXPLICIT to the users. Then they can make their own choices. Adding Stacy from privacy team (That correct?). It's really hard to figure out who's on what team on bugzilla. Who do we contact for the user story / UI team?

(In reply to Yuri Khan from comment #18) > Hey, > > here’s a potential tracking scenario: > > * Mallory has a database of unverified email addresses. He wants to know > which of them are read regularly. > * Mallory associates with each unverified email address a unique IPv6 > address within his /64 network. > * Mallory sends each unverified recipient a message which consists of a > hyperlink to this unique IPv6 address, wrapped around a lot of text. > * Alice views this message in a web mail client in Firefox. She > inadvertently leaves the mouse in the area where the message is to be > displayed. > * Firefox speculatively connects to the address of the link. > * Mallory’s router receives all connection attempts and logs destination > addresses. > * Because each recipient got a unique IPv6 address, Mallory marks Alice’s > email address as verified. Tor Browser has the same issue (because of the Firefox-base) https://trac.torproject.org/projects/tor/ticket/16840

Hi all, I'm adding Marshall Erwin. He does these reviews now. Apologies for the slow response and that it's difficult to figure out who's on what team. I'll see if we can make it clearer for privacy.

I am really concerned at the cavalier attitude I read above about this issue. An assumption has been made that someone whose mouse passes over a link wants to click it. That's simply not true. It's bad enough when a menu drops down on top of the article you were reading because you couldn't get your cursor to the text in the page to scroll without passing through an element covering the entire top or side of the web page. But sending information to and from that link is completely irresponsible. Anyone who thinks that banners covering the entire top or side of a webpage is a rare and isolated instance isn't living in this reality. You have handed the bad actors an absolute gem and you've also treated users' privacy and bandwidth as yours to dispose of as you wish. Saying that it is small ignores the fact that it wasn't yours. It wasn't for you to say. Loading sites I have absolutely no intention of ever clicking on just because I needed to get my cursor to where I could scroll was so obviously a BAD idea, and people have been telling you about it for a long time now. I'm also concerned that it took so much effort to find out the secret setting to turn this garbage off. I'm not at all convinced you have regular users' interests at heart. I don't see evidence of it above in the RESOLVED WONTFIX fix label. This particular "feature" needs to end.

To follow the point in comment 31 through: there is currently an on-going spamrun (emails with topic Fw: read this) with links in the email. So you only have to hover over the link to let the spammer know the email is active. This "feature" needs to be removed ASAP. I can not imagine what reasoning people can have to think this is a good idea.

I consider the lack of this user option to be a severe security vulnerability. Moving my cursor across a Web page from the scroll bar to a desired link (or vice-versa) can easily subject me to loading an unwanted advertisement, a tracking cookie, malware, etc.

I'm not sure why this was "WONTFIX", as it seems "FIXED" to me. The preference exists: https://support.mozilla.org/en-US/kb/how-stop-firefox-making-automatic-connections To disable speculative pre-connections, simply set network.http.speculative-parallel-limit to 0.

IMHO this shoud be a setting in the security tab of the options page and the feature should be deactivated by default. But even more: this is a useless feature that only has a potential to be misused and should be removed.

To respond to comment 34: that fix is WAY too obscure for the normal user, who won't even know that this is happening to look for it. Suddenly your pc has malware and you have no idea what even happened, you did nothing different than you ever had while browsing. Is that not the definition of a security risk? Let those who really want the millisecond of better performance turn it ON for themselves, if they don't care about viruses. The rest of us should not have this happening behind our backs.

I get that you think the preference is not enough, but this bug isn't the right place to discuss it, as this bug only tracked adding the preference. Since the preference has been added, the bug can be closed as fixed. If you want to discuss adding other features to control speculative pre-connections, you should do so on other channels (one of the Mozilla mailing lists) since Bugzilla is not a forum, but a bug tracker.

For now, if anyone wants a UI pref, I've added all the Maximum Simultaneous Connection options to the Data Choices tab of the Advanced pane to the next version of my extension SettingSanity (<https://addons.mozilla.org/addon/settingsanity/>). The beta can be found at <http://realityripple.com/Software/Mozilla_Extensions/SettingSanity/beta/> for now.

See bug #1211165 for a user interface.