Google Chrome Switching To Weekly Security Patch Updates (9to5google.com) 28
Google announced today that Chrome is now adopting weekly Stable channel updates in an effort to block major exploits quicker. 9to5Google reports: Google's browser gets major "milestone" updates every four (previously six) weeks, like going from version 100 to 101. In the past, Chrome would get a "Stable Refresh" update to "address security and other high impact bugs" in-between milestones every two weeks. This is now changing to occur weekly between milestones, starting with Google Chrome 116 on desktop and mobile, so that security updates get to end users much faster. Since Chromium is an open source project, "anyone can view the source code, submit changes for review, and see the changes made by anyone else, even security bug fixes." [...]
The current patch gap is around 15 days. It was previously 35 days before switching to patch updates every two weeks in 2020. Google expects weekly patch updates to result in security fixes shipping "3.5 days sooner on average, greatly reducing the already small window for n-day attackers to develop and use an exploit against potential victims and making their lives much more difficult." This new schedule will also result in fewer unplanned updates that occur when there are known in-the-wild exploits: "By now shipping stable updates weekly, we expect the number of unplanned updates to decrease since we'll be shipping updates more frequently."
The current patch gap is around 15 days. It was previously 35 days before switching to patch updates every two weeks in 2020. Google expects weekly patch updates to result in security fixes shipping "3.5 days sooner on average, greatly reducing the already small window for n-day attackers to develop and use an exploit against potential victims and making their lives much more difficult." This new schedule will also result in fewer unplanned updates that occur when there are known in-the-wild exploits: "By now shipping stable updates weekly, we expect the number of unplanned updates to decrease since we'll be shipping updates more frequently."
Better idea (Score:1)
Don't have vulnerabilities, perform input validation.
Re: (Score:2)
Exactly! This is like admitting the product is full of holes so they need to patch it as fast as those holes are discovered. Now, imagine all the non-patched holes discovered by bad actors but not shared with anybody!
Re: (Score:1)
Re: (Score:2)
The version numbers stopped being meaningful years ago.
Hell the entire user agent is mostly useless.
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36
Mozilla/5.0 why not HTML/5.0 ... again, why is
(OS ; OSbits; Bits) , why does this matter at all?
AppleWebKit/537.36 , why is google still using this at all? Current AppleWebKit is 605.1.15
(KHTML, like Gecko), why is this even necessary?
Chrome/115.0.0.0 , hey look the actual version number
Safari/537.36
Re: (Score:3)
the user agent is merely informational legacy (this is why those legacy strings are still used) and there isn't even assurance that it is authentic. if you use the content for any real decision you're doing it wrong. you should check for device capabilities and functionalities instead.
Even less stable Chrome (Score:3)
Yay. Speeding up releases made it less stable, so to fix it, lets speed up releases any more. Sometimes I doubt anybody is running the project at Google.
Re: (Score:2)
Implying that Chrome is unstable? Except it's not. I don't think I've had a Chrome tab crash in years. And yes the occasional crash vs fixing 0day exploits is objectively a good thing.
My security is more important than you having to retype your half finished Slashdot post.
Re: (Score:2)
You don't notice when it crashes. It rarely reports to the user, the first stop of Chrome upon a crash is to relaunch with a different seed for the random field experiments, so you get a different set of experiments. If that works the users sees nothing except the screen blink shortly.
Re: (Score:2)
Yay. Speeding up releases made it less stable, so to fix it, lets speed up releases any more. Sometimes I doubt anybody is running the project at Google.
Move fast and break stuff ! - Silicon Valley coder's motto
Re: (Score:2)
Move fast and break stuff ! - Silicon Valley coder's motto
With the corollary "If you're not breaking enough stuff, you're not moving fast enough".
And the Microsoft-specific variant "Just break stuff".
Why? (Score:3)
I do not understand why. It is not like the WEB standard change every other day. How about this, TEST and stop adding new features. I get the feeling we are the testers.
Also, I strongly suspect the vulnerabilities are occurring due to google's mining input data and trying to read all the cookies and cache left by all the sites you visit. I would not be surprised if chrome attempts to examine everything ~/.mozilla.
Re: (Score:2)
ources of Chromium 115 are 11,239,959,838 bytes after decompression (I downloaded chromium-115.0.5790.170.tar.xz 1,595,419,840 bytes and unxz) which includes numerous embedded third-party libraries. There ought to be vulnerabilities on a weekly basis even if they stopped adding to that. They already added to much, as part of their strategy to make Google Chrome basically an OS.
Re: (Score:2)
Market share, or perceptions thereof.
Google here advertises Pixel and Chrome for mobile on the SBS streaming app. I thought they had the Android browser market sewn up but it seems like they're worried enough about wooing iPhone users in a niche market of multilingual streamers in a population of a mere 25 million.
Re: (Score:2)
I use Chrome on my iPhone because it offers desktop mode. I hate mobile sites with their giant fonts and useless white space.
Re:Why? (Score:5, Interesting)
That is WHY! HTML5 is a living standard. Which is stupid while you can use various capabilities and JS probes to see if a given UA can display a document / application it leaves users with exactly no way to know a head of time if a given UA will be compatible with an application (they never did anyway because standards were no followed but at least it let you know where to finger point).
Of course Google's lobbying of the W3C had a great deal to do with that. Basically the Web's standard today is whatever Chrome-latest does..
Which I think absolutely sucks! Because it means you can't put a purpose oriented web terminal into something like an infotainment system in a car, or a display on a fridge, and have the grocery store chain know that that the most popular LG and Samsung Fridges implement HTML 5.3.4.2 and ECMAScript 6.1 - so they can develop to that an ensure their customers can use their app in the kitchen. Google is so often why we can't have nice things, shiny things certainly, but not nice things that work properly and certainly not things that work properly over the span of time someone might keep an aplliance or car.
And to the person that said input validation ... yeah I am not so sure here. The browser/UA isnt really a document rendering engine any more. Its a runtime environment. Saying 'input validation' is almost like saying GCC should do input validation and refuse to compile a C program that is malicious (how can it really know) or even just one that might cause some memory access violation, nice if it can produce some warnings, but there are case where its difficult to know if something is correct until runtime. For that reason ultimately the browser has to have solid runtime error trapping and good sandboxing - both of those things are hard problems. Even the hardware guys struggling to get that right on modern CPUs..
Re: (Score:2)
Of course Google's lobbying of the W3C had a great deal to do with that. Basically the Web's standard today is whatever Chrome-latest does..
Not just Chrome latest, but also whatever the latest Angular developers think they need for their hair-brained schemes. I will say that the shadow dom is a particularly dumb idea. To be clear, the implementation is dumb, whereas it has the intention to solve a valid use case.
Re: (Score:2)
Web standards and how a browser works are not the same thing.
Also you're implying that the software is already perfect. It's objectively not. Just because you stop adding features doesn't mean you don't need to apply security fixes.
Moving closer to live patching (Score:3)
stability about to take a nosedive (Score:5, Insightful)
Very weakly (Score:1)
Version numbers (Score:3)
Can't have the competition getting ahead on version numbers...
Side search killed Chrome for me (Score:2)
I will probably never update above 115. If I wanted side popups in my browser, I would use Edge.
Confused (Score:3)
Can anyone tell why modern browsers are huge monolithic blobs of code instead of you know using shared libraries, so instead of updating a big fat something you could instead replace or patch much smaller files?
On Linux
Google Chrome binary: 222,296,432 bytes
Firefox' libxul.com 142,354,864 bytes