From Chrome Apps to the Web • Hacker News Board

Re: From Chrome Apps to the Web

#71

Post by catdog » Sat, Aug 20, 2016, 12:21 AM UTC

seanwilson wrote: post #69

catdog wrote: post #64

Earlier quoted context omitted.

Most importantly, as a user, don't install programs which can't be trusted because sandboxing is no magic bullet and will never be. In addition to that better redirect the work that would go into these browser features to improve the native sandboxing mechanisms of the operating systems.

> Most importantly, as a user, don't install programs which can't be trusted because sandboxing is no magic bullet and will never be. Perfect is the enemy of good! It's better than the alternative and that's all that matters.

Sure nothing is perfect and I did not say that we shouldn't improve sandboxing but I do not think that moving everything into the browser is the better alternative. The problem doesn't get easier only because it's in the browser and as a nice topping every random website is now free to try to break the sandbox.

Re: From Chrome Apps to the Web

#72

Post by comex » Sat, Aug 20, 2016, 12:35 AM UTC

tdicola wrote: post #63

jwmerrill wrote: post #49

Earlier quoted context omitted.

The article mentions using Electron or NW.js if you want to continue building apps on web technologies that need deeper platform access. Is there a reason that those are worse options than Chrome apps?

It's possible but it's not an easy switch. And god help you if you have to mix native code with Electron. Getting a node-gyp toolchain spun up on Windows is a complete and total nightmare. Add Electron and its very specific version of Node into the mix (which totally confused node-gyp) and it's really awful.

There's also the alternative of switching to a Chrome extension, no?

Re: From Chrome Apps to the Web

#73

Post by JoshTriplett » Sat, Aug 20, 2016, 12:38 AM UTC

fabrice_d wrote: post #43

JoshTriplett wrote: post #38

Earlier quoted context omitted.

> - Full TCP/UDP socket support (AFAIK this is never coming to the web platform) While it could never be allowed unconditionally (because it allows scanning internal networks), I don't see any reason it couldn't be allowed with a permission request.

Asking a end user if foo.com should be allowed to open a TCP connexion to host:port makes no sense. 99.999% of users can't make an informed decision, and they just want the damn to work so they choose "allow". Never ask users questions that they can't reasonably answer, ie don't do what android did for a long time (looks like this has been improving since N). Maybe the case of TCP/UDP could be improved by showing a h…

You can't reasonably limit access to a specific host anyway, because DNS allows you to point a hostname to any IP; once you have permission to access a hostname that you control DNS for, you can connect to any arbitrary IP address, including LAN addresses. (You could slightly mitigate that by blocking RFC1918 private addresses and localhost, but then you couldn't build clients to talk to such servers.)

As another alternative, which would allow applications like mail clients, SSH clients, VNC clients, and similar, you could treat Internet connections like the web treats file-pickers today: ask the browser to prompt the user for one, and get handed a connection, without the ability for the site to set the target. Combine that with persistence ("allow the site to connect to this host again in the future without prompting?"), and you could easily connect to the handful of servers a user wanted to connect to. That wouldn't let you build a web-based BitTorrent client or similar, but it'd solve many of the problems people want arbitrary connections for.

Re: From Chrome Apps to the Web

#74

Post by zmanian » Sat, Aug 20, 2016, 12:50 AM UTC

I suspect many people will migrate to electron instead of web apps. APIs for USB and Bluetooth and the isolation offered by Chrome apps have no equivalent in extensions / web apps

Re: From Chrome Apps to the Web

#75

Post by kzahel » Sat, Aug 20, 2016, 12:55 AM UTC

errozero wrote: post #48

kzahel wrote: post #35

Earlier quoted context omitted.

This is the free version: https://chrome.google.com/webstore/detail/jstorrent-lite/abm... It's just not searchable in the store by default.

Is this your app?

yep!

Re: From Chrome Apps to the Web

#76

Post by fokz » Sat, Aug 20, 2016, 1:06 AM UTC

holtalanm wrote: post #57

Why does this feel like they are just giving the finger to ChromeOS users? So basically, we have an OS that will only run chrome apps, and they are removing the ability to create chrome apps. I'd be more okay with this if they gave ChromeOS the ability to install and run an .apk. Does no one see a problem with this?

Developers can continue to build Chrome apps and eventually Android apps for Chrome OS, when Google Play store is brought to Chrome OS. However, I agree there is the problem of losing incentive to maintain a native Chrome app from the developer POV.

Re: From Chrome Apps to the Web

#77

Post by Longhanks » Sat, Aug 20, 2016, 1:09 AM UTC

seanwilson wrote: post #58

catdog wrote: post #56

Earlier quoted context omitted.

Websites with hardware access? what could possibly go wrong? Browsers already are a overly complex security nightmare. Moreover the recent example of this stupid but rather simple battery API has shown us several, some more and some less obvious ways of how it can be abused. But sure Google will implement WebUSB and all sort of other shit they may imagine, the others will follow as always. In the end the browser will…

What's the alternative? If an app needs such functionality to work and it cannot work within a browser, the user will have to install a native app which aren't nearly as well sandboxed right now (Windows, Mac, Linux).

UWP is sandboxed, Mac App Store apps are sandboxed, Mac apps from outside the store can opt-in to sandboxing, flatpaks are sandboxed, snaps are sandboxed.

In terms of maturity, all of these techniques are probably more mature than any WebUSB/Browser hardware access thing/abysmal-of-the-day.

Re: From Chrome Apps to the Web

#78

Post by shams93 » Sat, Aug 20, 2016, 1:13 AM UTC

bwang29 wrote: post #2

Discloser, developer of Polarr for Chrome here https://chrome.google.com/webstore/detail/polarr-photo-edito... To us as developers, the biggest advantage of Chrome Store is discoverability, reviews, and store front organizations. As a fairly new developer, we also have a web app, but it is late in the game and there is no way to out-SEO the existing players through Google Search. Chrome Web Store was the place where…

If I were in your shoes I'd look at going hybrid Android since recent chrome devices are getting Android apps.

Re: From Chrome Apps to the Web

#79

Post by glenstein » Sat, Aug 20, 2016, 1:29 AM UTC

niftich wrote: post #13

The headline is very non-specific. Here's what's going on: In a multi-stage, two year effort, the Chrome App Store is being deprecated on Windows, Mac, Linux, but not ChromeOS. They're asking people to migrate to websites/webapps instead. Extensions and themes are unaffected. By 2018, only ChromeOS will be able to run apps in the Chrome App Store.

Forgive my ignorance, but isn't the Chrome App Store also the place where you get extensions?

Presumably there will still be some centralized place to get extensions.

Re: From Chrome Apps to the Web

#80

Post by niftich » Sat, Aug 20, 2016, 1:37 AM UTC

glenstein wrote: post #79

niftich wrote: post #13

The headline is very non-specific. Here's what's going on: In a multi-stage, two year effort, the Chrome App Store is being deprecated on Windows, Mac, Linux, but not ChromeOS. They're asking people to migrate to websites/webapps instead. Extensions and themes are unaffected. By 2018, only ChromeOS will be able to run apps in the Chrome App Store.

Forgive my ignorance, but isn't the Chrome App Store also the place where you get extensions? Presumably there will still be some centralized place to get extensions.

Yes, but extensions are unaffected. This is about 'apps' from that same store.