101–110 of 155 posts
Earlier quoted context omitted.
In plenty of countries iPhone has 0% market share, the local companies don't care about iPhone support.
Name one.
https://leftronic.com/android-vs-ios-market-share/
Here a device atlas (2019) with plenty of countries for you to play with,
https://deviceatlas.com/sites/deviceatlas.com/files/images/m...
Earlier quoted context omitted.
Exactly, the focus must be on trying to mitigate it, not make it more easier.
Should they block online email providers too because someone might send a phishing email?
Earlier quoted context omitted.
Running a browser from the downloads directory is unlikely to work correctly on macOS.
It’s funny you say this, because I did exactly this yesterday. I downloaded chromium and forgot I had not yet dragged it to my applications folder and I was running it for a few hours out of my downloads folder.
I’d feel safer if all applications could only access files tagged with an unique ID for the application. But then applications will start asking access for all of $HOME and we’re back to square one
I think it's absolutely fantastic, and users love it too - it gives them exactly what they expect from IDE-style software in the browser, such as "Save as" to any location on disk, and the ability to use folder-based projects (that are spread across multiple files).
The security concerns are obviously important but I'm pretty confident it's largely mitigated through the permissions model (which is similar to one Windows Store apps use). Also as noted elsewhere, existing web features already allowed reading files and even entire directories; the writing files part is new, and you cannot choose system directories, or ask for too much (e.g. root of the user directory).
So in short I think this is great news for the web and a big step towards allowing web apps to reach parity with desktop/native apps, while managing to do it in a reasonably safe way.
Earlier quoted context omitted.
It appears I could use this to ask a victim to "select your downloads folder" to save files to and then steal or overwrite any file in it.
If the permissions system in place is clear and potent enough, I don't see the problem. You can also ask people to simply download and install an app that can do whatever it wants. It's 2020 and we still can't build web apps that can read and write to local files. Browsers are no longer useful just for reading text.
Previously if you wanted filesystem control you had to trick a user into downloading something. With this API, it seems like it would be easier to con unsuspecting users into granting permissions they aren't aware they're granting.
Earlier quoted context omitted.
>So in essence, all this new API is mostly buying you is offline mode. There's been, for a long time, local storage APIs. This is filesystem access, which is very different.
I think adding a virtual file system to the local storage API's might be fine. One which cannot be mounted easily by non-technical users but has a viewer which allows dragging files into and out of it.
> BrowserFS is an in-browser file system that emulates the Node JS file system API and supports storing and retrieving files from various backends.
https://github.com/jvilk/BrowserFS
It supports storage backends such as: in memory, LocalStorage, IndexDB, HTTP, or the FileSystem API.
Earlier quoted context omitted.
It’s funny you say this, because I did exactly this yesterday. I downloaded chromium and forgot I had not yet dragged it to my applications folder and I was running it for a few hours out of my downloads folder.
Google Chrome ships in a DMG, doesn’t it? This means that if it is running out if your downloads folder, it’s not subject to the things that would mess it up because you dragged it there.
