I don't see why a conversion to multi-process has to worsen privacy, but: It apparently involves significant code changes within Firefox as well as some addons. Bugs, premature rollouts, elimination of some features which can no longer be as easily implemented, and/or developers abandoning some addons could have a negative impact. Some fingerprinting techniques are pretty creative, and I wonder if there could be any consequences on that front. I worry about startup, and maybe other cases, where you would want a security/privacy addon to reliably block things. Such an addon must be able to hold off [all] communications until it is ready or otherwise needs to, regardless of how long that might be. When fundamental changes are made to existing code, previous priorities and decisions are rethought. Which can lead to new priorities and decisions that aren't as privacy friendly. Mozilla is also deprecating XUL & XPCOM, and transitioning to WebExtensions. So there are big shifts underway, arguably warranting closer attention than normal and re-validation of things we rely on.
I understand those points and agree that we have to keep a close eye on the implications of all those changes. I appreciate that you don't see multi-process itself as a privacy threat, either.
I use this plugin to tweal Firefox settings https://addons.mozilla.org/en-US/firefox/addon/privacy-settings/?src=search It has most of what you need to tweak.
http://mxr.mozilla.org/mozilla-central/source/toolkit/components/thumbnails/BackgroundPageThumbs.jsm @line45 The behavior is documented inline within the source code. Apologies -- I had misread the documentation. It states that all plug-ins (rather than all extensions) are disabled during the load, which is a GOOD thing.
MXR has been returning a "The service you’re looking for is unavailable at the moment. We’ll be back up and running again before long, so please try again soon." page, but FYI: MXR permanently offline, please transition to DXR https://mail.mozilla.org/pipermail/firefox-dev/2016-June/004388.html https://mail.mozilla.org/pipermail/firefox-dev/2016-July/004429.html Oh, and in case this is of interest... https://addons.mozilla.org/addon/clean-links/ https://github.com/diegocr/CleanLinks
CleanLinks accepts custom regex patterns, which is handy... ...yet performing "cleaning" via DOM manipulation is a busted approach, IMO. "Escalation" (via deferred settimeout checks performed by anti-adblocker et al scripts) seems inevitable.
The File Save As feature in Firefox (and likely other Gecko based apps, and maybe even other browsers too) can bypass some protective measures we put in place. For example, a File Save As (Web Page, complete) may download something that the user is blocking via extension. Not only allowing the request out but also retrieving the resource (which might be loaded when the user opens the saved web page using their browser). There has been some discussion on this before. I saw this potentially new or at least interesting example earlier: http://leucosite.com/FireFox-LFD-and-SOP-Bypass/
These are the ways I know of to capture Firefox background traffic: External tool: Wireshark, Tcpview, software firewall, etc. Extension: I don't know whether there is a solid choice at this point. Due to some reports of extension conflicts and the e10s/WebRequest transition. NSPR logging: A traditional way of instructing Firefox to log various things and from startup. Sometimes you can't get the level of detail you want without excess verbosity, but it is useful for some purposes. Browser Console: Doesn't provide as much information as it used to, but it is an easy way to get a peek at network requests. Check the Net drop down filter and make sure xhr and log are checked. Browser Toolbox: Provides more detailed information and other debugging capabilities. Gotta start somewhere, so how about: Close all instances of Firefox Disconnect/disable your network adapter so that there is no network connection when we relaunch Firefox Launch Firefox. To a blank page, or at least eliminate the content tabs and leave one tab on about:blank. We don't want tabs generating traffic [during the first tests]. Open Browser Console Put Firefox in Work Offline mode Connect/enable your network adapter and give it a moment to come up Take Firefox out of Work Offline mode. Look at the network request information in the Browser Console. Let it sit for awhile and see whether more requests occur. The information should include method, scheme, host name, and path. Does that shed more light on things? Note: Normally I don't go through that whole process. If I take steps to eliminate content tab traffic and immediately open the Browser Console after launching Firefox I typically see all the requests I'm interested in. However, there have been contexts where some early requests weren't shown. I'm not sure why, to be honest, and it might have something to do with my configuration. However, when I switched to the "possibly more favorable sequence" outlined above, the Browser Console did report the earlier requests that were previously not displayed. So that's why there are some additional steps that may seem unnecessary. You can try things different ways and see if you notice a difference.
Another convenient way is to use uMatrix. Open its logger and observe what Firefox connects to, particularly behind-the-scene requests which can be easily controlled by uMatrix.
Well here's a trimmed down copy/paste from the uMatrix logger showing the first series of requests made by a fresh FF48 portable with a blank start page (first request at the bottom, last request at the top): Code: https://blocklist.addons.mozilla.org/blocklist/ http://ocsp.digicert.com/ https://versioncheck-bg.addons.mozilla.org/update/VersionCheck.php?reqVersion=2&id=uMatrix@raymondhill.net https://versioncheck-bg.addons.mozilla.org/update/VersionCheck.php?reqVersion=2&id={972ce4c6-7e08-4474-a285-3208198ce6fd} https://versioncheck-bg.addons.mozilla.org/update/VersionCheck.php?reqVersion=2&id=loop@mozilla.org https://versioncheck-bg.addons.mozilla.org/update/VersionCheck.php?reqVersion=2&id=firefox@getpocket.com https://versioncheck-bg.addons.mozilla.org/update/VersionCheck.php?reqVersion=2&id=e10srollout@mozilla.org http://ocsp.digicert.com/ https://services.addons.mozilla.org/en-US/firefox/api/1.5/search/ https://safebrowsing-cache.google.com/safebrowsing/rd/ ... https://safebrowsing-cache.google.com/safebrowsing/rd/ http://clients1.google.com/ocsp https://safebrowsing.google.com/safebrowsing/downloads https://aus5.mozilla.org/update/6/Firefox/48.0/ https://incoming.telemetry.mozilla.org/submit/telemetry/ http://ciscobinary.openh264.org/openh264 http://vassg142.ocsp.omniroot.com/ https://cdmdownload.adobe.com/firefox/win/ http://ocsp.digicert.com/ https://aus5.mozilla.org/update/3/GMP/48.0/ http://ocsp.digicert.com/ https://incoming.telemetry.mozilla.org/submit/telemetry/ https://incoming.telemetry.mozilla.org/submit/telemetry/ https://tiles-cloudfront.cdn.mozilla.net/images/ ... https://tiles-cloudfront.cdn.mozilla.net/images/ https://normandy.cdn.mozilla.net/static/bundles/selfrepair http://ocsp.digicert.com/ http://ocsp.digicert.com/ http://ocsp.digicert.com/ https://tracking-protection.cdn.mozilla.net/mozstd-trackwhite-digest https://tracking-protection.cdn.mozilla.net/mozstd-track-digest256 https://search.services.mozilla.com/1/firefox/48.0/ https://tiles-cloudfront.cdn.mozilla.net/desktop/STAR/ http://ocsp.digicert.com/ http://ocsp.digicert.com/ http://ocsp.digicert.com/ http://ocsp.digicert.com/ http://ocsp.digicert.com/ http://ocsp.digicert.com/ http://ocsp.digicert.com/ https://self-repair.mozilla.org/en-US/repair I was watching the Browser Console at the same time. Both "captured" the same things but the uMatrix logger showed the query string too (which is helpful). I wasn't running an external tool to verify nothing was missed.
I highly doubt a connection can be made, when there is no tab for these sites opened. Have you captured the requests? Maybe we can look at it to determine what they are.. I understand requests to Google (like safebrowsing..), Facebook (i am intrigued)..
Yes, uMatrix/uBO can show browser and other extension requests too. Basically its logger uses Firefox HTTP Observer, and will log all the requests fired by it.
The second sentence is correct, the first one is completely wrong. uMatrix monitors those behind-the-scene requests. You can see them in the logger if there is a in the second column. If you click that symbol the behind-the-scene matrix opens. By default, all bts requests are allowed but you can block them by clicking the "All" cell. Then you can selectively allow specific requests.
Thanks for the info, I will see if I can perhaps do a bit more research, but to be honest I don't want to spend too much time on it. I try to block as much as tracking as possible, but I doubt you can block them all, without simply dropping the browser. I have noticed this behavior via TCP Monitor and SpyShelter which also has a network monitor. With no tabs open and no active connections, both Firefox and Opera 12 will continue to connect to Google and Facebook, this happens every 15 minutes or so. I have never paid any attention to this before, but since I'm actively blocking trackers with extensions I was a bit surprised.
Just fire up FF in Sandboxie, install NoScript and RequestPolicy, turn off white-list in both add-ons, do you still see traffic? Try next uninstall all add-ons except NoScript and RequestPolicy inside Sandboxie and restart your Firefox (Ctrl+Alt+R). How you also turned of all browser features such as safebrowsing etc?
No problem, we'll give you a few days to prepare your report and twenty seven eight-by-ten color glossy photographs with circles and arrows and a paragraph on the back of each one explaining what each one was Seriously though, the main thing is that you grow comfortable inspecting traffic via the browser. Many questions can only be answered by looking at the URLs being requested etc. So do try to make some time for that even if you don't feel the need to do it for this particular situation. The repetitive nature should make investigation easier. If you capture/view browser requests and use your external tool at the same time, you will hopefully be able to correlate the two and quickly zero in. As for suspects: Firefox and most extensions will phone home using URLs that are stored in preferences and therefore can be found via about:config. For example, you'll see loop.facebook.enabled and a loop.facebook.shareUrl that points to www.facebook.com. I think it will only connect to FB in Loop usage contexts. I don't see a FB search plugin that is installed by default. However, a search plugin can generate traffic not only in response to an explicit search but also in response to search suggestions while typing and search plugin update check. There are some contexts where Firefox will perform speculative connections and/or prefetching. Some related info: https://support.mozilla.org/en-US/kb/how-stop-firefox-making-automatic-connections There are some FB related extensions/addons and those would be obvious suspects. Some third-party advertising, analytics, etc systems utilize CNAME records to explicitly redirect things at the DNS level. For example, http://www.innocent-looking.example/ will result in a connection to host www.evil.example if www.innocent-looking.example is mapped to www.evil.example. Plus, as you've noticed and commented on before, there are also CDN and other cases where www.innocent-looking.example simply resolves to the IP Address of a machine operated by evil.example folks, and that becomes evident when you see a reverse DNS name that doesn't jive with the name of the host you knew you were connecting to. Examining things from the browser side while also examining things via an external tool that shows connections and DNS info help you to spot such "mismatches".
I just did a quick experiment, I fired up FF with no extensions. There is no more communication with Google and Facebook, but it did connect to some other hosts, so it's obvious there is always some "phoning home" going on. I think the things that you mentioned explained it all. It's probably nothing to worry about, and it also doesn't happen all of the time. In the last 30 minutes I didn't see FF connecting out for no reason. I use this tool to monitor it: http://www.softpedia.com/get/Network-Tools/Network-Monitoring/TCP-Monitor.shtml
If you are comfortable telling us what extensions you are using, I'd like to take a quick look at those. To get a better sense of the exposures caused by extensions. Google and Facebook are of interest to some Well, even the simplest phone home exposes some information to others. Most forms expose something sensitive enough... and/or empower others to exert some control over your software... to warrant even more attention. Phone home is never desirable in the strictest sense, but some of it may have offsetting advantages and for that reason be considered tolerable by some users. AFAIK, you can still kill ALL of it in Firefox via various settings/prefs. One of the things I periodically do is look at the remote hosts that Mozilla developers build into Firefox via prefs and perform some simple analysis to get a party-oriented sense of the exposures. Its rough in some respects but it helps. Below is the output I generated for FF 47.0.1. It shows the hosts I extracted and the eTLD (effective TLD, public suffix) of the final CNAME (when one or more CNAMEs are present) plus the eTLD from reverse DNS lookups of the IPv4 addresses. It appears to me that Mozilla uses its own systems for some things but heavily utilizes Amazon AWS, Amazon Cloudfront, and CloudFlare. Plus Google for the Google SafeBrowsing lists. Code: Host Final CNAME eTLD IPv4 rDNS eTLD ---------------------------------------------------------------------------- addons.mozilla.org mozaws.net amazonaws.com aus5.mozilla.org mozilla.com amazonaws.com blocklist.addons.mozilla.org mozaws.net amazonaws.com ftp.mozilla.org cloudfront.net cloudfront.net incoming.telemetry.mozilla.org amazonaws.com amazonaws.com input.mozilla.org mozilla.com mozilla.com self-repair.mozilla.org amazonaws.com amazonaws.com services.addons.mozilla.org mozaws.net amazonaws.com support.mozilla.org mozilla.com mozilla.com versioncheck-bg.addons.mozilla.org mozaws.net amazonaws.com versioncheck.addons.mozilla.org mozaws.net amazonaws.com wiki.mozilla.org mozilla.com mozilla.com www.mozilla.org cloudflare.net UNAVAILABLE auth.services.mozilla.com mozilla.com UNAVAILABLE copy.loop.services.mozilla.com localhost crash-stats.mozilla.com mocotoolsprod.net amazonaws.com data.mozilla.com mozilla.com amazonaws.com en-us.malware-error.mozilla.com mozilla.com mozilla.com en-us.phish-error.mozilla.com mozilla.com mozilla.com en-us.phish-report.mozilla.com mozilla.com mozilla.com firefox.settings.services.mozilla.com cloudfront.net cloudfront.net location.services.mozilla.com mozaws.net amazonaws.com loop.services.mozilla.com mozilla.com amazonaws.com push.services.mozilla.com mozaws.net amazonaws.com search.services.mozilla.com mozilla.com amazonaws.com services.mozilla.com mozilla.com setup.services.mozilla.com mozilla.com UNAVAILALBE shavar.services.mozilla.com mozaws.net amazonaws.com tiles.services.mozilla.com mozilla.com amazonaws.com token.services.mozilla.com mozilla.com amazonaws.com activations.cdn.mozilla.net cloudfront.net cloudfront.net code.cdn.mozilla.net cloudfront.net cloudfront.net fhr.cdn.mozilla.net cloudfront.net cloudfront.net snippets.cdn.mozilla.net cloudfront.net cloudfront.net telemetry-experiment.cdn.mozilla.net cloudfront.net cloudfront.net accounts.firefox.com amazonaws.com api.accounts.firefox.com amazonaws.com detectportal.firefox.com cloudfront.net UNAVAILABLE hello.firefox.com amazonaws.com marketplace.firefox.com amazonaws.com oauth.accounts.firefox.com amazonaws.com profile.accounts.firefox.com amazonaws.com mail.google.com google.com 1e100.net safebrowsing.google.com google.com 1e100.net sb-ssl.google.com google.com 1e100.net www.googleapis.com google.com 1e100.net add.my.yahoo.com yahoodns.net yahoo.net compose.mail.yahoo.com yahoodns.net yahoo.com 30boxes.com amazonaws.com api.getpocket.com amazonaws.com api.imgur.com imgur.com UNAVAILABLE cdnjs.cloudflare.com UNAVAILALBE getpocket.com amazonaws.com mozsocial.cliqz.com amazonaws.com amazonaws.com www.facebook.com facebook.com facebook.com www.mibbit.com linode.com www.surveygizmo.com cloudfront.net cloudfront.net
Yes correct, I also sometimes see connections to Amazon and CloudFlare. About my extensions, I'm using uBlock, Ghostery and NoScript and I have disabled auto-update. So normally speaking, these extensions should not be phoning home. BTW, what do you think about GlassWire, would you use it for monitoring connections? https://www.glasswire.com/
Well I did take a quick look at each, separately, using a fresh FF48 portable. Each of the extensions has one or more features that if used will cause connections to remote servers. However, I didn't see something obviously pertinent to your "Firefox connects to Google and Facebook, this happens every 15 minutes or so" issue. My tests might not be close enough to your configuration, though. Plus, you seem to be making the Google and Facebook association by working backwards from server IP Address. We might be seeing different servers and reverse names due to being in different regions. You reported favorable conditions for further investigation (repeatability with a shortish period, reason to suspect it is extension related). So if/when you want to learn more, perhaps you can make progress through: Additional process of elimination (try one extension enabled at at time) Look at browser activity from within the browser so you can see URLs. Monitor DNS queries/responses so that when there is a connection to an IP Address [and reverse DNS name] of interest, you can look back through earlier DNS activity and find the hostname that was originally looked up. You could post the questioned IP Addresses and reverse DNS names, but that may not be enough for others to go by either. I haven't looked at Glasswire yet, but hope to before the end of the year. It may have useful features, but I doubt you need it and/or those features to shed more light on this phone home issue. Just #1 and #2 above should be enough. Browser Console doesn't bite. Forgot to mention: During this round of testing I finally noticed that FF48's Browser Console has the right pointing triangles that you can click on for expanded information about requests.
Setting identity.fxaccounts.remote.webchannel.uri to empty string breaks firefox https://bugzilla.mozilla.org/show_bug.cgi?id=1270160 VERIFIED FIXED (in FF49)
Intent to Implement System Add-on: SHIELD/Normandy https://mail.mozilla.org/pipermail/firefox-dev/2016-September/004594.html https://wiki.mozilla.org/Firefox/Shield
