Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Correct a number of factual inaccuracies. #19

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

gerv
Copy link

@gerv gerv commented Jul 2, 2015

Hi,

I'm not entirely sure of the purpose of your list. It's called "Firefox Debloat", but none of the changes here significantly affect memory usage in the common case. The text talks about "actively leaking data to third party services" (presumably without consent), but there are several entries which don't do that. I've tried to clean the list up a bit and correct some of the inaccuracies. For example, Safe Browsing downloads lists of malware sites (every Firefox downloads the same list) and so no history data is leaked. The only exception is uncommon downloads.

Similarly, no connections are made to Pocket unless you try and save a URL to Pocket (at which point it invites you to sign up) or you click "Get Pocket List" on the bookmarks menu (this is like a bookmark, basically) which also invites you to sign up. So I'm not sure what data you think is "leaked". But I didn't remove it entirely because I wanted to ask.

Similarly, geolocation sends your location only with your explicit consent.

I welcome your feedback on these changes :-)

Gerv

@sunaku
Copy link

sunaku commented Jul 2, 2015

👍 Looks good, thanks for the corrections. 📝

@initbar
Copy link
Contributor

initbar commented Jul 3, 2015

👍

@gerv
Copy link
Author

gerv commented Jul 9, 2015

OK, so can we merge this then? :-)

@initbar
Copy link
Contributor

initbar commented Jul 9, 2015

I guess that depends on @amq

@Gitoffthelawn
Copy link

@gerv wrote: "Safe Browsing downloads lists of malware sites (every Firefox downloads the same list) and so no history data is leaked."

Is the 'Safe Browsing' data downloaded directly from Google, Inc.? If so, does that give Google, Inc. a list of the external IP addresses of every system using Firefox with that feature enabled, as well as the user-agent string from each of those browsers? Default user-agent strings provide a significant amount of data, including OS used (and which version), the version of Firefox installed, the CPU architecture of the system, and sometimes more.

@gerv
Copy link
Author

gerv commented Jul 11, 2015

Yes, this feature sends to Google the same information that you send to Google any time you visit one of the > 50% of websites in the world which include some asset from Google (analytics, CDNed JS, +1 button etc.). It's also the same information that every website owner gets. If you think that revealing to Google that "someone somewhere behind IP 12.34.56.78 uses Firefox on Mac OS X" is a privacy leak, then you need to replace this entire document with the words "Always use Tor".

@aidecoe
Copy link

aidecoe commented Jul 11, 2015

But you can block that stuff with AdBlock, NoScript, Ghostery, can't you?

@gerv
Copy link
Author

gerv commented Jul 11, 2015

Without using Tor, you can't block every website you visit from knowing your IP address. You could spoof your user agent to claim you were using a Commodore 64, but then various websites would break in various ways as they don't know what content to send to a Commodore 64.

But the question is not about whether you can block it, the question is about whether it's a privacy violation. And I don't think "someone somewhere behind IP 12.34.56.78 uses Firefox on Mac OS X" is a privacy violation, given that unless you are using Tor, you say it to every website you visit. Privacy violations, to simplify slightly, tend to involve the website knowing something private about a particular person. This information gives them neither of those things.

I think the problem here is that no-one seems to know what the point of this list of changes is. If it's "debloating Firefox", then it doesn't work - none of these changes affect Firefox's size in memory or size on disk. To affect that, you'd have to recompile Firefox. (For most of them, the code isn't run unless you use the feature, so there's no memory gain to be had.) If it's "making Firefox more private", then you need to have some idea of what level of privacy is acceptable to you. Like I said, if telling websites your IP address is a problem, you need to replace the entire page with "just use Tor". If it's "stop Firefox using or downloading proprietary code", then that would be a different set of changes again, and would include disabling the addons repository because some addons are proprietary. What it seems to be at the moment is "break Firefox in lots of ways to make it less useful so that people go and use Chrome instead, which will be much worse for their privacy".

@aidecoe
Copy link

aidecoe commented Jul 11, 2015

Showing your IP to a particular website is not a problem. But if you provide a set of websites you browse to a single entity capable of making use of this kind of information then it's a subject of concern.

@gerv
Copy link
Author

gerv commented Jul 11, 2015

aidecoe: Quite possibly. But that's not what the safe browsing feature does. It downloads a list of bad websites that users shouldn't visit from Google, and then locally compares each site you visit against it. No history leak (unlike other implementations of the same feature in other browsers, I might note).

