Firefox 85 for Android released with DRM stream support and usability improvements
Mozilla released Firefox 85.0 Stable for all supported desktop operating systems last week. Firefox 85 is the first stable version of Firefox without Flash support, and Mozilla did add a number of usability features to give users better control over certain areas of the browser.
Firefox 85.0 Android is now available as well. The new version of Firefox for Android is already available via Google Play and may be pushed to user devices via the built-in updating functionality. A tap on Menu > Settings > About Firefox displays the installed version on the device.
The official release notes of Firefox 85.0 for Android lack information; the only changes listed on the official page are support for network partitioning, a feature that improves privacy, and security fixes. The Firefox 85 Security Advisory Page lists a total of 13 different vulnerabilities. The highest severity rating is high, the second-highest after critical.
Firefox 85.0 for Android includes capabilities to play DRM-protected media on sites such as Netflix or Amazon Prime. The browser uses Google Widevine and displays a prompt when a site attempts to play DRM protected media by default.
Firefox users may change the default behavior under Menu > Settings > Site permissions. The preference DRM-controlled content supports "allowed" and "blocked" besides the default "ask to allow". Blocked will block any requests outright, allow permits it without user interaction.
The latest version for Android includes a bunch of usability improvements:
- Sites added to a Collection will be loaded when they are opened. Previously, Firefox loaded the content from cache but that was problematic for sites with content that changes regularly as old content might be displayed when opened from a Collection link.
- Memory optimizations designed to reduce or eliminate the unwanted effect that sites are reloaded when users switch between tabs in the browser.
- Top sites can be selected directly, the extra click is no longer required.
- Supported extensions can be installed from Mozilla's official add-ons website.
Work on the new version of Firefox for Android continues. The addition of DRM-media playback closes a gap between Firefox and other browsers such as Google Chrome; users who don't want it can set its preference to block to do so. (via SÃ¶ren Hentzschel)
“Top sites can be selected directly, the extra click is no longer required.”
This makes a massive difference to usability, happy they fixed it!
// Memory optimizations designed to reduce or eliminate the unwanted effect that sites are reloaded when users switch between tabs in the browser.
I hated this, I’m happy they fixed it as well.
The DRM module is a closed source component that is quietly being shipped even with open source browsers. That is not only the case in Firefox, but also in other browsers like Brave. I understand the necessity to support it in general as users expect commercial streaming services to work in their browsers, but the module should really be open source as to make its inner workings transparent. A closed source model to be shipped with all major browsers was agreed upon by Google, Apple, and Mozilla years ago – doesn’t mean it’s good or should be so. Please understand that a DRM module could be completely open source – all that needs are private decryption keys!
I don’t understand how more useful implementations like the one proposed by the Fraunhofer Institute were completely ignored:
This guy speaks the truth, though it’s not limited to Mozilla:
The DRM module also causes privacy issues, e.g. Reddit uses it for fingerprinting users:
Reddit doesn’t even need DRM, it just gets abused for privacy violations there.
My advice to people would be NOT to use commercial streaming services in their web browsers, if they can help it. There are dedicated apps for most streaming services, use those instead of introducing a blackbox into your browser which can be abused for privacy breaches! If you use streaming services outside of your browser, disable DRM:
– In Brave, the Widevine DRM module can be disabled under brave://settings/extensions (Vivaldi has the same setting in the “Webpages” section of its preferences, just so you know)
– In Firefox, you can disable DRM-protected content under about:preferences#general and you should also disable the “Primetime” and / or “Widevine” plugins under about:addons, by setting them to “Never activate”… There are also unbranded builds of FF which ship without the DRM modules altogether.
Do you reckon there might be all kinds of compatibility issues with the open-source DRM implementation? From my own and anecdotal experience, even Microsoft’s PlayReady DRM is causing some issues on sites like Netflix, so maybe it’s just really difficult to get something out that’s properly supported?
No, there wouldn’t be compatibility issues. The Fraunhofer Institute was careful to adhere to the W3C EME specification as it was. It really depends on what the websites expect – currently, they expect the closed source EME plugin that ships with most major browsers. If Google / Apple / Mozilla opted for an open source implementation, they would expect the open source implementation instead. The open source implementation can’t work now because that is not what websites have come to expect – that ship has sailed years ago. It’s really that simple.
The question is mute, though. The big browser developers have opted for the closed source blackbox and that also has consequences for more minor projects derived from them.
In Brave, would that be:
Ask when a site wants to install Widevine on your computer.”
And toggle it to the right?
The toggle behind Widevine should be white / greyish when it’s disabled, when it’s enabled it turns orange like this:
Leave it disabled if it is currently disabled – use separate apps apart from the browser for streaming. Cheers.
> The DRM module is a closed source component that is quietly being shipped even with open source browsers.
Widevine is shipped as part of Android itself. There is no closed source component for DRM in Firefox (or other Android browsers). With Firefox 85 Mozilla added the API integration.
> you should also disable
I don’t understand why anyone should do this. There are exactly zero reasons. Either you want to consume DRM protected content, then you have to allow it, or you don’t want, then you can ignore it.
> Widevine is shipped as part of Android itself. There is no closed source component for DRM in Firefox (or other Android browsers).
My comment is not solely related to Android.
> I donâ€™t understand why anyone should do this. There are exactly zero reasons.
> Either you want to consume DRM protected content, then you have to allow it, or you donâ€™t want, then you can ignore it.
You do realize that there are separate apps for the streaming services, right? Both on desktop and on Android.
It’s funny to see for them DRM are more important than Extension in the browser.
Theirs priority isn’t the same as the user, result, mozilla dig it’s own grave.
@Iron Heart Just wanted to say I recently started testing Brave on Android and one thing I cannot figure out is how to globally set fingerprinting to strict. Any idea?
The “strict” form of their fingerprinting protections is not supported on Android currently. Please note that I can only lend limited support for Brave on Android, because it is not my main browser on Android (I use Kiwi and Bromite as my main browsers there), so I am at times unaware of developments happening or not happening on that platform for Brave.
I’m currently running Bromite on Android, are there any benefits of having Kiwi too?
> Iâ€™m currently running Bromite on Android, are there any benefits of having Kiwi too?
Yeah, Kiwi supports all extensions from the Chrome Web Store – it has full desktop Chromium extension support. I am running all the extensions I am running on the desktop there (uBlock Origin, LocalCDN, ClearURLs, Cookie AutoDelete, HTTPS Everywhere – HTTPS Everywhere isn’t needed in Brave on the desktop as the browser has this functionality natively, but it is good to have in Kiwi). Kiwi comes in handy if you need any extension on the go. Kiwi + uBlock Origin provides stronger adblocking capabilities than Bromite with its internal adblocker. Some of the stuff Bromite does (like the aforementioned adblocking) can be replicated in Kiwi via extension, however, Bromite has a much more privacy-conscious and stronger default configuration:
In Chromium, there is no about:config, so you have to use a browser that was sufficiently hardened by the developer in order to achieve privacy, and with the exception of extension support, Bromite is basically perfect. Kiwi without any extensions is nothing to write home about and worse than Bromite – so if you don’t plan on using extensions, Bromite is best.
Thanks, on my my mobile, I don’t really have a need for extra extensions, so I will just stick with Bromite. Out of curiosity, which of your listed extension’s functions is Bromite handling behind the scenes (if any)
> Out of curiosity, which of your listed extensionâ€™s functions is Bromite handling behind the scenes (if any)
Bromite only handles what uBlock Origin does, basically. It doesn’t:
– automatically upgrade connections to HTTPS when available (HTTPS Everywhere)
– replace libraries fetched from CDNs with local copies of said libraries (LocalCDN)
– filter tracking elements from URLs (ClearURLs)
– delete cookies and other local data upon tab close or domain change (Cookie AutoDelete, though one can set Bromite to delete cookies and cache upon closing the browser – but it’s not the same thing)
However, one needs to understand that there are two aspects of browser privacy, basically:
– How much hardened the base browser is internally – Bromite wins here hands down, no contest. See the link I’ve posted for reference.
– The extensions you use to further improve your privacy – Bromite loses here, because it doesn’t support extensions.
Kiwi, the base browser, is less privacy-conscious than Bromite, but the extensions I run in it do things which I can’t replicate in Bromite. On the other hand, I can’t replicate the hardening of Bromite itself (the base browser), in Kiwi. An optimal scenario would be a hardened browser that also supports all extensions. Extensions do unique things, but Bromite’s internal hardening also makes it unique, those are totally different aspects of privacy and cover different bases, there is no direct way to compare here.
Without extensions: Bromite >>>>>>>>> Kiwi, not even a contest.
@Iron Heart: I understand your point regarding your preference to use a first-party app for a streaming video site or service rather than a web browser.
However, on the other side of the equation is that a user loses control of the experience an app provides and it becomes entirely in the hands of the provider, whereas on a good browser the user can put mitigations in place.
For example, the YouTube app almost certainly includes advertisements (At minimum video ads when video is played, I’d imagine), whereas watching YouTube in a browser with either extensions or a built-in content blocker would allow those users who choose to do so to block ads. There is even a specialized extension for some browsers that attempts to block sponsored content (i.e. When a YouTube video with someone talking has the person do a personalized pitched that is indistinguishable from the program).
Another example would be when you want to listen to the audio from a YouTube video while doing something else with your phone or tablet. Last I checked (Which was admittedly years ago), the official YouTube app forced users to actively have the browser and the specific browser tab in the foreground to hear audio, not allowing one to switch to other tabs or other apps while continuing to listen to their video. In addition to being an annoyance to people, arguably this could have been Google attempting to leverage people into buying their paid subscription production.
“Video Background Play Fix”, available for some Android browsers (Off the top of my head Iceraven, which I know because I use it, but probably some other browsers as well), fixes the above issue, and there may be some browsers which do not have that specific extension available that provide built-in options or alternative extensions to deal with the same issue.
There is not only the issue of an app forcing it’s preferred way of experiencing it’s content at you in ways you could alter for a better user experience with the right browser as a current thing or a future thing in the landscape we have today, but also that the more people use apps and the fewer browser support the native web experience, the less a provider will fill the need to even made content available via the web. If the content stops being available on the web at all, the app will have carte blanche to do whatever they want without even the implicit check of “Okay, if we do x, more of our users may switch to viewing our content through a web browser which not only can block x, but also y and z. So, let’s not get too over the top here.”.
Apps can also come with unwanted permissions requirements that the right web browser with the right extensions or settings *may* not replicate, thus affording more user privacy in that respect, even if a tradeoff exists where it could afford less user privacy in other respects.
Of course, there may be unofficial third-party apps through places like F-Droid available for some sites, but, even so, I think there is a solid case for web browsers, even on mobile, to support video content.
There is also a usage scenario where someone is browsing news articles on, say, CNN, and sees a short embedded video they wish to view on rare occasions. Having a separate app to do that and then having to look up the video in the app may not be an ideal user experience for that user relative to simply clicking and watching within the browser. In fact, some of these sites where video is not the primary or even secondary mode of content may not have an app with video support, or have an app at all.
Correcting my own post:
Last I checked (Which was admittedly years ago), the “free” version of the official YouTube app forced users to actively have the app in the foreground to hear audio, not allowing one to switch to other apps while continuing to listen to their video. Similarly, the default behavior of YouTube in Chrome (Again, last I checked) doesn’t allow users to switch apps or even tabs if they want their video audio to continue to play in the background.
[Then I go on to describe one way of mitigating this by viewing YouTube in browsers with the right certain extensions and/or features]
I’ve read your comment, and I agree with some points, but not with others. I’ll elaborate a bit:
I am not against browsers supporting video content – that’s a basic feature of all browsers and it’s hard to fathom today’s web without it. The DRM component is not required for freely available video content on e.g. YouTube (there is also paid content on there that might require it, though) or CNN. DRM is used in benign ways by commercial(!) streaming services as a form of copy protection / anti-piracy measure. However, and sadly enough, there are also bad faith adversaries like Reddit which misuse the presence of the DRM plugin as a fingerprinting vector, even though DRM wasn’t required for any content on that website. Having such a blackbox in the browser was a bad idea when it was first introduced, and it is still a bad idea today – because not only companies which strictly require DRM for their content take an interest in the DRM plugin, you see.
I agree with you that being fully reliant on apps would give the streaming platforms more leverage, but I am not worried about this for a reason: The privacy-conscious are a minority, there will always be a sizable number of people consuming content in-browser, I don’t think we need to worry about that “second option” going away. Again, DRM is mostly used for a reason, but the privacy-aware must also consider the fact that others have no qualms when it comes to misusing said plugin.
If a certain app does not meet your expectations, there is the browser of course, but one can’t have it both ways: If we allow DRM into browsers, bad faith actors can use it as a fingerprinting vector, however, it might enhance our convenience or user experience in other areas. We can’t have it both ways and need to make a choice here – I don’t blame anyone if that choice is allowing DRM in the browser, each one of us has his / her own use case and there is little room for criticism here. I am just hinting at potential dangers, and those are not necessarily related to the streaming platforms themselves, but rather to bad faith adversaries like Reddit.
What you say about permissions is interesting, if a streaming app indeed requires even more permissions than a browser, we might be running into a net loss of privacy… However, we need to qualify this and consider the following: A browser, by nature, requires a lot of permissions, because it does a lot of stuff. For example, it requires access to the file system for downloads (write) and in case a file is opened in the browser (read), it requires access to camera and microphone (video chats), it requires access to location (navigation and route planning in browsers is a benign use case) and so on and so forth… The likelihood of a streaming app requiring the same amount of permissions is low, IMHO, because it just doesn’t do that many things. For example, it would be very odd for a streaming app to require camera access – if it asks for it, I would be worried. Point is, video streaming apps oftentimes do not require as many permissions as browsers, and there is also overlap here.
Then, one needs to understand why a permission is being requested. I’ve had funny discussions regarding that on gHacks already; one example: A browser will usually request read / write access for your entire file system, reason being supported file types that can be opened in the browser (read) and downloads (write), as I mentioned above. But this permission leads some people to come to erroneous conclusions, for example: “The browser has read access to all my files! It collects info about those and sends them back to the browser vendor!”
I really have to debate such cases, people assume that access to the file system means that the browser takes an interest in their files (data collection), when the reason is actually benign.
Don’t get me wrong, though, a browser could totally collect file metadata, but you need to prove that separately, pointing to some developer or user discussion or support ticket, for example. Pointing at the permission alone is not enough to justify such a conclusion if there are also benign reasons for the permission. This is why I am extremely wary about discussing permissions, because users rarely see the benign reasons for a permission, and assume the worst, of course without presenting any kind of evidence for the worst case. In conclusion, we need to stay vigilant here and should always question permissions, especially odd ones for the type of app in question (like camera access for a streaming app), but we should search for possible benign reasons first and keep in mind that especially browsers will require almost all permissions by nature.
PS: You mentioned YouTube and the subpar user experience with it – there is a solution for this, it’s called YouTube Vanced: https://vancedapp.com/ Removes ads from the videos and also allows background playback of videos. Comes with the SponsorBlock extension (the one that skips promotional material in videos) built-in. You might have to allow apps from other sources on your phone before you can install it: https://www.wikihow.com/Allow-Apps-from-Unknown-Sources-on-Android
2nd PS: I am aware of the fact that such a “fixed” version is not available for all streaming apps and your concerns about app usability are certainly justified in such cases, but when such a “fixed” app is available, as is the case with YouTube, I think we should use it. :)
Oh, so that’s why arkenshill, formerly the ghacks user.js, decided to enable DRM by default today. Funny that he made no mention of that Mozilla decision in his motivations. The last nail in the coffin, or is there room for more ? We won’t miss you anyway.
*she, at least according to my info.
Anyway, the decision wether to enable or disable DRM has to keep usability in mind. That is, users expect commercial streaming services to work in their browsers. If you disable DRM, those do not work. However, she also says:
> This has absolutely nothing to do with RFP.
source: https://github.com/arkenfox/user.js/issues/1107#issuecomment-770819681 (already have made a screenshot, just in case)
DRM has nothing to do with fingerprinting protections? I beg to differ, point in case:
Enabling DRM makes you more fingerprintable (Reddit actively uses this), and therefore it shouldn’t be enabled by privacy-conscious users (if the fact that the module is a complete blackbox isn’t enough of a reason already). However, I tend to agree that DRM being enabled is what the majority of users would expect, hence why one shouldn’t turn it off if minimizing breakage / unexpected behavior is the goal. That being said, a privacy-conscious user.js should at least hint(!) at the fact that using dedicated streaming apps outside of the browser would be the better idea, as that would make it possible to disable the blackbox in the browser itself. Depending on how much hardening is intended, one could even make a case for disabling DRM entirely in such a script (as it was there, too, until today).
* Removed [Editor: offtopic]
first of all, thanks guys for the shoutout
– is that the best you can come up with? it’s very telling . Please show me where uninvited and unprompted and out of the blue I have consistently promoted Firefox or arkenfox user.js – I say consistently, because I am sure there may be a couple of times I have linked to it when answering someone or trying to add value in a thread, and you’ll misconstrue that
–  Psychological projection or projection bias is a psychological defense mechanism where a person subconsciously denies his or her own attributes, thoughts, and emotions, which are then ascribed to the outside world, usually to other people
thirdly, the user.js has not enabled DRM by default: the issue is a discussion on whether or not to alter the default setting in the template
fourthly, as the user.js points out (and IH above) that there is a usability tradeoff. The user.js is a template: everyone will have different threat-risk models, and users are expected to tweak to suit their needs: no matter what the default is, not everyone will be be happy: it’s about finding a balance
and lastly, Iron Heart once again totally misunderstanding/misrepresenting everything
– “This has absolutely nothing to do with RFP” – this is 100% true. RFP does nothing to mitigate DRM or DRM fingerprinting. What I said was in direct response to someone else who tried to use the argument (linked) that I stated in a different issue about RFP + font fingerprinting protections vs using a preference: namely that RFP fingerprinting protections shouldn’t be interfered with, otherwise you lose that protection. Since DRM is not part of RFP, then that argument doesn’t hold.
– “(as it was there, too, until today)” – it still is. Please learn to fact check
– “That being said, a privacy-conscious user.js should at least hint” – it already has mechanisms in place, please learn to read what a template, readme, wiki, instructions and setup tags are. And, when/if the prefs are made inactive by default, the changes may indeed provide more than just adding a harden tag
On a semi-side note, please tell me what the fingerprinting of DRM reveals when not playing an actual video (besides whether or not it is enabled). I’ll make it easy for you .. take the reddit script and let me know the metrics gained and how much entropy they contain. Looking forward to your detailed breakdown
Please, stop the misdirection. Yes, DRM is not part of, or covered by, the privacy.resistFingerprinting flag, but the module itself is fingerprintable and therefore falls under the entire “anti-fingerprinting” umbrella. Enabling it makes fingerprinting easier;
> it still is. Please learn to fact check
This issue of yours attempts to change that, and was created today:
I didn’t say that you already altered it in the user.js itself – if you did, that would be even worse than mere considerations.
> it already has mechanisms in place, please learn to read what a template, readme, wiki, instructions and setup tags are.
Nowhere do you hint in there that users should use streaming apps outside of the browser – the only reasonable reaction to a fingerprintable blackbox in the browser.
Leave me alone with all that “template” talk – you offer a preconfigured config file that is meant to be halfway workable at least; otherwise, why would you even consider enabling DRM by default for usability reasons? Those are usability considerations are contradicting your “template” claim. Not all recommendations on a “template” (= recommendation list users can selectively choose from) must be workable (however, those on a preconfigured config must be workable – hence usability considerations), a “template” would also provide extensive reasoning why a certain change was made and what alternatives are reasonable etc.
> Iâ€™ll make it easy for you .. take the reddit script and let me know the metrics gained and how much entropy they contain. Looking forward to your detailed breakdown
It checks for the following things:
– If DRM modules are available at all, whether it’s enabled or disabled.
– What type of DRM module it is.
DRM is just one possible fingerprinting vector, so one CANNOT identify a user JUST based on DRM. However, DRM is a further identifier on a list of identifiers that together form the fingerprint – you know that, those are the basics. Why would you allow yet another identifier?
* Removed [Editor: no need to start yet another war in the comment section]
PS: I am waiting for your user.js to to resolve the fact that Firefox still connects to firefox.settings.services.mozilla.com even if your user.js is fully applied – please resolve. By the way, there is no about:config flag for that, so good luck modifying the code.
> I didnâ€™t say that you already altered it in the user.js itself
You did: quote (last two caps mine): “disabling DRM entirely in such a script… as it WAS there, too, UNTIL today”. You can’t even fact check yourself in your haste to try and discredit people
> It checks for the following things: â€“ If DRM modules are available at all, whether itâ€™s enabled or disabled. â€“ What type of DRM module it is.
And how does that apply to Firefox, please do enlighten. What are all the possible outcomes of the reddit script in Firefox? What is the entropy? At least try to answer the original question fully.
> Why would you allow yet another identifier
The identifier exists regardless
* Removed [Editor: reference to removed comment by IH]
OK, apparently I have said that you altered the user.js. I can’t remember making any such assertion, not least because I’ve explicitly pointed to a GitHub issue that is clearly still in progress, but anyway, if you say so, I have clearly asserted it. No way around it.
> The identifier exists regardless
Whether or not DRM is active exists can be identified, but there is also the type of plugin, and in the future possibly version numbers:
Good luck to your users thinking that your script is a best effort defense against fingerprinting, now and in the future. You will sa
* Removed [Editor: offtopic]
> What is the connection for?
Related to Firefox Experiments:
> Why is the connection bad?
FF Experiments are basically a backdoor, any connection related to it is clearly non-benign and not required for Firefox to be operational, nor can it be traced back to any user action = unsolicited request.
> Where does it say anywhere that all connections must be blocked/stopped? Donâ€™t answer, itâ€™s rhetorical.
All connections that are not strictly required for Firefox to operate correctly, and can’t be traced back to any user action, must be stopped as unsolicited requests – that is, if you care about unsolicited requests (a privacy guy should).
What part about “Donâ€™t answer, itâ€™s rhetorical” do you not understand? You have
– incorrectly claimed I changed the user.js
– insinuated that I think DRM is not fingerprintable
– incorrectly claimed I copy everything from Tor Browser
– created off topic noise making a number of incorrect claims about the user.js
Your reply about the user.js and your claimed connection is BS. The user.js explicitly says it is for desktop only, not android. Firefox experiments are completely disabled.
The burden of proof is on you. Please provide proof that a brand new desktop vanilla Firefox profile with the user.js
– 1. connects to firefox.settings.services.mozilla.com (not saying it does or doesn’t: I just want you to prove it)
– 2. what exactly is the nature and reason for that connection: i.e. conclusively prove what functionality is using this
– 3. prove that the functionality for it is actually a privacy concern
If you can’t provide that proof, then I suggest you stop talking
DRM fingerprinting. Firefox only supports widevine. So the only results you will get (for now) are binary: i.e if the DRM is on then widevine is available, otherwise it’s the opposite. When/if more CDMs are added, then it gets reassessed (if DRM is enabled). This is why fingerprinting here wasn’t even considered. Not to mention that since it triggers prompts (at least on Firefox), it probably won’t be used in the wild (my understanding is the reddit one was an A/B test). Additionally, Firefox shows a DRM icon in the urlbar, so it’s not likely to go unnoticed even by those with DRM enabled. The FP risk here is negligible to none. If anything, enabling DRM would be the right answer IF the question was fingerprinting.
But fingerprinting isn’t the question, it’s not even considered. The issue was about looking at the *default* value in the user.js for usability. The major consideration is the threat outlined in the EFF link. And just like in any review/reminder: always look at better explanations, sources, references, etc. Now I’m not an expert on DRM itself and what could happen when you play a DRM video for example, but it is a reasonable assumption to consider this threat differently for say Tor Browser users vs Firefox users in terms of expectations and usability out of the box (as you have already said).
Like this one: https://github.com/arkenfox/user.js/commit/ac52886ea8c54f2bee386456459c1d34c09cf265
– where more information was added as to why you might want to keep WASM disabled
The user.js is a live document for a product that is constantly changing for a tech that is ever-evolving. It’s always under review and can always being improved within reason (balancing simple and short vs comprehensive etc). Thanks for the reminder to suggest alternatives for those who would consider enabling DRM permanently
So after all that, I just don’t get why you decided to jump on someone else’s silly (and incorrect) comment about nothing important … and end up digging yourself into this situation of being argumentative, doubling down, making personal attacks, and all your old tricks. It’s your nature.
> incorrectly claimed I changed the user.js
I didn’t, don’t put words in my mouth. I explicitly pointed to an issue that is obviously, and for all to see, still in progress. If I wanted to nefariously insinuate that you changed the user.js already, I wouldn’t have done so. Not even primary school pupil could possibly misunderstand that wording, but you can. Why do you always put words in my mouth? It gets old.
> insinuated that I think DRM is not fingerprintable
Literally where did I do that? I said that you are introducing a fingerprinting vector (objectively true), not more and not less.
> incorrectly claimed I copy everything from Tor Browser
> created off topic noise making a number of incorrect claims about the user.js
> connects to firefox.settings.services.mozilla.com (not saying it does or doesnâ€™t: I just want you to prove it)
I shouldn’t have to tell you how the browser YOU claim expertise for operates on the most basic level: Go to about:networking, check the connections it establishes there, with a vanilla profile and with your user.js. Do it again after 5 – 10 minutes. It will connect to firefox.settings.services.mozilla.com sooner or later.
Arch Linux docs also mention it, by the way:
> what exactly is the nature and reason for that connection: i.e. conclusively prove what functionality is using this
Read it, understand it. It’s not limited to Android, either, but this document tells you what it does.
> prove that the functionality for it is actually a privacy concern
You have it the wrong way around: You need to prove to me that the user needs this connection for some benign reason, otherwise the connection is to be distrusted. It’s related to FF Experiments, so it is definitely counted among the unsolicited requests.
In more general terms, I do not exactly “need” to extensively prove anything here (I am sure you will quote this out of context in the future, but anyway) – Firefox is not anywhere close to my primary browser and I do not explicitly or implicitly claim expertise for it. You do claim such expertise, however, and so you should know the basic inner workings of the browser, how to verify such a claim, and how to do the research. Also note that gHacks comments are not scientific write-ups and don’t need to be. I see no reason to put in any more work into my comments than you do, just because you demand it. Why would I? It’s easy enough to verify, so go ahead. I’ve told you where you can find it.
What you say about DRM is likely about to change, considering that the module will, with all likelihood, be able to produce a version number akin to a user agent in the future, so the versioning might also become an issue. That is, if one even needs a reason to disable a complete blackbox in the browser!? You have zero idea what it does internally, it’s closed source. Neither have I, but I assume that it is reasonable to distrust a blackbox. Your assumption that a tiny icon in the address bar will be noticed by the user I leave without further comment – this is just ridiculous. You can’t count on users noticing something so minuscule unless they look at the UI all day (hint: nobody does).
> Itâ€™s your nature.
I didn’t know we knew each other so well, at least I didn’t perceive it that way.
> donâ€™t put words in my mouth
Quote IH: “as it was there, too, until today”
– you are directly claiming that the user.js was changed
> Literally where did I do that?
Quote IH: “This has absolutely nothing to do with RFP [quoting Pants]. source [link to github issue] DRM has nothing to do with fingerprinting protections? I beg to differ”
– you are directly saying that what I said is that DRM has nothing to do with fingerprinting
> Your assumption that a tiny icon in the address bar will be noticed by the user I leave without further comment â€“ this is just ridiculous
It will be noticed by some users, and that is hopefully enough to draw attention to it and cause outcry. It only takes one person. Potential backlash is at least some deterrence. That’s the point. Not that everyone will notice it. Grow up.
> the rest
You still can’t back up your claim. The burden of proof is on you, since you made the allegation. The short answer is you don’t actually know, and you can’t prove it. You’re making assumptions. You see an URL. You link to an a wiki about experiments which uses that URL. You link to a wiki that tells you about the URL being hard-coded in omni.ja. That doesn’t prove anything.
You’re claiming that the connection is for experiments. Experiments are disabled by the user.js. Your claim is BS.
I actually know the answer why, and it has nothing to do with experiments, and carries zero privacy risk (I’ll give you a hint: ASRouter). You do realize that the URL in question is used for many things, right? Oh, and those connections can be stopped via prefs: but it’s not a privacy issue you see.
I just wanted you to prove what you said, which you can’t: because it shows that you do not fact check and will just throw anything semi “plausible”, as noise, that you can find in order to try and discredit people or look smart or something.
Again, if I wanted to insinuate that the user.js was changed, I wouldn’t have pointed to a work in progress. You yourself should grow up. You seem to know better what I wanted to express than I myself do, don’t you think that notion is a bit too ridiculous even by your standards? Anyhow.
Your quote seemed like you were ignorant regarding the fingerprinting implications, that you were about to carelessly introduce a fingerprinting vector. And it still seems like that just based on your GitHub. Though you have clarified that you are not ignorant regarding that here.
> You still canâ€™t back up your claim.
Eh, wut? Are you serious? I literally told you where you can see the connection: about:networking
I pointed you to an explanation of what it does. It’s being discussed extensively here, too: https://groups.google.com/g/mozilla.support.firefox/c/O2Rswb1jBUw
Do you need even more proof? I don’t make that stuff up, others discuss it as well. Consequently, you should annoy these people as well, seems like they are somehow coming up with the same conspiracy theories like I am. Quick, before it’s too late!
> You link to an a wiki about experiments which uses that URL. You link to a wiki that tells you about the URL being hard-coded in omni.ja. That doesnâ€™t prove anything.
Pants, that it is related to Firefox Experiments in the first place already proves that is it non-essential. Firefox Experiments are, by definition, non-essential, therefore they are called “experiments”.
> Youâ€™re claiming that the connection is for experiments. Experiments are disabled by the user.js. Your claim is BS.
Your user.js disables Firefox Experiments and yet the connection is still being established. Anyone who takes a look at about:networking can confirm that, no point in denying it.
> Oh, and those connections can be stopped via prefs: but itâ€™s not a privacy issue you see.
There is no pref that can disable the connection to firefox.settings.services.mozilla.com !
Do you make an attempt at justifying unsolicited requests here? I mean, seriously? YOU need to prove that this connection, which undeniably exists and is being established regularly, is NEEDED.
Hint: The connection is NOT required for Firefox to be operational. Not in any way, shape, or form.
> that you can find in order to try and discredit people
Am I discrediting you by saying that you can’t stop the connection with some user.js file, as there is no preference for it? It can only be stopped at the code level, which I am sure won’t present any serious challenge for you, considering your proven coding skills. So good luck with that, I am watching out for results.
Stop spreading lies about the arkenfox user.js
> Your quote seemed like you were ignorant regarding the fingerprinting implications
Only to you. You were so eager to disparage me, you misread it or deliberately chose to misrepresent it. You quoted it with no context, failed to even follow what it referred to, ignored the fact I said RFP which is a specific thing in Firefox, and then directly insinuated a lie (oh, and took a screenshot as if it was some sort of gotcha moment). That’s pretty pathetic.
> Eh, wut? Are you serious?
Deadly serious. Your claim is 100% incorrect, and you still haven’t proven it (and you can’t). [side note: Also, why are you pointing to an almost four year thread of outdated information?] You were so eager to throw in more, off topic, noise in order to disparage the user.js, that you didn’t even fact check your own claim.
THE BIG LIE: You made the claim that the user.js does not block all connections (it’s not meant to) because it connects to the services domain, etc. claiming that it’s a privacy issue and insinuating that the user fails in this task. And I asked you to show me **what** purpose those connections you see are for and why it is a privacy concern. Your answer was “experiments”.
THE FACTS: This is simply not true, and yet you still triple down even when I told you the answer: “and yet the connection is still being established” .. learn to read: once again, that URL is used for many different things. it is ASRouter connections, not experiments, and those connections (ASRouter ones) can be disabled via preferences, but we do not block them as they do not have any privacy concerns. Do you understand now?
Learn to read, but more importantly, learn to comprehend what you read.
> Thatâ€™s pretty pathetic.
Not if it could be read this way. Anyway, IF I misunderstood you, then that only means I have lowered myself to your level of reading comprehension. Shit happens, my bad. I’m so sorry, tears blind me.
Also, “pathetic”? My gal, you keep an entire protocol of my posts on gHacks around, THAT is pathetic. Taking a screenshot because I know by experience that you are underhanded is not.
> THE BIG LIE:
Oh, how dramatic. I can’t even…
> You made the claim that the user.js does not block all connections (itâ€™s not meant to) because it connects to the services domain, etc.
I never made that claim (Are you putting words in my mouth again? Doesn’t it get old by now?) – some connections are necessary, esp. the Firefox update check and the add-on update check, also captive portal detection. One should not block those because they are needed for Firefox to operate correctly and remain secure. That I denied the necessity of those connection by insinuating that everything, literally everything should be blocked is some bullshit of yours, for all to see.
> Your answer was â€œexperimentsâ€.
Yeah, and? That’s literally (part of) the answer, and thus the connection is proven to be unneeded.
> it is ASRouter connections, not experiments, and those connections (ASRouter ones) can be disabled via preferences, but we do not block them as they do not have any privacy concerns.
ASRouter is unneeded and is totally related to experiments. Point in case, and I quote:
“Messaging System Overview
At the core of the Firefox Messaging System is the Messaging System Router (called ASRouter for historical reasons). The router is a generalized Firefox component and set of conventions that provides:
– Flexible and configurable routing of local or remote Messages to UI Templates. This allows new message campaigns to be started and controlled on or off-trains
– Traffic Cop message sequencing and intermediation to prevent multiple messages being concurrently shown
– Programmable message targeting language to show the right message to the right user at the right time
– A template library of reusable Message and Notification UIs
– Full compatibility with Normandy pref-flip experiments
– Generalized and privacy conscious event telemetry
– Flexible Frequency Capping to mitigate user message fatigue
– Localized off train Messages
– Powerful development/debugging/QA tools on about:newtab#devtools”
None of that is anything a user needs for Firefox to be operational or secure. None of that. Also, do you see the “full compatibility with Normandy pref-flip experiments” part? Proves that it is related to Firefox Experiments, which is the worst part, but it is also related to telemetry crap and the notorious Mozilla propaganda messages a.k.a. snippets, they misuse that for stuff like this: https://www.ghacks.net/2020/07/25/mozilla-used-firefoxs-notification-system-to-push-the-facebook-boycott/
So again, show me what “useful” thing the connection is for and I’ll buy into your notion that it should remain enabled, not before.
Speaking of which, which about.config pref would disable the connection to firefox.settings.services.mozilla.com ? Eagerly awaiting your reply, you know so much more about Firefox than I do, surely you must know.
ANOTHER EPIC IRONHEART FAIL: still hasn’t shown that there is a privacy concern or that the connection is for experiments. Experiments are disabled. Just stop the lying and off topic noise and BS.
Exhibit #9653 for readers: This whole exercise has been a classic IH example of personal attacks, lies, making wild claims without any proof, going off topic…
– Show me why the connection is needed.
– Show me the pref that would disable the connection, even if (according to you) it’s to my own detriment.
I am waiting. By the way, the fact that experiments were disabled with a different pref is unrelated to the connection, the connection is not just there for experiments (but also for them, contrary to what you claim).
Clearly you also never retracted your lie re. me supposedly having claimed that “any and all” connections are unneeded, which is some bullshit. But I didn’t think you would.
Your whole argument and lie here is about privacy/experiments. Here: “does not block all privacy-breaking connections because experiments, or something because I, Iron Heart, do not actually know what I am talking about”, is that better? Its a basic assumption that no-one is talking about non-privacy-concerning things such as update checks.
You claimed the user.js fails some basic privacy because it does not stop experiments. THAT is a LIE
> the fact that experiments were disabled with a different pref is unrelated to the connection
So you agree now that experiments are disabled? And you agree now that the connection is unrelated to experiments? Or are you going to claim it’s still experiments?
> Show me the pref
Prefs actually. And no. Everything is already documented, discussed, and even proven on GitHub: including that the connections being talked about have zero privacy concerns and can be stopped via prefs if wanted
Take the discussion there instead of polluting yet another article on ghacks. I’m normally happy to answer a question and provide details, but you just take that as another excuse to go off on even more tangents. I’m not here to be your personal ad infinitum fact checker
> the connection is not just there for experiments (but also for them, contrary to what you claim)
Can you even write: 1+1 = 2 (but also 2)?! Anyway, quote me: “once again, that URL is used for many different things”. At no point have I ever stated anything that _doesn’t_ explicitly use it. Your logic is appalling
> Its a basic assumption that no-one is talking about non-privacy-concerning things such as update checks.
Ah, OK, now it’s a basic assumption after you have made that bullshit claim about me…
Pants: “You made the claim that the user.js does not block all connections (itâ€™s not meant to) because it connects to the services domain, etc.”
You said I stupidly demanded all connections blocked, I debunked it, and now it’s suddenly a basic(!) assumption that some connections must be allowed… OK. We know you are flexible there.
> You claimed the user.js fails some basic privacy because it does not stop experiments. THAT is a LIE
My gal, I didn’t say the user.js doesn’t stop experiments (that is you putting words in my mouth again). What I said is that it fails to stop a connection that is – among other things, like telemetry and snippets – related to experiments. That is not at all the same thing.
> So you agree now that experiments are disabled?
Yes, but that has nothing to do with the connection. The connection is still being established even if experiments are disabled – it’s also not ONLY related to experiments (one of the reasons why it is still active despite experiments being disabled, obviously).
Pants, I have explained that the connection does many things (but nothing useful), and that one aspect it is related to is experiments. That is a general explanation of the connection.
Pants: “But, but, experiments are disabled!”
IH: “What does that even have to do with the connection, it is related to experiments, but it does more than that! The prefs related to disabling experiments do not stop the connection at all.”
Pants: “But, but, experiments are disabled!”
And so it goes on and on… Yawn. You are deflecting. You are mixing up two different aspects to confuse others, this is not about disabling experiments, this is about stopping a nonsense connection that is related to experiments, but also to other nonsense.
> And you agree now that the connection is unrelated to experiments?
No, I don’t. As you can infer from the list I’ve posted here already…
…it IS related to experiments, but not ONLY related to experiments. The connection does more than that – but nothing useful.
> Prefs actually. And no. Everything is already documented, discussed, and even proven on GitHub
Again: Show me the pref(s) that stop firefox.settings.services.mozilla.com !!!
Don’t point me to ominous “documentation” for something that can be answered in less than one minute, so which pref(s) would stop the connection? Care to answer?
> Take the discussion there instead of polluting yet another article on ghacks.
It is you who hijacked this topic by deciding to annoy me again, but hey. And no, you can easily ban discussions you don’t like on GitHub, but you can’t here. I decline that non-offer.
> Iâ€™m normally happy to answer a question and provide details, but you just take that as another excuse to go off on even more tangents.
Just answer the question, lol.
Hint to others: According to Mozilla documentation, there purposefully is no about:config entry that can stop firefox.settings.services.mozilla.com, my dear Pants [Editor: added the correct name of the participant, removed the wrong one] is just dancing around that fact. Point in case, with the arkengem user.js applied, Firefox still establishes the connection, despite the fact that the connection is 100% an unsolicited request. Funny, isn’t it?
> Iâ€™m not here to be your personal ad infinitum fact checker
Then why are you here? You plan on “calling me out” and “proving me wrong” for more than a year now. You said that this is a “hill you are willing to die on”!? What happened? Also, I’ve proven you a liar and manipulator more than once here, you “fact checker”.
> Anyway, quote me: â€œonce again, that URL is used for many different thingsâ€.
Yes, and none of the things it is used for (experiments is just one of many) is in any way, shape, or form useful to the user, so why doesn’t the arkenshill user.js block the connection? Again: Show me why it is useful to the user, then I will buy into your notion that it shouldn’t be blocked.
Still dancing around the fact that it is not of no use to users and that your user.js doesn’t block it only because there is no about:config entry for it, huh? Keep doing it, you are already exposed.
> It is you who hijacked this topic by deciding to annoy me again
Quit while you’re behind dude. You are the one who misquoted me, claimed I said things I didn’t, and then asked about the connections. In future, any questions from you will be ignored and simply countered with “lies” (when it is a lie, that is)
> is in any way, shape, or form useful to the user, so why doesnâ€™t the arkenshill user.js block the connection
arkenshill .. see “psychological projection”. So mature.
The connection is not blocked because it has zero privacy concerns and is useful for some users. Who are you to decide what they want or don’t want. Prove to me it is not a privacy issue or stop talking
> Me: You made the claim that the user.js does not block all connections (itâ€™s not meant to) because it connects to the services domain, etc. claiming that itâ€™s a privacy issue and insinuating that the user fails in this task.
Quote the full sentence and it makes more sense. No matter how you spin it, you made a false claim. You have no idea what you are talking about: linking to four year old discussions and trying to find something on the internet to back up your BS (you can’t). Do some actual research and fact checking for once.
> You are the one who misquoted me, claimed I said things I didnâ€™t,
It’s you who does most of the projection here. My gal, you misquote me all the time, rip stuff out of context, insinuate that I said things I didn’t ever say, and so on and so forth. I try to avoid misquoting you, but if I do accidentally (and as far as I can tell, I didn’t here), then you have no moral authority to object. None whatsoever.
> In future, any questions from you will be ignored and simply countered with â€œliesâ€ (when it is a lie, that is)
You already do ignore the questions I have asked, namely:
1) In what kind of way is the connection useful to the user?
2) Which pref(s) would disable the connection, even if it would be to my own “detriment”?
I am you asking that for, like, the fourth time, without ever getting a reply that makes sense, even though the questions are being asked in good faith. I genuinely want to know how I can turn this off using about:config!
Also “lies”, Pants… you constantly accuse me of various things (even stuff you freely made up as you go), I’ve gotten used to the noises you make. Answer my questions for god’s sake.
> The connection is not blocked because it has zero privacy concerns and is useful for some users.
Again, how is it useful? It’s related to experiments, snippets, telemetry etc. There is no useful application mentioned anywhere in the Mozilla docs. Do you know of a useful application that Mozilla just fails to mention? If so, feel free to tell me.
> Who are you to decide what they want or donâ€™t want.
Question: Who needs telemetry / snippets / experiments or any connection related to that? Except for Mozilla, I mean.
> Prove to me it is not a privacy issue or stop talking
Again, you have it the wrong way around: YOU need to prove to me that the connection is in any way, shape, or form “USEFUL”, otherwise it is to be distrusted. Not the other way around.
> So mature.
Befitting for you, I’d say. Once you grow up, stop annoying me, stop putting words in my mouth, stop lying about me etc., I’ll deal with you in a cordial manner again. Not before.
> No matter how you spin it, you made a false claim.
How is distrusting a connection that has no useful application a false claim? How is mentioning the fact that arkengem doesn’t block the connection a false claim? You can desperately search for false claims, and you won’t find any. Your accusations are totally irrelevant to me.
Learn to read. I’m not going to indulge your off-topic requests – I am not your lackey. I have told you the answer already – apply some logic and search about:config: use your head for once. Otherwise, if you’re incapable of some basic investigative skills, ask at github, like anyone else
> > [quoting me] The connection is not blocked…
> Again, how is it [the connection] useful? Itâ€™s related to experiments, snippets, telemetry
Stop the lying. The connections you see, from your first question about why FF with the user.js makes connections, have nothing to do with experiments or telemetry
As for useful, that’s not even up for debate because .. wait for it … it has NOTHING TO DO WITH PRIVACY. If you don’t like the functionality it brings, then turn it off .. oh wait, you don’t even use Firefox
How long will you continue to maneuver here? Can you show me a pref that would disable the connection to firefox.settings.services.mozilla.com, or can you not? Writing that down takes, like, ten seconds and doesn’t make you my “lackey” (funny but obvious excuse). I’d be happy enough with you linking to a pref that would disable it to – once again, an effort that doesn’t take much time.
It is you who demands “due diligence” and “conclusive proof” all the time. So why aren’t you able to produce any? Or is it yet another case of “One rule for me, one for thee.”? Please produce evidence, or shut up.
> Stop the lying. The connections you see, from your first question about why FF with the user.js makes connections, have nothing to do with experiments or telemetry
Lying? Seems like Mozilla does all the “lying” for me here, their documentation indicates that the connection is related to telemetry, experiments, and snippets (posting it again because you seem to have miraculously forgotten about it):
â€œMessaging System Overview
At the core of the Firefox Messaging System is the Messaging System Router (called ASRouter for historical reasons). The router is a generalized Firefox component and set of conventions that provides:
â€“ Flexible and configurable routing of local or remote Messages to UI Templates. This allows new message campaigns to be started and controlled on or off-trains
â€“ Traffic Cop message sequencing and intermediation to prevent multiple messages being concurrently shown
â€“ Programmable message targeting language to show the right message to the right user at the right time
â€“ A template library of reusable Message and Notification UIs
â€“ Full compatibility with Normandy pref-flip experiments
â€“ Generalized and privacy conscious event telemetry
â€“ Flexible Frequency Capping to mitigate user message fatigue
â€“ Localized off train Messages
â€“ Powerful development/debugging/QA tools on about:newtab#devtoolsâ€
> As for useful, thatâ€™s not even up for debate because .. wait for it â€¦ it has NOTHING TO DO WITH PRIVACY.
You still have it the wrong way around: You need to prove that the connection is somehow benign (the Mozilla documentation doesn’t indicate that), otherwise it is to be distrusted(!).
> If you donâ€™t like the functionality it brings, then turn it off .. oh wait, you donâ€™t even use Firefox
Which *benign* functionality are you talking about? That would literally answer my question, don’t be so opaque here… If any such benign functionality exists, Mozilla seems to have missed it in their own docs. Big oopsie, Pants knows more about the connection than Mozilla does, apparently.
Pants, it is obvious to any outside observer that you are just dancing around the fact that you are totally unable to stop this unsolicited request because there is NO about:config flag for it, and since your expertise does not exceed flipping about:config flags, it’s the end of the road for you there. Keep dancing around the fact, funny sight to behold.
If you can’t tell me a) what benign use this connection has and b) which about:config pref(s) would disable it (according to you, such pref(s) exist) in your next inevitable reply, then I have shown what needed to be shown here. I’m out.
from the Anonymous who coined “arkenshill” on February 1, 2021 at 1:12 pm
â€“ is that the best you can come up with? itâ€™s very telling . Please show me where uninvited and unprompted and out of the blue I have consistently promoted Firefox or arkenfox user.js”
The main problem here is not promoting something, which is not necessarily wrong by itself depending on what is promoted and why ; the problem is to look like this projects exists to protect the users from the bad behavior of Mozilla (this is the expectation of most of your users, this is a crucial need today in the browser area to save the web from surveillance capitalists, and this is the most known user.js to my knowledge) while in fact you are breaking those expectations by defending most of their misdeeds and in fact deliberately working to discourage users to finally cut the cord and use forks, ultimately helping Mozilla to go on with their abuses [1,2,3,4,5,6,7,8…].
 Like Pocket re-enabled here, apparently according to another issue you are even a user of this Mozilla spyware yourself
 Or nothing done to prevent DNS queries sent by default to Cloudflare here:
