Slashdot Mirror
Google To Auto-Migrate Some Users To 64-bit Chrome
Google says it will automatically upgrade the version of Chrome that some Windows users are running, in what it describes as a bet to improve stability, performance, and security. From a report on ZDNet: In a blog post on Tuesday, the search engine giant explained that Chrome users running 64-bit Windows with 4GB or more of memory will be automatically migrated to the 64-bit version of Chrome if they are running the 32-bit version.
While it's not necessarily good how is a switch from 32 to 64bit of browser worse than an entire operating system?
Since Chrome doesn't support plugins anymore, what's the point in keeping it 32-bit on 64-bit systems? I don't see any features that break in 64-bit.
what a load of crap.
Chrome is Chrome is Chrome. Moving to 64 bit makes sense simply because of memory management issue. My current Chrome usage of RAM is well over 4 GB (lots of windows open), and I suspect that most people are using way more RAM than they think.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
Google says it will automatically upgrade the version of Chrome that some Windows users are running, in what it describes as a bet to improve stability, performance, and security.
In other news, Google will automatically search for results that it considers relevant, regardless of what you type in the search bar, in what it describes as a bet to improve quality of searches.
(I know on average they are right and users can't spell, but I find it really annoying when my perfectly correct search term is changed to something more common automatically)
In Chrome each tab is its own process. Do you really need more than 4GB for one tab?
> ...Chrome users running 64-bit Windows with 4GB or more of memory....
As if it doesn't use enough memory.
and I suspect that most people are using way more RAM than they think.
I agree, but I think you mean that Chrome is using way more RAM than a sane person would expect.
I just opened a tab listing folders on a web server (5 files and 5 directories, no index.html). According to Chrome task manager, this tab is taking 18.94 MB! That's for 10 lines of text and white background all around.
While it's not necessarily good
No change in user experience. That's good.
There's more to 64 bit than just the bigger address space. Annoyingly Google don't seem to be giving much away here beyond "stability, performance, and security"
The interwebs seem to support that there's a performance improvement but the difference isn't huge.
The ZDNet article really adds nothing over Google's blog post. Would've made more sense to have the summary link directly to that.
Google is a good company (for example leader in fish transportation systems). So I think the move to 64 bit is good.
ACKCHYUALLY,
Each Chrome tab is limited to 4GB, even in 64-bit. "For security reasons."
And I've hit the limit before. Scrolling endless webpages is an easy way to hit the limit. Also, some addons like AdBlock use up a lot of memory.
I think you mean that Web pages are using way more RAM than a sane person would expect. Both Chrome and the user are the victims here.
#DeleteFacebook
He specifically said there was no index.html. You can't blame a web page that doesn't exist. This was a directory listing.
Because no-one will notice.
systemd is Roko's Basilisk.
Nope, it isn't just the web pages it has to do with the underlying implementations rendering and JS engine. Compare Firefox, Chrome, Opera, IE, Edge, etc. on the same system with the same page. Oh and if they have any JS, leave all of them up overnight and compare again. Holy memory leaks batman.
This auto update may break your Chrome in Citrix Xenapp 6.5, I was running the 32 bit version in the Citrix farm for a reason and it auto updated on me and I had to add the following switches to the Chrome shortcuts to resolve the issue --no-sandbox --disable-infobars --disable-gpu --no-default-browser-check --disable-popup-blocking --enable-npapi
You don't want more than 4GB of RAM for each, but you absolutely do want more than 4GB of virtual address space if you want ASLR to do any good.
I am TheRaven on Soylent News
Why is that? Please do tell.
Because I don't use that Google shit.
“Common sense is not so common.” — Voltaire
Try the login page for Tumblr.
It loads more than 20Mb of scripts and images.
What does 32 vs 64 bit have to do with security? I'm genuinely curious... It seems as if they are claiming their 32-bit users, or those without 4GB of RAM are somehow inherently less secure. That seems like marketing nonsense to me.
Of course this wouldn't even be an issue if Windows wasn't such a giant piece of garbage that it's taken this long to get a mainstream 64-bit operating system and applications. I've been running a 64-bit build of Firefox on Linux since, what, 2004?
How anyone can think a company manipulating software on your machine, without your permission, is acceptable is beyond me. It's bad enough Microsoft does it with their forced updates, but now Google is intruding as well?
The only reason I have Chrome on my system at work is so I can tell Adobe, "No, I still can't log into our VIP account because your site doesn't work correctly. It doesn't matter if I use IE, Firefox or Chrome, the problem is on your end."
In days past people would be railing against any company which pulled this stunt. Now they shrug and accept the illegal intrusion, making excuses for why this is good. I'm sure if your car dealer would randomly change things on your car you wouldn't have a problem with it either, right?
We will bankrupt ourselves in the vain search for absolute security. -- Dwight D. Eisenhower
Will people who depend on a 32 bit plug-in be able to use it seamlessly with the 64 bit Chrome? That may not be the case.
Try the login page for Tumblr.
It loads more than 20Mb of scripts and images.
Tumblr is one of the few websites that brings my tablet (2GB ram) to its knees. Infinite scrolling of an image-heavy website certainly doesn't help things.
Even those who arrange and design shrubberies are under considerable economic stress at this period in history.
What does 32 vs 64 bit have to do with security? I'm genuinely curious...
What is has to do is that the architecture that brought 64bits (AMD64), also brought several security features (like NX bit) among others.
32bits software might be targeting architecture that predate the NX bit (e.g.: if you still have an old 32bits .EXE that dates back from the Pentium 4 era, it might be writing to and executing from the same memory area), and perhaps Windows could theoretically not enable NX for 32bits legacy software on these grounds? (to avoid to break old 32bits software ?)
By accelerating the deprecation of 32bits software, they might try to deprecate the non-NX software ?
(That is pure speculation on my part. I have not enough experience with Windows)
(register vs. stack pressure is also different between the 2 architecture. AMD64, in addition to 64bits, also brought twice the number of registers. meaning that more things can be kept on CPU and less needs to be written to the stack. Which could mean less potential candidate in case of stack smashing exploit. But I'm really going on a limb here. Return address is way more interesting to abuse in this case than register value.
It's definitely less probable reason than NX).
I doubt that software would be affected easily by any other difference between the two
(e.g.: warp around at different values, 0x7fffffff vs. 0x7fffffffffffffff
That is highly unlikely : win64 is a LLP64 platform - all integers are still 32bits (both int and long), unless explicitely required (long long, hence the LL) and thus all value still wrap similarily between same source code software compiled for 32bits and 64bits.
only pointers are promoted to 64bits (hence the P) and thus only point math would wrap differently)
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Google earth is only Google application I ever wanted a 64-bit version for because I'm tired of seeing it hit 2GB process limit and promptly crash. Apparently checking memory is too hard.
Unless an app actually legitimately requires more than the 32-bit process limit I prefer 32-bit apps for the following reasons:
1. Slightly less memory overhead /w 32-bit address space.
2. No matter what a user process won't go haywire and run your system out of memory leaving your entire system in virtual memory swap hell.
On windows 64-bit for 64-bit's sake in the absence of a legitimate need to address more memory (A web browser does not constitute a legitimate need) simply because 64 is a higher number than 32 is a fruitless enterprise. All of the technobabble differences are a wash with no tangible benefit to the end user.
Why ever would you buy all that RAM and *not* want to use it?
Quite. One would hope they offer an easy "downgrade" path for those poor souls.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Now let us install Chrome (windows) on whatever drive we want instead of C:\ without having to resort to the portable version.
We've only been asking for 6 years.
This is worse
How? Please do tell.
Not asking the user's permission=BAD! Its no more Google's computer than it is Microsoft's computer! I am happier than ever that both Windows and Chrome have been kicked off of my computers and other devices!!
I read the headline this morning. On a lark, I went to look at my about page to see what I was running. Well, that prompted an update check. Sure enough, I now have 64 bit Chrome on that machine. It could be a coincidence....
You don't want more than 4GB of RAM for each, but you absolutely do want more than 4GB of virtual address space if you want ASLR to do any good.
As I understand it, ASLR is good to prevent native code execution issues. Are there actually browser issues that are can use ASLR as a viable defense against a browser exploit? It seem to me that you are in virtual-virtual address space from the point of view of JIT, and nothing would ever be in and expected location except perhaps a plug-in...
That explains a lot. Yesterday, all the extensions in Chrome disappeared. I re-added them, and it was fine. It would have been nice to have some sort of warning, or even a message saying what was done.
The article says they're doing it with the update to 58.0.3029.96 , and I just verified that's what mine is.
Next time, just ask, m'kay?
Serious? Seriousness is well above my pay grade.
Where are the nanny states decriers when the nanny is called Google or facebook?
Will people who depend on a 32 bit plug-in be able to use it seamlessly with the 64 bit Chrome? That may not be the case.
Like what? Chrome stopped supporting NPAPI plugs (e.g., Java applets) a year and a half ago. They have a "built-in" Flash player, as well, and those are probably the most popular plugins. Basically, anything you need that is still a 32-bit plugin probably already stopped working.
R.Mo
Don't get your shorts all twisted up, there.
This update is only for people who have automatic update so they have given Google permission to update their Chrome.
I don't read your sig. Why are you reading mine?
Well considering NPAPI has already been killed off, I doubt that's much of a problem.
and the developers who have to track down 32bit-only Chrome bugs :/
The exploits escape the JIT and inject native code. The native code part is much more feasible with less potent ASLR. In 4GB address space there's a way to squeeze things hard enough from the javascript end so the native code will need way less iterations to find a matching layout. Exploits do iterate over layouts, sometimes doing more than a billion iterations until they succeed - yes it takes lots of time, makes your machine run hot, and is bad user experience. That's one of the reasons for slowness of machines that are under attack but not owned yet: iterative bypasses for ASLR.
Given that all of this text is transformed into a DOM and finally display lists that then get rendered by shader code - I'd say 20MB is nothing much. It doesn't scale though, so if you had 1000 lines of text you won't suddenly have 2GB of RAM use.
Recent versions are a lot better with RAM. It still uses every available byte, but hands it back as soon as other apps start to need it by purging tabs and reloading them later.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Even flash is blocked most of the time now.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Yes. The difficult thing about code reuse attacks is that you have to find a useful bit of code to reuse. With a JIT in your target process, you can conveniently persuade it to generate some useful code that's full of gadgets. Mobile Safari combines ASLR with ARMv8's execute-only mappings to harden this: not only is the JIT'd region in a random location, its writeable address isn't stored anywhere in readable memory. They map a region write-only in one place and execute-only in another place. They then JIT a memcpy function that copes a buffer into the write-only region and throw away the address of the writable region, just keeping a pointer to the memcpy implementation in the executable region. You can use that to write anywhere into the executable region, but the only way of finding the writable region is to try writing there, which in a 64-bit address space is likely to crash the process probing long before you find the right address. Because the mapping for the executable part is execute only, you can't read it to find if a write happened to land in the writeable mapping and you can't read it to find where gadgets ended up.
I am TheRaven on Soylent News
Because eventually you don't have enough RAM to run something else than the browser.