Slashdot Mirror
Google Chrome Requires TSYNC Support Under Linux
An anonymous reader writes Google's Chrome/Chromium web browser does not support slightly older versions of the Linux kernel anymore. Linux 3.17 is now the minimum requirement. According to a thread on the Debian mailing list, a kernel feature called TSYNC is what makes the difference. When a backported patch for the Debian 8 kernel was requested, there were hostile replies about not wanting to support "Google spyware."
This doesn't pass the sniff test. This 'bug' has apparently been around for months (October/November) and it's just now that people are noticing? And the fix is patching the kernel rather than regressing whatever change was in Chrome that added this?
Not that I was going to use a system that kowtows to RMS by calling itself GNU/Linux anyway, but the OS is there to support the software I use, and I use Chrome on Linux. If the OS won't support it, then I won't use it.
So, you tell us you are not going to use a system that you weren't going to use.
And we should give a fuck, why?
Watch this Heartland Institute video
The general issue here is that running a fairly large, popular application now requires a kernel patch that was authored by the same organization that wrote the application. Moreover, the kernel version including this patch is well newer than what's shipped by most mainstream distributions, AND the application vendor is fairly hostile to running older versions of the application software (that wouldn't require this patch).
So,
1. Vendor isn't willing to think about distribution support timelines
2. Vendor doesn't seem to care about kernel/userspace boundaries and very happily writes code on both sides to an interface they've designed themselves, for themselves.
3. Profit?
Yes, doing it this way is notably easier for Google. This is generally considered one of the selling points of a closed ecosystem: you don't have to care about little things like public interfaces and what's already in the field (and going to be there for a decade): just "move fast and break stuff" because it all works in the environment that you're testing in, and you don't much care about anything else.
Because it's yet another reason not to use them.
Disinfect the GNU General Public Virus!
LTS as a practice, is against Google's best interest - Google is attempting to leverage Chrome to turn all software into insecure, auto-update, phone home garbage - just like all other web applications. They don't want to use the workaround, they want you to update.
This is really a non-issue. Chrome decided to use a recent feature in the kernel. This happens all the time. Most distributions that are using the older kernel have patched. If Debian doesn't want to patch, move to another distribution or switch to Firefox. Both Fedora 20 and 21 are on 3.17 - so it isn't an issue there. Debian is notorious for using old stuff, so it may be the kernel they are using requires a multitude of changes and because of their policies they don't want to move to a more recent version. You buy into that logic when you choose to use Debian - so expect this stuff to happen. This has nothing to do with RMS or Google; rather the mismatch of using a slow to update distribution with a browser that is on the fast track.
To each his own.
However, for folks who want their OS to actually pay attention to their needs, it's yet another nail in Debian's coffin.
Disinfect the GNU General Public Virus!
they were able to survive without TSYNC and make it 'safe' but suddenly they can't
Geez, improving their software's security by taking advantage of better kernel support, Google really are deadbeat stupid. Better drop the sandboxing idea, have everything in the same process, preferably run as root. We'll be all safe with this old, not up-to-date version of openssl with brand new SSL3.0 support.
Chrome is by definition, spyware.
It does everything in its power to relay information about your activities back to Google, right down to what you click and when, if you allow it.
Most of these 'features' require you to opt-in, but some just happen right out of the box.
If you don't realize that the entire existence of Chrome and Chromium is to get information about you, you're an idiot with your head in the sand.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
You know what? I'm not paranoid about Google. They don't care about me individually, and I opt out of their ad targeting. The rest I just don't care about.
You're can't be paranoid about google, paranoia is thinking that someone's watching you, with Google, they boldly state they're watching you and in your case you're aware of that. I personally do care what Google knows and have taken steps to limit that significantly, by using as little of their services as possible and making tracking me much more difficult. A random Jane or John at Google shouldn't be able to tell you you're on your period this week, for instance.
The cesspool just got a check and balance.
That doesn't make sense. TSYNC is a security-enhancing feature.
Chrome uses seccomp-bpf for Sandboxing.... that is isolating certain threads from the system.
TSYNC facilitates software correctness with regards to the security. Without TSYNC, there is a greater likelihood of problems in the application leading to system compromise.
So I'm quite satisfied by Google's choice to refuse to run their browser on kernels that don't support current security features.
Firefox, Konqueror, Midori, Epihani, Opera, Arora, etc, should do the same.
Of course, they will have to implement multi-threaded Sandboxing functionality first.
I'm instead amazed by Google's arrogance in stating that RHEL 6 is "too old" for Google Chrome. It's been that way since at least last summer, so my RHEL teaching cluster and workstations just don't have chrome installed.
Actually, that's not quite true - one user manged to get Chrome working, but it regularly consumes all system resources and crashes the PC. Result.
All in all, I'm happy to do without Chrome on RHEL 6. Will I try to get it working when I roll out RHEL 7 this summer? Possibly, but moves like this make me wonder if Google's a company whose products I want to install at all. Firefox ESR may have its faults, but it basically works, and I can trust it'll stay working.
Oh arse