Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

From Chrome Apps to the Web

blog.chromium.org

Post reply on HN
Print view View original

61–70 of 111 posts

Re: From Chrome Apps to the Web

#61

Post by seanwilson »

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…

> Maybe the case of TCP/UDP could be improved by showing a human readable version of the prompt for some well known ports. So a browser would ask "Do you allow webmail.com to use a secure IMAP connexion to mydomain.com?" when webmail.com requests access to mydomain.com:993

Such prompts are going to be super confusing to the majority of users. What is IMAP? What does secure mean? What's a port?

I don't have a solution; I think it's really difficult and interesting problem. For example, you might think a game shouldn't require any permissions, but then it might need internet access to upload scores, access to your address book to invite your friends to play etc. I can't see any easy solutions how you can check the app isn't using these permissions in a malicious way.

Re: From Chrome Apps to the Web

#62

Post by tdicola »

ulber wrote: post #60
tdicola wrote: post #23

This is going to be really annoying since hardware access from HTML5 is still very rough and not even standardized. Stuff like talking to a serial port isn't even on the radar (so good luck programming a board like BBC micro:bit, Arduino, etc. without a native app), and efforts like WebUSB are still extremely early and not even a full standard. I feel like the product managers making this decision are completely obli…

The BBC micro:bit happens to be a bad example, since the editors [1] are exactly web apps with no hardware access. The editors compile the code in the browser and provide the ARM binary as a .hex file that the user downloads onto the micro:bit, which is a USB mass storage device. [1]: https://www.microbit.co.uk/create-code

Yeah but not every board can do USB storage bootloader, and there are troubles with it like ignoring Mac OSX .DS_store files, etc. Been there, done that, USB mass storage bootloading kinda sucks.

Also if you load stuff like MicroPython on the micro:bit you can't access its serial REPL from the web. That sucks, plain and simple.

Re: From Chrome Apps to the Web

#63

Post by tdicola »

jwmerrill wrote: post #49
tdicola wrote: post #23

This is going to be really annoying since hardware access from HTML5 is still very rough and not even standardized. Stuff like talking to a serial port isn't even on the radar (so good luck programming a board like BBC micro:bit, Arduino, etc. without a native app), and efforts like WebUSB are still extremely early and not even a full standard. I feel like the product managers making this decision are completely obli…

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.

Re: From Chrome Apps to the Web

#64

Post by catdog »

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

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.

Re: From Chrome Apps to the Web

#65

Post by tdicola »

sowbug wrote: post #51
tdicola wrote: post #23

This is going to be really annoying since hardware access from HTML5 is still very rough and not even standardized. Stuff like talking to a serial port isn't even on the radar (so good luck programming a board like BBC micro:bit, Arduino, etc. without a native app), and efforts like WebUSB are still extremely early and not even a full standard. I feel like the product managers making this decision are completely obli…

Did you place a bet on this technology? Tell us about it.

I didn't personally but there's stuff out there like chromeduino and Codebender that could be broken by this: https://chrome.google.com/webstore/detail/chromeduino/dmkinc... or https://chrome.google.com/webstore/detail/codebender-app/mag...

Re: From Chrome Apps to the Web

#66

Post by xpaulbettsx »

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.

Nah, it's not that hard, not sure why you had so much trouble

Source: Have written many many Electron node modules

Re: From Chrome Apps to the Web

#68

Post by Navarr »

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?

Chrome Web Store will continue to exist for ChromeOS.

The Google Play store is also coming to ChromeOS.

Re: From Chrome Apps to the Web

#69

Post by seanwilson »

catdog wrote: post #64
seanwilson wrote: post #58

Earlier quoted context omitted.

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

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.

Re: From Chrome Apps to the Web

#70

Post by notatoad »

seanwilson wrote: post #40
skybrian wrote: post #37

Earlier quoted context omitted.

Why do you say "lack of notice?" This is the notice. Maybe it's surprising news, but nothing is actually changing today.

Four months notice to be told there's no point releasing a Chrome packaged app you might have been working on (which may not work as an extension) isn't very much notice.

Four months is plenty of time to repackage a chrome app into electron or something.
Post reply on HN