Hacker News new | ask | show | jobs
by eeZi 3310 days ago
This one I'm fine with since WebAssembly is a worthy replacement, but I'm still annoyed at Google discontinuing Chrome Apps.

Some examples of specialized apps I use all the time that would require a native app otherwise:

- Signal Desktop

- TeamViewer

- Postman

- SSH client

- Cleanflight drone configuration tool

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.

Now everyone is moving to Electron and instead of one Chrome instance, I'm now running five which use more than one GB of RAM each. Much less secure, too, since each has its own auto-updater or repository and instead of being sandboxed by Chrome's sandbox, they're all running with full permissions.

It also means I cannot longer use Signal Desktop on my work device since installing native apps is forbidden for good reasons, while Chrome Apps are okay.

It also hurts Chrome OS users since Chrome Apps are being abandoned in favor of Electron. It also makes it less useful for developers to create Chrome Apps since the market is much smaller.

Since Chrome Apps continue to be available on Chrome OS, I'm considering separating that functionality into a stand-alone runtime or making a custom build for Linux. Anyone wants to help with that?

14 comments

Your comment scared me, but TFA doesn't say that:

> We will remove support for PNaCl in the first quarter of 2018 everywhere except inside Chrome Apps and Extensions.

Where do you see that chrome apps are being discontinued? Otherwise this is FUD.

EOL for Chrome Apps outside of Chrome OS was announced in August 2016 https://blog.chromium.org/2016/08/from-chrome-apps-to-web.ht...
But OP is specifically calling out how this hurts Chrome OS, but it doesn't seem to affect that platform, from what I can tell.
One way it affects it is to reduce the overall market for Chrome apps, reducing the incentive to make an app in the first place.
Exactly. I doubt most of the ChromeApps that exist today were made for ChromeOS. They were made because it was an easy and straight forward way of making a webapp on the desktop. Now, as OP mentions, everyone is moving to Electron and NWJS, neither of which works directly on ChromeOS.

The only upside I can see is that CrOS is soon going to support running Android Apps which may save it, but even then... Maybe they'll figure out a way to run Electron/NWJS apps on ChromeOS?