The anti-downloading-malware feature, which is a different feature, sometimes (when you are downloading a file not many people download) sends a partial hash of that file to Google, because we can't pre-download hashes of every file in the universe. But the hash, of course, doesn't give Google a copy of the file, and doesn't even necessarily let them know which file it is even if they've seen it before (i.e. it's public). If you want to object to this, fine. But there's no objection of this sort to safe browsing.

@aidecoe
Copy link

aidecoe commented Jul 11, 2015

So... it doesn't check addresses on the fly?

@gerv
Copy link
Author

gerv commented Jul 11, 2015

Safe Browsing checks sites on the fly, but not against a remote source. It checks against the local source. (It used to be that you could turn on remote checking on the fly, but we may have removed that. Regardless, if it's still in there somewhere, it's definitely not on by default.)

@gerv
Copy link
Author

gerv commented Jul 30, 2015

The current text says a number of factually incorrect things about Firefox, which is unfair. Can this pull request get some attention? :-)

@hrj
Copy link

hrj commented Aug 2, 2015

@gerv

If you think that revealing to Google that "someone somewhere behind IP 12.34.56.78 uses Firefox on Mac OS X" is a privacy leak,

Nope, it leaks authentication cookies as well. Have a look at the discussion in this bug report.

@gerv
Copy link
Author

gerv commented Aug 2, 2015

As that bug report (resolved FIXED) clearly shows, it hasn't leaked authentication cookies since Firefox 27, released in February 2014.

@hrj
Copy link

hrj commented Aug 2, 2015

Oh, my bad. I missed the one comment which says that SB is now sandboxed.

However it still does store and send a cookie. So it is not just IP + UA String that is leaked.

@Gitoffthelawn
Copy link

@gerv Are those Google cookies really sandboxed? In the Firefox UI, they appear just like any other cookie.

Is there a test mechanism available to see if the claimed sandbox really works?

@gerv
Copy link
Author

gerv commented Aug 2, 2015

Gitoffthelawn: so you think we spent all the time engineering a privacy mechanism for this that doesn't work? It would be nice if we could dispense with the climate of suspicion and accept that Mozilla is filled with privacy-loving people too.

If you want to see what SafeBrowsing does, then have the dev tools or LiveHTTPHeaders open when it makes a request for the list, and you can see. What you should see is that it doesn't send any standard Google login cookies you may have for G+ or whatever. I believe there is a cookie which is specific to this service, so they can detect abuse (e.g. people hitting the service lots of times per day). I think that's reasonable, personally - running free web services at scale is hard. The exact details of how that cookie works are probably in the documentation but, if not, they are in the source.

And I think using the word "leak" about your IP and your UA string is silly. These are things you send to every website you visit, and you send them to Google specifically when you visit 50%+ of the websites in the world. The way the Internet is engineered, websites get to find out your IP address. If you don't like that, then replace all of this advice with three words: "Just Use Tor". Although you might want some more words to explain to people why their internet performance just got significantly degraded.

@hrj
Copy link

hrj commented Aug 2, 2015

@Gitoffthelawn

Is there a test mechanism available to see if the claimed sandbox really works?

One can inspect traffic flowing out of a test machine using tools like Wireshark. I am not sure how it works with encrypted traffic though (apart from compromising the SUT or effecting a MITM). You probably need to get more help from other forums.

Auditing is a good way to contribute to open-source, and I don't think it takes away anything from the work of developers.


@gerv

I think using the word "leak" about your IP and your UA string is silly.

Indeed; the context matters. Two parties interact -> probably not a leak. Third-party gets to see it -> most definitely a leak. Especially the UA string, which in today's world of long UA strings, diversity of hardware and software, and machine intelligence, is a very good predictor of user identity.

These are things you send to every website you visit, and you send them to Google specifically when you visit 50%+ of the websites in the world.

Which is why there are huge privacy concerns being raised about it, and there are people trying to mitigate this. Tor is a solution, as you rightly pointed out, and it is on the extreme end of the spectrum, as you rightly pointed out as well.

This repository is about one of the other options. Extensions like umatrix also help cut down the third-party traffic.

@gerv
Copy link
Author

gerv commented Aug 2, 2015

" Especially the UA string, which in today's world of long UA strings, diversity of hardware and software, and machine intelligence, is a very good predictor of user identity."

You say that with such confidence; but all browsers don't have the same approach to UA strings. We've been slowly reducing the entropy in ours over the last few years, by doing things such as fixing the build date to a constant value, removing the language code, reducing the OS information, and so on. Compare our strings with those generated by Safari, for example.

Here's the current Firefox UA string for a release build on Ubuntu Linux 14.04 LTS:

Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0
FIXED LINUX 64-bit VERSION FIXED VERSION

So you find out I'm a 64-bit Linux user with Firefox 41. My OS is relatively unusual, but there are still millions of people with that UA. No "machine intelligence" is going to be able to identify me from that UA.

Another question is: who is this advice aimed at? If it's at the average user, or even the average privacy-conscious user, I'd say that telling them to turn off Safe Browsing with no alternative service is absolutely doing them a privacy disservice. They will not thank you for "preserving their privacy" when their machine gets rooted and all their personal data stolen by a site which Safe Browsing would have blocked. Just like anti-virus is an absolute essential for the average user's Windows box, a safe browsing service is an absolute essential for the average user's browser.

