[jlarocco]

> It was one of the best things that happened to Linux desktops in a long time and removing it hurts users and makes them less secure.

It would be more accurate to say it was the best thing to happen to your use of Linux in a long time, and it looks like even that is only because you're trying to use a bunch of closed source, non-cross-platform stuff.

I also disagree that it makes users less secure. The teams working on Debian, Ubuntu, Arch, etc. have much better security track records than some random web developers who've made an "app". There's no way would I trust a web based SSH client, for example.

[eeZi]

Signal Desktop and Cleanflight are open source.

And sometimes, you have no choice - there's no FOSS alternative to TeamViewer, and thanks to it running inside Chrome, I no longer have to run a Windows VM.

The web based SSH client is published by Google themselves and they use it internally.

> The teams working on Debian, Ubuntu, Arch, etc. have much better security track records than some random web developers who've made an "app".

The way things are, right now, Chrome is much better at protecting apps from each other than my Linux desktop is. If, for example, the Cleanflight or TeamViewer apps were regular apps, a bug in them would fully compromise my account.

---

Off topic remark about Linux distro security: I really like Arch, but security isn't their strongest suit. For example, they still haven't enabled full-system ASLR, citing unfounded performance concerns, when other distributions did so years ago. Even Windows with all their third party apps has a higher percentage of ASLR binaries than the average Arch system.

They also have no central build system and instead rely on volunteers who build the packages on their personal systems and sign them using their personal GPG keys.

I really want ASLR in Arch so I'll keep complaining about it publicly until it finally happens :-)

[jlarocco]

> The way things are, right now, Chrome is much better at protecting apps from each other than my Linux desktop is.

I have a hard time believing that. With a ton of stuff all running inside of Chrome, it's much easier for them to access each other's data than if they were standalone apps. Further, since Chrome is such a huge attack surface, I would expect it to be less secure than a smaller, more specific application.

On that note, I can go look at my Linux distro's security and bug tracking systems and see all of the known security issues and bugs affecting almost all of the software on my system. Does anything like that even exist for Chrome Apps?

> If, for example, the Cleanflight or TeamViewer apps were regular apps, a bug in them would fully compromise my account.

Isn't that the case whether it's a Chrome App or not? Chrome has a huge attack surface, so it seems there's an even bigger chance of hitting a bug or being affected by an exploit.

The bigger problem seems to be that you're running apps that you don't trust, while I can trust my Linux distro to have safe software in their repositories. Barring bugs, I generally don't have to worry about installing malicious applications.

I'm not sure Google does any kind of vetting for Chrome Apps, but I'm not sure I'd trust them even if they did. They are the largest ad tracking company in the world after all.

[kps]

  > I have a hard time believing that. With a ton of stuff
  > all running inside of Chrome, it's much easier for them
  > to access each other's data than if they were standalone
  > apps.

Ah, the argument from incredulity.

If you're using X11, every command with access to the display server (which is usually everything you run) can read all keyboard and pointer input and screen output and inject arbitrary input.

[jlarocco]

And? That doesn't change by running inside of Chrome.

The only reason that's even a concern is because you can't trust Chrome Apps to not be malware.

On the other hand, when I "apt-get install <some app>" I know it's not listening to all X keystrokes unless that's a legitimate part of its functionality, because I trust the Debian team to only add trustworthy software to their repos.

[AgentME]

>I have a hard time believing that. With a ton of stuff all running inside of Chrome, it's much easier for them to access each other's data than if they were standalone apps.

Chrome apps are subject to sandboxing, and regular native desktop apps (besides apps installed through OS X's app store) generally don't have any sandboxing enforced on them at all.

[jlarocco]

So people just don't understand processes and permissions any more?

[rhizome]

Your pique is noted, but as more anecdata I use Chrome Apps for Soundcloud and Mixcloud, where it's nice to have a Chrome window that won't collect tabs and have a recognizable icon. I have dozens of tabs open in each of several Chrome windows and it can be a pain to find the one I want. Insert complaint about not being able to switch to a tab from Chrome Task Manager.

[jlarocco]

I was specifically disputing the claims that Chrome Apps are "one of the best things that happened to Linux desktops in a long time" and that they're noticeably more secure.

Taking Soundcloud as an example, Clementine (and probably most media players) can stream it just fine. Having a Chrome App is nice, but it isn't providing anything that isn't already available. I'd even say the Chrome App is a step backwards, because with Clementine I don't need a separate app for every music service.

[eeZi]

Streaming means parsing a bunch of untrusted data. What if ffmpeg/gstreamer/Clementine has a security issue? It happened before.

With a Chrome App, it sits in a (really strong) sandbox and would need to escape the sandbox first.

With a native app, it's game over.

[rhizome]

The idea being that I should install Clementine to listen to Soundcloud, instead of Chrome, which is already installed? This is the only thing I would use Clementine for, since it doesn't support multiple genres per track so it's out as a music library.

[eeZi]

You can do that with regular web apps - just create a desktop shortcut in the Chrome menu ("More").