This might also motivate better support for running ChromeOS apps under standard Linux.
Maybe Google is looking to run Android apps in chrome?
The massive ChromeOS market as compared to the Chrome extension app store?
OP isn't calling out how it hurts CrOS, they're describing how it's the place that Chrome Apps are still available, and thus could have that functionality copied out of CrOS and rejiggered to (continue to) work in Linux.
Deprecating it in the browser will kill any developer ecosystem. No one will write Chrome Apps anymore.
It may take a bit longer before it is disabled everywhere, but I feel like the writing is pretty much on the wall for NaCl at this point; If you develop or depend on apps that leverage it (in any context), this should probably be a warning sign to start thinking about how to sever that dependency (even if it's not urgent).
At a minimum, Postman does not belong on that list. It has been the case for quite some time now that Postman's desktop app is a) better than the Chrome App, and b) recommended by the developer.

Postman aside, I don't understand why anyone would want any of the apps you listed to be installed as a Chrome App. Why would someone want an SSH or TeamViewer client to be tied to their browser? You're installing an application either way; Chrome internalizing the process as an attempt to offer convenience is a strange idea. Chrome is a browser, not an operating system - let the OS do what it does best. Chrome Apps were an unnecessary and proprietary mess - a failed experiment I am happy to see dismissed.

Add to that list:

- unblockable advertising

- stronger DRM

- Bitcoin mining that regular user can't detect

- etc..

It will be good and bad, but, more bad than good.

We could choose not to run .exe .bat and the rest

So far, webassbly doesn't look optional.

> - unblockable advertising

Ad blockers primarily look at domains, so blocking will continue to be possible at the request level. They aren't interpreting or parsing JS to begin with.

> - stronger DRM

If sites were going to ship Web Assembly-based DRM, they would already be shipping Web Assembly along with the Emterpreter. Remember that wasm has a polyfill already. I haven't seen that happening, so I see no reason to believe it'll happen in the future.

> - Bitcoin mining that regular user can't detect

A regular user certainly would notice the 100% CPU consumption. And anyway, bitcoin mining in a WebGL shader would be more profitable than anything wasm-based.

Moreover, though, surreptitious bitcoin mining on consumer PCs would be ludicrously unprofitable no matter what. Here a Stack Overflow answer from last year that calculates how much a site with 2M daily visitors would make if they could all somehow run the fastest C implementation [1]. It was less than 50 cents a day back then, and in the meantime the hash rate has grown by nearly an order of magnitude [2]. Good luck.

[1]: https://bitcoin.stackexchange.com/a/42413

[2]: https://blockchain.info/charts/hash-rate?timespan=2years

You are right, but replace Bitcoin with the latest Fadcoin and it might get lucrative again.

One cool idea that is also gaining traction is in-browser proof of work to prevent DDOS attacks. Basically you have to perform a lengthy computation to get past the (fast, ultra-high bandwidth) firewall. Doesn't slow down the individual user much, but makes an attack much more difficult. I could imagine people using malicious JS to get these proof-of-work tokens.

But yeah, computing power in the cloud has become fairly cheap, it's really hard to see how criminals could benefit from secretly serving WebAssembly to people.

I doubt a regular user would notice 100% CPU usage and even less certain that they would know what to do about it or what was causing it. Most OSes operate chrome just fine when another process is asking for 100% as well.
Their fans running at max (or a very warm device) would let them know. This has been the experience among the non/less-technical users in my company.
You must have been working with at least quite young people or something. My experience goes the other way. I've seen people who bought a new computer because their fans were running at max and the reason for that was that they were full with dust and dog hair.
I "fixed" someone's computer that would regularly crash a few minutes after starting it by vacuuming the dust out. :)
Right, they might notice it, but why would they care? They don't know that they should care, it is just a computer being a computer and it probably spins up the fans for other tasks too. They would be right to not care unless told otherwise, sys ops isn't their job.

I think it would be smart to educate people as part of a regular security briefing for non technical staff though. But if it's something that high of concern to your company maybe an automated CPU usage monitor could alert the team to anomalies.

They would care when their laptop shuts down. [1]

[1] I was running a test today when the program being tested ran into a very tight loop and the fan really kicked in. I was curious if it would finish and let it run for several minutes until all went quiet and the screen went dark. It had shutdown to prevent heat damage.

Does battery usage not matter?
Regular users do notice things like that, they just can't articulate it. "I think my computers getting old" and "I think I have a virus" are common ways of trying to explain things like this.
I'm not sure where you're getting any of this from.

First, I don't see why you think WASM-based ads will be any less blockable than JS already is.

Stronger DRM on the web [is already a thing][1], but that has nothing to do with WASM.

Bitcoin mining on the web is already possible with JS and so far that hasn't been an issue. If it does start becoming a widespread problem though, browsers will start taking steps to combat it, like they [already have][2] for pages that needlessly consume CPU in the background.

[1]: https://www.w3.org/TR/encrypted-media/

[2]: https://developers.google.com/web/updates/2017/03/background...

> Bitcoin mining that regular user can't detect

That's actually a great idea for funding content creation online. If a site is open source, then it would even be possible to prove that only a reasonable share of the client's resources are being utilized. I'd take that funding model over the advertising-driven model that exists now.

That's actually pretty clever, but wouldn't the resource usage be insane?
> - unblockable advertising

I don't see how this necessarily follows from WASM.

WASM is aiming to be fast enough to actually be capable of running a rendering engine. No more DOM for adblockers to look at, the pages may finally become canvases.

I just cannot see this not happening.

Right, but you can already do that. Serve the whole page as a SVG, or JPEG, or PDF. You can already embed ads inline. Or just plain serve them from your own server, calling them article.jpg instead of http:://ads.adcompany.com/advertisement.jpg .

The reason people don't do this, is because ad companies want control. They want to know exactly how often the ads are served and they don't trust you to serve their ad all the time and to all customers. Also they want to rotate it quickly. Finally, they want to track people. So the solution is to use remote javascript. 99% of ads work this way, even mayor news sites don't sell their own ads anymore.

In this scheme, you'd probably still have ads served from a third party server. And even if they obfuscated the domain name, you could still probably identify their blob and block it.

So I'm not to worried about unblockable ads. But you're right, they will try, and I am worried about sites becoming unusable because they will emulate browsers using canvas, poorly.

If you run your own rendering engine you lose accessibility. If you add aria tags to stuff in order to make it accessible, adblockers will be able to read them as well.
I don't think advertisers care about accessibility. Not the same companies that want auto-starting video clips in your browser.

As for the site owners - unless it's someone large enough to care, I think the usual choice between "letting a few disabled persons access the site" and "getting a few more bucks from advertising" would be quite obvious. If that question would even arise.

Don't most ad blockers just rely on media queries on the DOM? I imagine there's a lot of ways to circumvent those techniques when you are rendering raw pixels with wasm.
Those pixels still have to go somewhere in the DOM, and clicks on those pixels still need to be handled. Plus, there's nothing wasm can render that you can't render with uglified JS already.
So I guess it's equivalent to rendering ads on a Canvas element?
>- Bitcoin mining that regular user can't detect

It makes very little sense to mine on anything other than ASICs.

Is that still true if someone else foots the power bill?
Put it this way: once you factored in the price of the bus fare to get to the public library to borrow a terminal to check your giant botnet's bitcoin earnings, your criminal enterprise would be operating at a loss.

CPU mining hasn't been viable since 2011 when bitcoin difficulty was below 1,000,000, and today it's near 600,000,000,000.

Ethereum is mined on GPUs (that's why Radeons are out of stock everywhere all the time :D)
> unblockable advertising

What do you mean?

Turn your website into an interactive canvas, basically an HTML5 Canvas game that functions like a news site, I think it would be much more difficult to block ads in this scenario. One objection is that you can already do this and we don't see it, but a counterpoint is that its a hassle at the moment, and once tooling is advanced C# to WASM compiler or something along those lines, then we'll see frameworks and then it will be pretty simple and possibly compelling... If it gives publishers more control over the experience I don't see how they could pass it up.
Agreed. WebAssembly is not a replacement; the point was not to allow to write extensions in native language, the point was to have a mechanism for escaping the browser sandbox in a controlled way.

Google could have allowed Chrome to be used as a cross-platform GUI library (THE cross platform GUI library), but left it to Electron (lagging behind and requiring distribution); think XUL runner. I don't see the sense in that. I'd absolutely love a modern XUL runner.

Postman recently released a Native App, fwiw
It's based on Electron
Don't be surprise, people consider electron "native" today.
Some people and those people are arguably wrong.

Electron is really just Chrome with a separate JS engine that can run native code if the developer chooses to do so.

Personally I'd argue that the "nativeness" of an application depends on how much the developer actually uses that ability to run native code. If you just throw a bunch of standard webapp CSS, JS and HTML in a folder and wrap Chrome around it, it's no more "native" than any other webapp. If on the other hand you have a whole bunch of native code doing, for example, media editing and the HTML and such is just the frontend UI, I'd say sure, that's a native app.

> require a native app otherwise

Oh, the tragedy /s

I'm extremely hesitant about installing random non-sandboxed applications. A Chrome app comes sandboxed with well-defined permissions. It's rare for native apps outside of mobile to come sandboxed or be easy to sandbox.
I always wonder what it is that these apps need that cannot be done as regular web apps, as the web platform has provided more and more controlled ways to break out of the browser sandbox. (This is not rethorical by the way.)
PNaCl is (or should I use "was") not limited to HTTP and can use UDP/TCP directly. So things like SSH clients are possible.
Some devs want to develop js apps without paying/maintaining a server.
Since they're just static files, that should be pretty easy to do :)
Some js apps need to work with database.

eg: I'd like to build an expense tracker with html/css/js/sqlite but I want it to be offline and the user can choose to save their db file in their dropbox/gdrive folder.

> 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.

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 :-)

> 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.

  > 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.

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.

>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.

So people just don't understand processes and permissions any more?
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.
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.

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.

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.
You can do that with regular web apps - just create a desktop shortcut in the Chrome menu ("More").
Forgive me if I misunderstand but won't android apps work on Chrome OS devices well at least the newer ones anyways?
But that's only Chrome OS.

Chrome Apps were great because they worked on all (desktop) platforms.

> instead of one Chrome instance, I'm now running five which use more than one GB of RAM each

Is that true? Executables and shared object files are supposed to share (code) memory.

So what big data structures does Chrome use that it can share between tabs (which are processes) and that it can't share between different instances of Chrome?

> Is that true? Executables and shared object files are supposed to share (code) memory.

Different version - different DLLs

Ok, so it's a version management problem then.
This is bad news. Wasn't aware.
> 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.

I will disagree, you can install most of these from the official repository of your distribution, without the use of electron. They are also very secure if you run them as an unprivileged user.

Suppose your JS Chrome App is getting the plug yanked on it, what are your alternatives?

1.) Port it to Electron and keep nearly the same code base