We have engineered the Safe Browsing service to be as privacy-preserving as possible, jumping through loads of hoops, and even (IIRC) getting Google to re-engineer bits of it. If you have constructive suggestions for how to make it even more privacy-preserving while still allowing it to run at all, then why not file a bug with your idea? Anyone can throw popcorn from the sidelines.

@Gitoffthelawn
Copy link

@gerv, can you take it down a notch? This is a fine place to honestly discuss issues, but unfortunately your tone is not conducive to calm discussion.

Writing to posters here with phrases like "So you think", "You say that with such confidence", and "is silly" are not constructive. Comments like "Anyone can throw popcorn from the sidelines." are counterproductive.

Maybe dial it back a bit?

Your suggestion to file bug reports on Mozilla is in many ways a great idea, although may not be a good use of time. Bug reports, when read and acted upon, are a great way to help develop a project, especially an open-source one.

Unfortunately, there are thousands of bug reports on Bugzilla, many of them years old, which have no indication that anyone has even read them. They are listed on Bugzilla as "untriaged" or have no response years after being filed. Personally, I've stopped filing regular new bug reports given the number of "untriaged" bug reports I have already filed. On occasion, I'll still file one, but it usually feels like bug reports land on deaf ears.

@Gitoffthelawn
Copy link

The Google cookies that are created by Firefox's Safe Browsing functionality are displayed in the Firefox Settings UI just like any other cookies. There is no indication to the user that they are somehow sandboxed, if that is the case. Outside a bug report, I have not found any documentation from Mozilla stating that those cookies are not available to other Google products. In order for those cookies to be sandboxed, Firefox would have to store two different sets of Google cookies. To be open and transparent, Firefox would have to show both sets of cookies within the Privacy UI. I'm not saying they aren't sandboxed, only that the Google SB cookies look just like every other cookie.

The claim that "you send [information] to Google specifically when you visit 50%+ of the websites in the world" is not accurate. Only people who lack the knowledge, skills, or interest send information to Google. That is certainly a majority of people, but not everyone. Many people block all connections to Google. This can be accomplished in a myriad of ways, including firewalls, routers, iptables, HOSTS, proxies, dynamic replacement libraries, and content blockers. Many people even use Android devices without ever touching Google.

@gerv
Copy link
Author

gerv commented Aug 3, 2015

It's a little rich for you ask me to take it down a notch; everything I've said, based upon my knowledge of Mozilla and my own checking, has been met with a quite unwarranted level of suspicion. You're not dealing with Apple here, you know.

My point about filing bug reports is that if you can't think of a more privacy-preserving way to provide this functionality, then you should either a) make the case that it's not necessary for the average user, or b) accept that the average user should keep it turned on, and remove it from the list. As it is, you are encouraging users to do something which may well be deeply harmful to their privacy.

We seem to be arguing about one small part of this PR. Does that mean that the other changes are acceptable?

@gerv
Copy link
Author

gerv commented Aug 3, 2015

If anyone needs to be further convinced that the cookies are sandboxed, read the bug where the feature was implemented - https://bugzilla.mozilla.org/show_bug.cgi?id=897516 . (It's linked from the bug mentioned above.) Cookies can be separated by App ID, and there's a special App ID of UINT_MAX - 1 for the safe browsing service. I assume (but have not checked explicitly, but it makes sense) that the reason the cookies show up in the cookie manager just like other cookies is because it's a manager for all your cookies, and if they didn't show up there, you wouldn't be able to delete them. (You do want to be able to delete them, right?)

Unless someone can show me an HTTP request to a non-safebrowsing service where the safebrowsing cookies are sent, or a request to the safebrowsing service where the non-safebrowsing cookies are sent (i.e. that there's a bug in the patch), can we all accept that this change did what it says on the tin, and that the safebrowsing cookies are indeed isolated from the main cookie jar?

Forgive me if this sounds frustrated, but if you want to know what the software does, and you won't accept the word of the developers, then why not read the code instead of guessing? That's the advantage of open source.

@ghost
Copy link

ghost commented Aug 3, 2015

why not read the code instead of guessing?

Sure, let me just start going through 174MB of source code. See you in 2000 years!

@gerv
Copy link
Author

gerv commented Aug 3, 2015

There are Bugzilla bugs listed in this PR, which have patches attached, which show you the place in the code to look for the changes in question.

@Gitoffthelawn
Copy link

@gerv I stopped reading after your first words: "It's a little rich for you..."

@todeale
Copy link

todeale commented Jul 16, 2016

Hi! I'm learning a lot from you guys (you look to be really experimented hackers :D ).

I'm new on github and actually a newbie in software engineering...
Open source is great! and so... :D

Humm ok! Sorry! Seems like this is not the right place to discuss about that...

Anyway i''m looking forward to become a kacker.. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants