I don't know; I understand the cynicism here.. But can we assume an optimistic scenario where vendors are able to properly address the security implications and this enables web developers to build all kinds of new applications? I for one would love to be able to write web applications that could, say, control the lights in my house or smart devices. I hate interfacing with my phone to control these types of actions;…
You lost me at "assume an optimistic scenario where vendors are able to properly address the security implication".
I don't know; I understand the cynicism here.. But can we assume an optimistic scenario where vendors are able to properly address the security implications and this enables web developers to build all kinds of new applications? I for one would love to be able to write web applications that could, say, control the lights in my house or smart devices. I hate interfacing with my phone to control these types of actions;…
Home assistant?, ifttt?, raspberry pi with zigbee/zwave module?, smart devices with web hooks?
You probably can control most smart devides with web apis, check out home assistant code for that... But they go to manufacturers portal.
Too bad most manufacturers have an interest in you paying them subscriptions...
"Note that this capability is already available to Chrome Apps and Extensions and in no scenario will we be handing it out like candy to any website that asks nicely; [the API] will come with a higher barrier to use." Involving Google as a gatekeeper, of course. Google is trying to establish the level of control on the Web it has on Android.
That sounds like basic security to me. Apps and extensions are already "verified as ok" by the user (whether fully informed or not) vs random websites. Not doing so sounds like a gross deficiency in access control.
"Note that this capability is already available to Chrome Apps and Extensions and in no scenario will we be handing it out like candy to any website that asks nicely; [the API] will come with a higher barrier to use." Involving Google as a gatekeeper, of course. Google is trying to establish the level of control on the Web it has on Android.
I'm thinking more like WebUSB, where there's a prompt before access to devices is given.
"Note that this capability is already available to Chrome Apps and Extensions and in no scenario will we be handing it out like candy to any website that asks nicely; [the API] will come with a higher barrier to use." Involving Google as a gatekeeper, of course. Google is trying to establish the level of control on the Web it has on Android.
Google just wants browsers to become more powerful cuz then more people will use Chromebooks. since everything can be done on a browser. Why do you think PWA's are being pushed so hard by google? So people can build PWA's that also run on Chromebooks. No need for native apps
I think chromebooks kind of pivoted and now cater to the school markets and mass deployments rather than individuals. They must have realized they're not gonna blow proprietary drivers and native x86 based archs out of water and offered the low cost wholesale devices to education. It's probably a good strategy when you get them vertically integrated with G Suite for edut (which is free) and just lure all the students in US Schools to get used to Google products instead of all schools teaching using MS Office. Long way to go before they can actually replace MS Windows, macOS for games, photo editing, video editing, coding (althought that's close) or such.
Local apps - I can install once and check signature. - I can store them in a backup for later forensics if they do something bad. - I can firewall the process only to required services. - I can disable outside network access for local process. - I can analyze what it does before and after the fact. - They can be scanned by a malware scanner / virus scanner. Web apps: - need network access to load (and probably at run…
We could bring those advantages to web apps, but there isn't money in it, so it won't happen yet.
Local apps - I can install once and check signature. - I can store them in a backup for later forensics if they do something bad. - I can firewall the process only to required services. - I can disable outside network access for local process. - I can analyze what it does before and after the fact. - They can be scanned by a malware scanner / virus scanner. Web apps: - need network access to load (and probably at run…
We could bring those advantages to web apps, but there isn't money in it, so it won't happen yet.
wouldn't that mean making them native apps, like something on top of electron?
As a gopher dweeb forced to write hackarounds like an external helper to get Firefox into Gopherspace again (either a proxy server: https://addons.mozilla.org/en-US/firefox/addon/overbitewx/ or an actual executable: https://addons.mozilla.org/en-US/firefox/addon/overbitenx/ ), I'm torn. I would love to see the browser able to speak raw TCP again like I could when XUL/XPCOM extensions were still a thing. But this shou…
The next thunderbird will contain OpenPGP support build-in because they are finally getting rid of XUL addon support and enigmail would not work with it.
Until widespread code-signing exists on the web this seems incredibly reckless to expose. Even if you require https and put it behind a modal, history has shown that both of those measures are not impenetrable barriers to attackers and raw sockets open up a whole new set of attacks. HTTPS is basically useless for authenticating dangerous code: There are thousands of https domains out there that you can easily put you…
How would code signing be helpful? How would the key end up being trusted?
I do think that content pinning/notarization of web apps could be powerful. We are building some of those ideas here but and I have an interest in how this could be used to pin critical apps to an audited/approved version: https://transparencylog.com