21–30 of 115 posts
This is a great idea and will mean that many Electron applications can just run much more securely as plain web applications.
This could be a great way to allow Web apps to talk to native apps. At Folding@home our client software uses a Web frontend. This frontend talks to the native Folding@home app at localhost over a socket. The problem is that browsers are starting to show security warnings for any non-https traffic and it's not possible to securely give the native app a valid SSL certificate. Reading and writing shared files would let…
But if you stick with the HTTP listener, as someone else mentioned, while you're installing your app, you can edit the user's host file to add a domain name to the loopback adapter, and then you can also create a one-off SSL cert for the computer.
Is this API needed? I understand the benefits, but web apps or Chrome extensions that _really_ need file access can already use the Native Messaging API and ask the user to install a native app, like here: https://a9t9.com/kantu/x#fileaccess The advantage of an explicit app installation is that users/companies that want to avoid such file access (and the many other things that native apps can do) can simply avoid/blo…
This could be a great way to allow Web apps to talk to native apps. At Folding@home our client software uses a Web frontend. This frontend talks to the native Folding@home app at localhost over a socket. The problem is that browsers are starting to show security warnings for any non-https traffic and it's not possible to securely give the native app a valid SSL certificate. Reading and writing shared files would let…
You can't get a certificate for localhost, but you can get one for foldinglocalhost.com and resolve that to 127.0.0.1.
Is this API needed? I understand the benefits, but web apps or Chrome extensions that _really_ need file access can already use the Native Messaging API and ask the user to install a native app, like here: https://a9t9.com/kantu/x#fileaccess The advantage of an explicit app installation is that users/companies that want to avoid such file access (and the many other things that native apps can do) can simply avoid/blo…
In a lot of use cases, all you really want is a simple way to read and save a small blob of data.
But to achieve this today you would have to do one of:
- Save it in local storage, but lose their data if they clear it or use another device.
- Build out a REST API backend, but need to also build auth and account management.
- Use a backend as service such as firebase, but still costing you to store the data.
- Use a filepicker api to save to the user's cloud storage. For example Google Drive has a file picker: https://developers.google.com/picker/. But not everyone use the same cloud drive (icloud, dropbox, onedrive, etc).
With local file access, it's more or less the same as the filepicker api solution except they are free to save it to a non-syncing file location too if they choose.
If you could write an executable file, you could make a compiler in browser JS.
Earlier quoted context omitted.
> I would rather see a sandbox approach that restricts the locations and types of files that can be read and written. Which is exactly what is in the security proposal linked at the bottom of the article.
Thanks for pointing that out. I missed these 2 items on first glance. Limiting access to certain directories: https://github.com/WICG/writable-files/blob/master/EXPLAINER... Limiting write access to certain file types: https://github.com/WICG/writable-files/blob/master/EXPLAINER... FWIW: On the surface, this appears to contradict the following quote from tfa: > ...ensures that the user is always in full control over…
This is a great idea and will mean that many Electron applications can just run much more securely as plain web applications.
One of the great things about browsers is the way you can trust them to be reasonably sandboxed from the rest of your machine. Features like this chip away at that trust model and open up new attack vectors against unsuspecting users. I get the usability benefits, but the security implications are scary. How easy would it be to trick my mother into uploading her profile picture and have the site change that file into…
For this, the browser must make all the traditional OS interfaces available. It has interfaces for accelerated 2D and 3D graphics, audio, USB, process management (workers), networking (including peer-to-peer), and a number of persistence mechanisms. But before it takes over completely, it has to interoperate with the host OS a bit, too, by exposing the filesystem.
(A decade more, and maybe the vision of Inferno [1] will sort of kind of be implemented.)
[1]: https://en.wikipedia.org/wiki/Inferno_(operating_system)