2.) Rewrite the whole thing as a native app in such a language as C++ without the use of Electron

You can't possibly tell me that most developers won't choose #1 instead of #2 in a heartbeat (the switching costs are orders of magnitude more for #2, for one thing). Which is not a Good Thing.

And it's also very obvious that #2 isn't nearly as secure as #1, which runs in a sandbox and so does not have direct unchecked access to users' files like #2 does.

Unless I'm misunderstanding something, an Electron app also has direct unchecked access to users' files by using the Node.js 'fs' core module.
Which option works on a chromebook?
You can as a user to just use another application.
Yes, but the existence of ssh on chrome makes it much much easier to teach a windows user how to try out the linux command line. PuTTY is annoying as hell to help a new person get working and they might not have enough space for vagrant+virtualbox.
PuTTY is annoying as hell to help a new person get working

Seriously? There are like 12389127381789 how to guides about how to do it, and it is literally like 3 steps.

Do you really think the person who has problems starting putty is going to thrive in a CLI environment?

PuTTY's UI is an ass-backward mess (and that's mildly put) and the fact that you're used to put up with it or that there exists five Knuth's arrows worth of guides doesn't change that. In fact the latter is probably a testimony of it all. I've used it for years, know it by heart, still hate it, and am pretty well served by and versed in the unix terminal universe, TY. PuTTY has been useful for sure but that was by scarcity as there was basically no alternative on Windows for a decade or more.
On windows, you no longer need either with bash for windows you can have a near complete linux experience while running inside windows natively.
If you can assure me that is the case, fantastic! Do you know of a way to test the UX of ssh from bash for windows for less than $5 ?
"Ubuntu on Windows" as they're calling it now is free, enabled via the control panel, and provides a near perfect bash experience. I use it on the desktop I built for VR to SSH into my digital ocean droplets all the time. Super easy to use, just open powershell, run `bash`, then you can run `ssh` like normal. You have access to your windows files with /mnt/c and etc. for additional drives. The only issue is that Powershell doesn't support the full gamut of colors that Bash does, but that support is coming in the fall creators update and frankly it works fine with every Vim and zsh color scheme I've tested.