Still nothing here
and totally on-topic criticism hidden as “off-topic”.
 Here your answer to “Philosophy matters with software, not just the code itself. Free software is about freedom, that includes customization of the code, and of which fork or mainline to use. Stop trying to imply that we must trust the Mozilla as some kind of authority – they have a pretty bad track record over the last 10 years. Even Archlinux includes a Google tracking id in their Firefox builds for one…and the lack of pocket and other complete and other bullsh*t inclusions that Mozilla has pushed on users makes Waterfox much more attractive…[…] I also remember Mozilla installing an addon silently to market some TV show…showing that not only can they do hat without user interaction, but will do so proves that they are no longer trustworthy without heavy auditing…and then there’s the ad laden new tabe page…shall I go on ?”
was to hide the comment, call it “a bunch of batshit crazyshake statements” and that “Clearly you need help” (apparently another situation where disapproving Mozilla signals psychological disorders according to you):
A user.js project thinking like that should not be trusted to defend our interests against Mozilla. This needs to be exposed.
 Here those who do not want Firefox to connect to Mozilla to download Pocket and snippet ads are “fuckers” who don’t understand that “not all connections are bad”.
 the previously mentioned intention to re-enable DRM by default, title was modified after this discussion:
 Here this Mr Robot malicious behavior of Mozilla was only a “blooper” according to you, and you don’t mention anything else they could have done wrong from your point of view, and it would be ok anyway because Google is bad too:
