I would have hoped and expected for them all to have been fixed. I don’t own a Mozilla account so can’t even read details about the issues. Do you think any are worth worrying about?
Please don’t regurgitate this nonsense. It is found in every mozilla-hating troll’s rants, and it looks like you’ve just copypasted this from elsewhere and read falsely into it all. I’m not saying that user’s don’t get upset by change, or misunderstand things, or that all these issues can’t be discussed - I’m just saying they need to be put into context and discussed with all relevant information
I’m going to address each one briefly in generalized terms (this is all from memory, I do not have the time to look things up just for this), and hopefully enlighten you. First of all, before you criticize someone, walk a mile in their shoes … then criticize them because, one: you’ll be a mile away, and two: you’'ll have their shoes. Jokes aside, you should have all the information and view it from the other perspective. Do you have all the decision making info that Mozilla had? Mozilla don’t make changes based on whims. We don’t have to always agree with what Mozilla does, but we should respect, and trust, the process. This is from a Tor Browser (TB) user’s hat, even as a Firefox (FF) user, and with my foresight and knowledge.
Pocket
not listed, but pocket does nothing unless you sign up for it. TB removes the icons. Activity Stream (where recommended pocket stories links end up) is not used by TB, and in FF you can disable them from settings. I’m not entirely sure on the privacy, I think pocket make share anonymized hit rates on stories - certainly no PII.
Mr. Robot
December 2017 … this was over FIVE years ago. Not saying it was a good look… this was an internal issue where safeguards/checks/common-sense was lacking. Because of that incident, safeguards and protocols have been put in place - such as signoffs from a select few people, forms to be filled in, etc. As for FF, telemetry and being able to push experiments via normandy is perfectly fine and normal - chrome also pushes A/B testing. You can always opt out. For TB, none of this matters, as it is disabled and remote calls nixed - it does not make sense in the TB world anyway. Anyway, over FIVE years later, nothing like it has happened again at FF (because protocols, safeguards are in place) and nothing like it can ever happen in TB. So beating a 5+ year old drum is not very productive or indicative of today
Promotes Cloudflare
I am not a networking (or tor protocol) engineer. DoH is not some great evil. It can improve privacy/security - see the EFF article, I’m sure you can search for it. In order to roll it out (and only three countries have been, and it has been widely received as a positive thing, not negative, in those countries), Firefox needed a partner (or two) - IIRC they signed agreements with privacy respecting clauses for users. Users could also choose their own providers. And when rolling it out, users had a say - i.e they were notified and could choose to not use DoH (I do not remember if it was opt-out). Ignoring all that and I’m not going to debate it - the answer you are looking for here, is that it does not matter for TB which handles networking and DNS differently.
Inferior fingerprinting protection and other leaks
let me just stop you right there. The FP protection afforded by RFP and especially in Tor Browser with some additional patches and a large crowd … is world leading (three letter agencies basically said it was game over years ago - they could couldn’t do it [edited typo]), so let’s not make wide general misleading statements. Now as for extension UUIDs - Mozilla’s solution could be argued as superior - as least it doesn’t leak on all extensions on demand, and vetted/good extensions don’t leak anything at all. That said, leaking a unique ID (for your ext install) is worse than leaking the generic ext one. Either way, it’s not great (blink or gecko), but in TB we do not leak NoScript (nor uBO in Tails), and we do not recommend adding any other extensions
old extensions
XUL had to go. It was preventing multiple process, hindering changes and causing progress bottlenecks (I wish I could find the link about how a single code change had to wait a year to get added, tested, finalized due to legacy extensions). And from a security perspective, it was essential it had to go. Nothing of value was lost except perhaps some APIs that helped workflow (not a privacy issue). None of this has anything to do with Tor Browser (except the security part and good riddence to XUL).
addon-aggeddon 2
Not great. Especially since it was the second time. It’s complex as to why it happened, a post-mortem was conducted, extra safeguards and documentation put into place IIRC. The other thing to come from this was that Mozilla were able to push via a mechanism, a fix to users without updating. This method has been hardened and can be used again in future (FYI: it is not possible to use this on TB) - it has never been used since (let alone abused), and again, must go strict procedures. I’m sure you can google the mozilla results of the post-mortem write up, I think by eka (eric rescorla, CTO)
Breaking css UI customization features
userchrome … css tweaks are not officially supported, and this has nothing to do with TB or privacy or security
about:config
how much time do you need to spend in about:config. No one cares about sorting and filtering - unless you are an expert or knowledgeable in these things, you shouldn’t be in there. And if you are, they you know what you’re looking for.
about:config was removed on stable android because geckoview (android) is quite different to gecko (desktop). Users could easily break their profile/app, and on android there is no easy way to recover it. This is a safety feature for FF’s target audience. If you require about:config you can use other builds such as nightly. On TBA (TB Android), about:config is not blocked.
compact mode has nothing to do with privacy/security. Are you a UX expert? Your preference is not necessarily the main one. Code complexity and overhead is a real thing. Mozilla runs on limited funds and do amazing things with a 20+yr old spaghettified code base - at this point with rust, servo like css, warp, e10s, removal of XUL, adding the new web ext, manifest 3, stencil, a unified look & feel, and other reworked components, that they have probably rewritten half of it - that’s 10’s of millions of lines of code. If they chose to remove compact mode, deal with it. It’s not actually removed, and you can always use userchrome.css. Can you do that in blink?
poor security
once mozilla shook off XUL, and sped up the browser (quantum) and were able to quickly rewrite large parts of it (css is in rust from servo) they achieved fission in approximately 3 years. It took blink almost 8 (but I’m sure they had a different time pressure). I am not a security specialist, but madaidan keeps moving the goalposts IMO. He says the rust implementations are not in places that matter (they have made a difference in security bugs, I wish I could find the paper) so -1 for FF, but that chromium will start using it too so +1 for chromium. Do you see how biased that is. For a long time FF didn;t have fission, so that was a point against it (in his post). Now it does, but wait it’s not quite as strong as chromium’s, so that’s still a point against it. See the bias yet? I am not arguing about his points - what I am saying is that cherry picking points and enumerating them is not how you measure security. It is a many layered thing and hard to measure. Trying to compare two entirely different and very complex browsers is an fool’s errand.
performance
has nothing to do with privacy or security. Ignoring the fact that the browsers mentioned are over a year old. IMO this is mostly a load of nonsense and usually anecdotal. Perf only matters in perception and in real world cases. Fore sure, there are areas where chrome really shines vs firefox. But there are also areas where FF kicks ass - for example, ever tried to measure the reflow on a page with lots of characters (thus causing lots of fonts to be used) - in Firefox it takes milliseconds, on blink it takes many seconds - that there is due to css written in Rust (AFAICK). Try it - scripts - load in FF and it’s almost instantly shown, load in blink and it says … waiting for reflow for ages.
what does make a difference for FF users, is blocking bloated ad nonsense, and cross party rubbish (e.g. uBO). And for most browsers and most webpages, the differences between FF vs blink is not measurable to humans. For TB, the issue is latency in tor, not browser perf.
to answer the first part. Search suggestions are opt in on Firefox IIRC, and these things are removed in TB anyway, if they use remote calls or have any privacy concerns. They are also configurable in the Settings. Nothing to see, move along.
–
final word: all companies make mistakes (even if they are only optics and not privacy ones such as Mr Robot), it’s how they deal with it and fix it and future-proof it that matters. Sorry if my answer/tone comes across as a bit harsh, but just throwing out large spurious lists of concerns in a single thread is not how it works in my world (and comes across as naive at best, deliberate at worse). I’m not going to debate any of my points - so don’t ask me about them.