10/10 developing for the web on windows is finally tolerable

I don't know enough about ssh for Chrome and bash for Windows to get your point. Isn't bash for Windows (as part of WSL?) free? What is it that costs more than $5 using bash for windows but is free with ssh for Chrome? Genuinely interested, I'm on OSX mostly but I'm WSL curious.
I interpreted that as them not having access to a Windows machine and wanting to try out the experience for themselves before attempting to teach someone else.
Git bash comes with ssh.

Cygwin has ssh as an optional install.

Msys2 too.

Of course, you need to have windows first. MS give away 30-day win 10 trial VM images with git bash installed, or at least they did.

I..should have clarified that I don't have easy access to a windows machine and don't have access at all to one that I can install stuff on.
Just curious - why do you think PuTTY is annoying?
I love PuTTY, but my best PuTTY is actually KiTTY, since it saves profiles in a local config file instead of the ominous Windows Registry. Much easier to move around :-)

http://www.9bis.net/kitty/

I wish I'd done a UI critique of it back when I was doing the relevant teaching.
If you run them as a different user from yourself, maybe, but who does that?

The idea that software is secure if it only runs on your own user account is stupid IMO. I'd rather that software had access to everything on my computer EXCEPT my personal files.

It's about restricting access: One is protecting others; The second is protection within your own realm. Both are needed (Unix was just like: At least don't touch the data / system that other users have)
Why are you using an SSH client in your web browser?
Chrome OS has no native SSH client, but Google published a NaCL based SSH client:

https://chrome.google.com/webstore/detail/secure-shell/pnhec...

It's useful outside of Chrome OS if you have a security perimeter based on TLS with ACLs and auditing already in place and you want to use it for SSH as well:

https://github.com/zyclonite/nassh-relay

https://chromium.googlesource.com/chromiumos/platform/assets...

Google uses a similar setup internally.

I wouldn't call it a "Linux Desktop" if you can't run a standard SSH client. Chrome OS is it's own beast.
I've got this crazy idea. Since "Linux Desktops" are generally running GNU under the hood for providing user land services, why don't we call those systems... I don't know... "GNU/Linux"? That way we can distinguish them from systems that use the Linux kernel, but have a completely different user land infrastructure.

I know, I know. It's crazy talk....

How many of them actually intimately use the GNU userland as opposed to Xorg and whatever libc's installed? GNU's an increasingly irrelevant portion of unix and unixlike systems -- most of the actually important userland portions are python, ruby, the aforementioned Xorg, etc.
I actually don't think you are incorrect. GNU is not nearly as big a piece of the puzzle as it used to be. It's just that when most people say "Linux Desktop", the part where they say "Linux" usually means the part that GNU makes up. As far as I know, GNU libc is still by far and away the most popular libc installed on those kinds of systems.

So it was just kind of a snarky joke because the parent said that to be a "Linux Desktop" you had to be able to get ssh running (presumably they meant openssh). And while that's not GNU, GNU is what the vast majority of "Linux Desktops" will use to get you there -- so the implication really was that "Linux Desktop" == "GNU/Linux Desktop".

I thought it was funny, but probably I was being too obscure. Also, I should know better than to dive into politics for no good reason.

> GNU's an increasingly irrelevant portion of Unix

Say what? Do you know what GNU means or what it includes? Here's a link so you can learn more:

https://www.gnu.org/software/software.html

GNU is more than a collection of programs; it's an operating system:

https://www.gnu.org/gnu/thegnuproject.html

The chance of success would be higher if the term GLX would be used: Debian GLX, Ubuntu GLX, etc.
In some ways, and if everything aligns, ChromeOS is actually better:

https://groups.google.com/a/chromium.org/d/msg/chromium-hter...

But "if everything aligns" == "only if you're inside Google".

Hah, that's a funny thread. I've heard that Google is using Chromebooks for engineers with production access.

Makes a lot of sense sense since Chrome OS is much easier to secure than a normal Linux distribution.

That sounds insane. Do you have any proof ?

Google also has goobuntu, which I'm being is what's provided to engineers.

Agreed, the SSH client is a bit of an outlier since you have that natively.

I still listed it for completeness, I do use it, after all.

In my case, because your trying to run a high school computer club, and everyone has school issued chromebooks.
You are
Have you tried simply avoiding Electron and the bloatware it encourages?
Wasn't his post arguing in favor of Chrome apps over Electron? He'd prefer to keep using Chrome apps and avoid Electron.