SoylentNews is people
SoylentNews
Google Fixes White Screen Problem in Chrome, Admins Furious
For approximately 5 months, Google has been experimenting with a feature called WebContent Occlusion that hides the content of not-visible tabs so that they use less resources and cause less battery drain.
A Chrome developer stated that this feature caused no problems in their period of testing and on Tuesday morning Google quietly enabled it for users in Chrome 78 Stable release.
[...] While this feature was being tested on Chrome Beta users for some time, it was not properly tested in enterprise terminal server environments.
This became evident in Citrix or Terminal Server environments when a user locked their screen, every other user on that server would have their Chrome tabs suddenly become a white screen.
This happened because web occlusion was enabled in the browser for the locked screen and hid their browser content. At the same time, it also caused the content in tabs for every other user on the same terminal server to become hidden as well.
The only way to fix this was to unlock the screen, but this issue was constantly repeated as other users on the Terminal Server would once again lock their screen as they left their desk.
[...] After hundreds of reports from enterprise users who were affected by this, Chrome developer David Bienvenu stated he rolled back the change and disabled the feature.
For the rollback to take effect, users are required to restart the Chrome browser in order to pull down the new configuration.
Enterprise admins are furious that Google has the ability to quietly enable features in their environment without even a heads up and provide no way for admins to block these changes.
(Score: 2) by Grishnakh on Saturday November 16 2019, @06:14AM (9 children)
What kind of shitty multi-user operating system allows a userspace application program running on one user account to affect the same application program running on another user account?
(Score: 1, Insightful) by Anonymous Coward on Saturday November 16 2019, @06:41AM (8 children)
What kind of shitty application uses it's installation directory to store user settings/state instead of the OS' suggested settings location?
I wouldn't be surprised if Chrome is leaking more data between users.
(Score: 2) by maxwell demon on Saturday November 16 2019, @06:49AM (2 children)
In a properly secure operating system, even the most shitty application should not be able to do that.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by driverless on Sunday November 17 2019, @03:07AM (1 child)
Sure, but no-one wants to use XTS-300.
Or what else did you mean by "properly secure operating system"?
(Score: 0) by Anonymous Coward on Tuesday November 19 2019, @10:16PM
Windows NT, obviously; with C2 classification until it's network connected.
(Score: 2) by shortscreen on Saturday November 16 2019, @09:36AM (4 children)
*nix users can go ahead and mod me down, but I for one despise programs that silently spread junk all over my file system. It's much better when everything related to a program stays in one directory tree. Keeps things modular. Each program can be added, moved, or deleted without screwing up other unrelated things for no reason.
(Score: 3, Informative) by NotSanguine on Saturday November 16 2019, @10:56AM
A fair point. However, it seems to me that apps should use ~/.appname to store per-user configs/info and system-wide app configs/info should be in /etc/appname on *nix systems and /var/appname for runtime data. Most (but as you correctly point out, not all) applications do so.
This is approximated in Windows with %USERPROFILE%\appdata\[local|remote]\appname and %PROGRAMDATA%\appname or similar, although runtime data is generally store in the former (it's likely the latter with Chrome, causing the issue).
I'd expect you'd see centralization of such data on Windows more often than on *nix, since Windows systems are usually single-user-at-a-time environments -- except with Terminal Server.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 3, Interesting) by RamiK on Saturday November 16 2019, @07:19PM (2 children)
In Nixos everything has its own directory under /nix/store and mounted read-only. Like:
There's some generated stuff in /etc that the packages manager writes from /etc/nixos/configuration.nix. But in general, most packages have their own virtual /etc/ under their respective /nix/store directories. So, midnight commander for instance:
The dir name btw is #hash#-#package-name#-#package-version* so you can deploy multiple versions and even you own patched version of the same package and let different users use whatever they like.
compiling...
(Score: 2) by driverless on Sunday November 17 2019, @03:13AM (1 child)
In Naxos everything has its own house, usually with a view of the ocean. You can get read-only papers in the tavernas. I recommend Kostas, in Kastraki.
(Score: 2) by RamiK on Sunday November 17 2019, @09:17AM
He complained *nix are a mess since they spread around binaries, data and configurations all over the directory hierarchy. While there are some customary conventions, and there's even the FHS specs [wikipedia.org] from the linux foundations, none of it is actually part of the *nix standard. So I rebutted it by providing a counter-example which happened to be Nixos that I use on a few desktops, workstations and a server.
Sorry to have wasted your time with a technical reply when I could have just made a snarky comeback.
compiling...