and their search deal with Google is fine with you in this post. About Google Analytics in Firefox you write in this post:
“Google Analytics used in the browser (Activity Stream, Get Addons panel, AMO) – they have a special deal for that (see chinaar’s post above about how sacred deals are and the shitstorm that would happen if broken and made public). Why use GA: probably because it’s cost effective rather than roll their own. Again, just stepping in their shoes – do they care about privacy? Yup, they did a special deal.”
This one alone is enough to call you a Mozilla shill, it’s unbelievable that someone saying that garbage is trusted by so many to defend their privacy against Mozilla and Google. This needs to be exposed.
You also say that Google Safebrowsing is fine, which is already quite dubious for the URL part, but more importantly you omit saying (while knowing it more than anyone else) that Firefox tells to Google a good part of what files the user downloads.
“So as for the browser not being private: I disagree.” Ok, again you can’t be trusted to defend us against Mozilla, if it’s your starting point.
“I think Waterfox, Palemoon and other FF forks (Tor excepted) are a waste of time as recommendations: because you can already control FF to an extremely high degree.” : why would privacy seeking users spend hours understanding a user.js or customizing their software back to a smaller malware level when they could say no and use a browser that is not malicious out of the box ? you are here to keep users under the nefarious influence of Mozilla and you help kill the attempts of emancipation through forking.
 So you still trust Mozilla in spite of all the shameful anti-users things they did, while for you here forks of Firefox that never did anything like that are “re-DiCK-ulous”, or a “piece of junk”, and then the free software-hostile typical corporate argument, a small resource non corporate fork that cleans a corporate malware should not be trusted because from a “one-man-band”:
 in reply to “I feel many many more users would switch to Waterfox, especially this user.js crowd” : “Not if I can help it. There is no reason to use a fork.”
