Path: csiph.com!weretis.net!feeder8.news.weretis.net!reader5.news.weretis.net!news.solani.org!.POSTED!not-for-mail From: Richmond Newsgroups: alt.comp.software.firefox Subject: Re: Unwanted update to 150 just happened Date: Thu, 30 Apr 2026 09:10:26 +0100 Organization: Frantic Message-ID: <82jyto27il.fsf@example.com> References: <10sinht$tpvi$1@dont-email.me> <10sisme$vqg1$1@dont-email.me> <10sivi0$10uuo$1@dont-email.me> <10sptp2$311i3$1@dont-email.me> <10sr2ep$3c77i$1@dont-email.me> <10sr8ck$3f3pq$1@dont-email.me> <10srqs8$3jk6e$1@dont-email.me> <82jytp6a67.fsf@example.com> <10stlmh$51ep$1@dont-email.me> <10suick$c4n8$2@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: solani.org; logging-data="1273253"; mail-complaints-to="abuse@news.solani.org" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:MBGOdwlsVWkmyyISQCCYOUJ+gYc= sha1:Jc4VvzKKPOv+C84WWyhCBWu0/v0= X-User-ID: eJwNxMcBgDAMA8CVcJPwOInL/iPAPS4MgqIj4LGxldtzOfkWSNSRksnOut6q/8EQg1kfFT7zATXeEWk= Xref: csiph.com alt.comp.software.firefox:16964 The Real Bev writes: > On 4/29/26 12:20, Dave Royal wrote: >> dillinger Wrote in message: >> >>> On 29/04/2026 17:47, Richmond wrote: >>>> dillinger writes: >>>> >>>>> Op 29-04-2026 om 04:36 schreef The Real Bev: >>>>>> On 4/28/26 14:21, Dave Royal wrote: >>>>>>> The Real Bev Wrote in message: >>>>>>> >>>>>>>> On 4/28/26 02:14, Dave Royal wrote: >>>>>>>>> The Real Bev Wrote in message: >>>>>>>>> >>>>>>>>>> On 4/25/26 10:26, Nobody wrote: >>>>>>>>>>> On Sat, 25 Apr 2026 18:18:07 +0100, Andy Burns >>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Retirednoguilt wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I've never had FF update me autonomously. >>>>>>>>>>>> >>>>>>>>>>>> I have it set for "Check for updates but let you choose to >>>>>>>>>>>> install them" and as best as I can remember, its never >>>>>>>>>>>> disobeyed ... >>>>>>>>>>> >>>>>>>>>>> Should a user (for whatever reason) 'uninstall/re-install' >>>>>>>>>>> then that radio button changes to 'automatically >>>>>>>>>>> install/recommended'. >>>>>>>>>>> >>>>>>>>>>> Semi-OT, Thunderbird conversely holds the 'check for updates >>>>>>>>>>> but lemme do the work' setting. >>>>>>>>>> >>>>>>>>>> I have had that setting for decades -- and still do. Some >>>>>>>>>> years ago it stopped working and some kind person posted the >>>>>>>>>> policies.json fix -- which worked until today. Posted >>>>>>>>>> herewith: >>>>>>>>>> >>>>>>>>>> Make a new firefox/distribution/ subdirectory which will >>>>>>>>>> contain the file policies.json which contains { "policies": { >>>>>>>>>> "DisableAppUpdate": true } } >>>>>>>>> >>>>>>>>> Did that 'kind person' provide a policies.json file for you to >>>>>>>>> download, or did you create one - on Linux? >>>>>>>> >>>>>>>> Someone posted about that file long ago, and the one I created >>>>>>>> with pico worked for years. > Just wondering how these Windows >>>>>>>> line endings - if that was the > problem - got there. They >>>>>>>> appeared when Firefox chose to update itself against my express >>>>>>>> wishes. I suspect that Firefox did it of its own volition -- >>>>>>>> or simple clumsiness. Core dump complete. >>>>>>> >>>>>>> You /found/ them after the unwanted update. Were they >>>>>>> responsible for it? I doubt it: line endings - of either type >>>>>>> - are ignored in a json file. >>>>>> >>>>>> The windows endings damaged the file such that it no longer >>>>>> served the purpose. Fixing it worked. >>>>>> >>>>> >>>>> Firefox doesn't care about line endings. >>>>> >>>>> Just for the sake of it I tested it for you, I created a >>>>> policies.json which blocks about:config and tested it with both >>>>> CRLF (windows) and LF (unix) line endings. >>>>> >>>>> The result are the same for both, it works: Blocked Page, Firefox >>>>> can’t connect to the server at about:config >>>>> >>>>> ^M is not a corruption, this is how cat -A shows CR, your AI needs >>>>> an update. >>>>> >>>>> CRLF (windows): cat -A policies.json {^M$ "policies": {^M$ >>>>> "BlockAboutConfig": true^M$ }^M$ }^M$ >>>>> >>>>> LF (unix): cat -A policies.json {$ "policies": {$ >>>>> "BlockAboutConfig": true$ }$ }$ >>>> You tested whether it blocked >>>>> about:config, but you didn't test >>>> whether >>>> it blocked an >>>>> update, or if the update altered the json file. >>> I tested >>>>> policies.json, which was reported corrupted, with both >>> CRLF >>>>> and LF, any policy will do, we don't need to wait for the next >>> >>>>> update. >>> Policies.json is not included by default, updates >>>>> will either not >>> touch it at all or remove it completely, >>>>> depending on how you >>> update. >>> Since we can't see the >>>>> original file there is no way to tell how it >>> was changed. >> >>>>> Why might an update remove policies.json? I assume that the >> >>>>> firefox updater will read it if it's there but never write to it. >>>>> >> The point of it is that it's user, or organisation, >> >>>>> controlled. >> I did wonder if updates might /update/ >>>>> policies.json, for changes >> in format say, in the way they >>>>> update a profile. But I doubt >> it. >> On Debian I have tarballs >>>>> of Fx nightly and TB beta, in addtion to >> packaged versions for >>>>> regular use. They do not include a >> distribution/ directory or a >>>>> template policies.json. > > No, they're not included with the tarball. "Some kind person" posted > the fix at some point in the past (earliest I have is Firefox 72, July > 7,2020) posted how to do it. If I want to use a newer version I don't > update. I download the tarball, untar it into its own subdirectory > and run it from within that subdirectory (/blabla/firefox/firefox -P > &). After running it once I exit and copy over (cp -rf *) my previous > profile into the newly created profile. Accordingly, I have at least > a dozen fully functional firefoxes. TMI, but there it is. > > Worked fine until somebody said that FF148 had some sort of security > problem, at which point I did an update to 149 rather than building a > whole new installation. I think I renamed the policies.json file, > which would have been the simplest thing. Sorry I can't be more > certain. Then I would have renamed it back. And then I got the > unwanted surprise of the 150 update. I turned the problem over to > Perplexity, which provided the solution. If anyone is interested I > can have Perplexity generate a nice pdf file of the entire > interchange. > > I assume that firefox does some variant of cp -rf * when it updates > and then does some profile-creation stuff and god knows what else. It > must also use some touch-like command, becuase the date of the > policies.json file was the same as the date on all the other FF 150 > subdirectories and files. I don't remember looking at the > FF149/firefox files because I would have had no reason to. And that > must be when the mischief occurred. > > AH-HAH! At some point when I first heard about the policies.json > thing I was unsure about where to put it, so I put one in the /firefox > subdirectory. It's still there, and contains the ^M characters. They > seem to be M- instead of ^M, for what it's worth. Its date is the same > as all the others -- April 24 19:37. > > cat -A policies.json {$ M- "policies": {$ M- M- "DisableAppUpdate": > true$ M- }$ }$ $ The plot thickens. Here is what my favourite AI said: "In your case, the indentation uses UTF-8 encoded non-breaking spaces (or similar Unicode whitespace) instead of regular ASCII spaces (0x20). For example, M- is likely a non-breaking space (U+00A0, encoded as 0xC2 0xA0 in UTF-8). Why this matters for a JSON file: Most JSON parsers only treat ASCII whitespace (regular space, tab, newline) as insignificant whitespace. Non-breaking spaces can cause parse errors depending on the parser. "