tl;dr: You do seem to be coherent, so I’ll address most of it below. But I’m not really interested in your analysis, some hand-wavy ideological theory, some handpicked comments from thousands made over years etc. One-dimensional, black+white, non-critical thinkers, who are biased and/or already have an axe to grind with Mozilla, I am more than happy to drive off to go and use forks or anything else. I know who I want my target audience to be, don’t assume to know what my intentions are.
I always argue both sides in order to get or facilitate a better view/discussion. I have always said that nothing should be “trusted” on face value and everything should be scrutinized: and sometimes that can be subjective. You make some fair points but I feel they are taken collectively as out of context
> You also say that Google Safebrowsing is fine, which is already quite dubious for the URL part, but more importantly you omit saying (while knowing it more than anyone else) that Firefox tells to Google a good part of what files the user downloads
You may disagree about the URL part (there are several mitigations here: e.g. part hashes hidden with other real part hashes), but three facts remain: the user.js disables the real time binary checks (and warns users of the consequences) – I’m sorry that the real-time binary check info isn’t mentioned in a different repo’s comment: a comment trying to cover a large area – but it is in the user.js and the wiki etc. The user.js allows the rest of safe browsing as a default (because security by default is important). It still documents turning it off for those who don’t want it (and understand the risks)
Do you have a argument against that logic?
No, I do not use pocket, not sure where you got that idea, and the link is for someone else’s comment. The user.js is concerned with privacy: the pref referenced in your link has nothing to do with privacy. Unless you sign up for a pocket account, then no connections are made for the pocket extension. Whether someone likes it or not is not part of the mission. Who am I to allow/deny people who may want a Pocket account. It would be hypocritical to apply my own personal preferences on others: this is why the 5000 section exists
There’s a few reasons for that. DoH has pros and cons, and there is no right answer. If your whole argument is DoH in the browser is evil, then you’re wasting my time. At best, the most I’ll ever add is a few info links and a pref or two: it’s not something I will enforce on anyone: so I don’t see the hurry
Secondly, the roll out is slow (only affects one or two countries right now: I would need to re-check), but when it does happen for a user, my understanding is the user is informed via a doorpanel and they can cancel: pretty sure it is opt out which may or may not be the best depending on your view if DoH is evil or not.
Don’t get me wrong: this is not the same as informing users ahead of time so those who wish to make sure (the rollout) it is blocked can enable the pref: but I also don’t see it as the threat everyone else does. And for those wishing to use it, there are already a huge amount of articles and they’re probably already set up with alternative servers etc, so I’m not in any hurry there either
There’s a third reason that has more to do with drawing a line in the sand within the repo itself – but that has nothing to do with you
“and totally on-topic criticism hidden as â€œoff-topicâ€” – I disagree: OP explicitly says “This is not a debate on this state = good, this state = bad.” – i.e I am only interested in adding information for users to make their own informed choices
> Robot “blooper”
Yes that was a wide-sweeping general statement in a different repo. And I’ll stand by it. It was a procedural, documentational, expectational and human failure, as was Cliqz. All companies make mistakes, it’s about how they respond to them. Mozilla put some procedural measures into place to help mitigate it happening again: such as a digital trail of accountability, and sign-offs from a limited number of people. Since those incidents, nothing like them (a scary unannounced robot game extension, or a 1% trial of a countries users with new installs that had some privacy issues) has happened since, which is a good thing. Additionally, it also tightened up telemetry requests and added an accountability trail there as well. Of course all actions should still be scrutinized and anything dodgy held up and questioned.
So yes, I will forever call it a “blooper”, or a mistake or whatever. I’m not sure what else you’re implying, because if it is that it was deliberate (well of course it was designed to do that: misunderstanding or knowing that this is what they could do) that’s fine, but “deliberately malicious” I don’t think anyone could prove that. So I’ll call it a “blooper” and a wake up call for their experiment team
> GA deal
I’ll dispute your analysis of that statement: go read it along with my disclaimers. Again it’s in that one-off wide-sweeping comment in a different repo trying to cover a lot of ground. As stated, it’s always about looking at both sides of the story and providing a balanced view. Not everything is always black and white. They did a special deal, which limits how google can use that, and costs are always an issue (I can’t find it right now but they did look at alternatives: which showed they cared to some degree). So I do not bemoan this choice of theirs on their own domains: do I LIKE it myself, not particularly, but I can appreciate how they arrived at that decision and at least mitigated parts of the threat/risk.
The user.js actually allows extensions to function on those protected moz domains: so it’s not like I’m not doing something about it or haven’t held them somewhat accountable
> the rest
“So you still trust Mozilla in spite of all the shameful anti-users things they did…” . No. I only care about what the browser itself can do. As long as I can control it, then it provides the best solution currently out there on desktop for privacy (IMO): which is all I care about. Do you think I still don’t scrutinize them? Or not think some of their decisions suck?
You: “helping Mozilla to go on with their abuses”, “shameful anti-users things”, “a browser that is not malicious out of the box”” – you are exactly the sort of non-objective user I am not interested in dealing with. You’re biased to start with
One thing I am very aware of is users expectations: which is why I am deliberately discouraging the sort of black/white ranting/thinking of visitors: e.g. expecting the user.js to block all outgoing connections. Thinking all Pocket is evil. Thinking all SB is evil. Often these are the same people who make wild claims and often then talk about forks. To be fair, I am often short and blunt and outright rude to these sorts – BY DESIGN.
You think I’m on some sort of pro-Mozilla: no: I scrutinize them heavily: I just think it’s the best solution
You think I’m on some anti-Fork crusade: not really (but I do think some have serious issues): I do not see the point when you can control it all with FF itself
> title was modified after this discussion
I find this absolutley hilarious, because I planted it there. I rename titles all the time. Even though a lot of issues start and stay with “reminder: do x” (because I’m usually backed up on them), they are always about discussions as stated in OP: and may or may not happen. I changed the title because I knew it would mess with IH’s head if he wanted to bring it up. I guess you went for it instead. Changing the title to reflect the outcome more accurately is not proof of anything
Just always the same stretched Mozilla marketing bullshit to defend accumulated malicious behavior that would never be accepted from another company by the free software community. Not worth replying to that BS point by point, it has been done over and over already. Readers will judge by themselves.
OK, I knew I was wasting my time: when you use the word shill, and then call everything spyware, malicious and so on – clearly you already made your mind up, and you only see in black and white. It’s people like you I don’t want anything to do with: because you’re not objective. You’re already anti-whatever and I’m not here to deal with your problems or your world view – I just do not care about you.
Instead of making accusations about my motives: why don’t you prove I have not scrutinized Firefox changes, or that I have compromised a user’s privacy. Why don’t you show the posts where I criticize Mozilla changes, or would that upset your narrative?
Clearly you have an ulterior motive here, and are trolling.
Oh and look at what Pants is saying now, the TLS identifiers should be re-enabled because being tagged with unique identifier supercookies by every site at every connection (hello there, Cloudflare DoH too that he didn’t block) would be not as bad as a tiny performance hit, even for the tiny minority that uses his user.js ; or even worse, copied straight from the mouth of Google, because having privacy defenses like blocking *unique identifiers* would “make you more fingerprintable” :
Not bowing down to every tracking trick pulled by Google and the like is “not secure”, “fingerprintable”, “bad for performance”, “more costly than collecting data ourselves” (!)… and this even in a niche user.js supposedly for privacy geeks.
* [Editor: removed, please stay civil]
lol .. learn to read/comprehend: I encourage everyone to read the issue: https://github.com/arkenfox/user.js/issues/1110
gee, even Anonymouses are being edited.. such a lovely environment
Cloudflare dns leak still not shown. Same story each check, month after month. ffprofile.com can be bothered to list and inform about it. Hurts confidence in all these lists when they cant or wont keep up with this stuff.
setting is at the bottom of general settings, burried under the technical network settings click then at the bottom of that. Untick to disable, check ipleak.net to ensure firefox isnt sending your dns info some place else. “configure how firefox connects to the internet” is easily overlooked if connection is working, bit sneaky.
network.trr.mode 5 to disable it in about:config if anyone sees and is interested.
I think more got added so who knows what the browser is even doing anymore.
Currently using Firefox 86b4 and it’s just peachy.
On another note, Mozilla sure is slow updating Firefox for Android.
Still have Ver. 84.1.4 for weeks now with no mention of any updates.
I get the PC updates regularly, so trying to figure out why Mozilla is slow with the Android releases.
Android Play Store updates are weird sometimes. Depends on your geographic location and some other random factors. Have you tried manually going into the Firefox (Stable) page in the Play Store app on your phone and see if the button says ‘Update’? I’ve seen a number of cases where the auto-update didn’t pick it up.
They are slow with the Ubuntu releases as well. I still have 84.1.4 as well.
It could be Canonical’s fault tho.
It could be what phone and OS version you have. I’m on a Pixel 3 XL, and my Firefox was updated to 85.1.1 a couple days ago. Usually I get the update two to three days after the desktop version.
Firefox is a good choice for certain tasks, however it hangs the computer too much times with AMD GPU built in drivers if hardware acceleration is enabled, tested with all kind of driver versions, including stable or latest ones. The last time that Firefox hanged my computer was while opening Google search site, amazingly weird than a single tab is able to hang an entire W10 computer. I don’t know if the cause is AMD GPU or even Firefox itself, however no problem ever with Edge Chromium nor IE11, both them have hardware acceleration active and both is working flawlessly. :[
Could this be a driver issue? I have an AMD Vega GPU and it seems to work fine with FF.
I suppose too that it’s a weird driver issue, however it only happens with Firefox. By the way, it’s well known that your AMD Vega GPU works really nice, and probably it’s one of the best GPU ever made by AMD. :]
Can’t wait for more Mozilla Firefox, especially when they openly support censorship while still pretending and telling lies about “open and free internet for all”.
Guess people don’t care much about anything as long as “it is not chromium because…” and you can add any excuse about marketshare and eggs in one basket and all that, none of those can justify this company openly supporting censorship and internet just for “few ones we like, the ones we “don’t” like shouldn’t have it”
But oh well, I guess it is good some people will get these amazing DRM stuff on it.
– Mozilla fanboy
It is not entirely clear to me how an open source browser can possibly censor people, to be honest. Perhaps they’ll introduce code that prevents you from accessing certain websites, perhaps they could even maintain a remote blocklist from which Firefox constantly fetches new “evil” website entries (similar to the add-on blocklist or Google SafeBrowsing). But then, Firefox is open source, so there will inevitably be people patching out that component. They might make that component closed source, perhaps as a proprietary binary blob (I wouldn’t put even that behind Mozilla), but even then, people could work from the last non-tarnished state of affairs and continue to apply only benign patches from Mozilla from that point on. Even if they make such a component an requirement for building Firefox, it wouldn’t be insurmountable.
Mozilla is not a free speech advocate (anymore), so much is clear I think, but what is of interest to me would be how they could possibly pull that off, considering a public open source history? Even if they went fully closed source, people could still fork the last open source state.
I don’t want to enter into a political debate here (I am not fond of the ideology that is being censored here, but neither am I fond of censorship as a concept, just so you know), but I will assert that I think a browser should remain a neutral(!) tool doing my bidding no matter where I want to go. Stating anything else is like saying my TV should have a say in what channels I am allowed to watch – it’s just a tool with no right to lecture me or to warp my sense of reality by preventing me from accessing certain info (if I wanted to), please, dear browser, just do my bidding as you always have so far. I am not supportive of censorship.
>It is not entirely clear to me how an open source browser can possibly censor people
When its stripped down to a cloud ran rendering app and the makers become service providers (Scroll? Better Web?). Webhosters will be suckered in, paying to serve a clean protected web. They can then de-platform whatever they like including the user and serve whatever ads and tracking. So much sly manoeuvring when you think about it, give it 10 years.
Ah, OK. The horror. People shouldn’t allow that, it is very important to maintain user independence and user autonomy, in my opinion. But yeah, what you say sounds realistic. :(
Mozilla disable all possibilities to open local html files. Good bye firefox
It’s better not to waste time dealing with that hypocritical company
What do you mean? Where have they disabled this?
It means Firefox 85 Android now cannot open some files stored on your device, you were previously able to view local files and directories by entering/bookmarking, example: file:///storage/emulated/0/Documents/bookmarks.html
On Android Nightly I use the Add-ons SingleFile (save a web page as .html) and Markdown Viewer Webext (render .md files), those Add-ons still work, but I now have to use another browser/app to read locally saved .html and .md files. :(
What about Firefox Focus, is it the same in that ?
Firefox v85 on Android can no longer open local html files.
I can only open them using Bromite or Chrome, or some other text or HTML viewr app.
This limits the ability to do web coding on Android tablets using Firefox.
I don’t know if it was done for some security reason, but I find it very user-unfriendly.
A browser that can not open local html files is just stupid.
Imagine a text editor being able to open local html files, while a browser can not.
I don’t know with which version this handcap was introduced.
The desktop version can still open local HTML files (for now?).
I still miss the ‘Tab Queue’ feature from previous Firefox version. That was a brilliant that no other browser on Android currently has. I wish they worked on bringing it back than adding bloat stuff like ‘Collections’.
It could be what phone and OS version you have. I’m on a Pixel 3 XL, and my Firefox was updated to 85.1.1 a couple days ago. Usually I get the update two to three days after the desktop version.