Hacker News Reader

Comment by lewisl9029 | Hacker News Reader

On a slightly off-topic note, one thing I've always wanted to build and use is a web music player that plays and _syncs_ my own music collection.

Unfortunately, there doesn't seem to be a way around the fact that web apps have no persistent access to the local filesystem, and thus would have to duplicate any locally stored music in browser-based storage in order to maintain its own fully synchronized library.

I can understand why this restriction is in place as a security measure, but it significantly limits the appeal of any web app that performs any kind of synchronization of files. I sometimes wonder if persistent filesystem access is really such a huge security risk for web apps that even asking for explicit permission grants from the user and limiting access to user-specified directories is not enough to make it an acceptably secure capability for inclusion in web browsers?

View on HN

People tend to just click "yes" on confirmation dialogs, often really understanding what the question means. Now combining that with the net, where ad networks load code from other sources, which load scripts from yet other networks is a big security nightmare (we can already see how often add networks carry malware already ...)

Access to a persons files destroys all security.

I do understand why browsers would want to disallow unfettered access to the entire filesystem (and present the opportunity for the user to give too much access inadvertently), but I still wonder why even something like the non-standard Filesystem API (https://developer.mozilla.org/en-US/docs/Web/API/File_and_Di...) would choose to use a virtual filesystem as the backing store as opposed to some site-specific subdirectory in the real filesystem that the browser could control and sandbox?

Is the issue just that it would widen the attack surface too much in the event of a potential bug that could compromise the browser sandbox and/or the same origin policy? Or is there more nuance that I'm missing?

There are two kinds of problems I spontaneously see, I assume there can be found more.

For one it has to be clear to the user. Is he granting one time access or repeated access? Which sites are getting the access? Is it actually the exact page I see or some code loaded from elsewhere? etc.

The other part is the sandboxing part. Sandboxing access to file systems is hard. How do you deal with symlinks, hard links, ... (maybe there is a different vulnerability allowing to create those and both techniques together lead to an dangerous exploit?) what amount of the path name etc. are available to the application (this might i.e. link the username, which might be derived from a full name, think about /home, /Users, C:\Documents and Settings\ but might be useful to show) and then, again, the related real-life user issue: not all users have all their music in a distinct folder structure, but probably mixed with other files, and oh, they want to play the files freshly put into "Downloads", too ...

Granting such access is a can of worms ...

I haven't done it in years but I'm 87.4% certain that you can put a html file in the local folder and hardcode the relative paths. It requires some non-web software to populate it with data but since most of it is static it should work just fine?

I use to rip torrent websites by de-paginating their browsable tables of things to hold 2000 entries each and saving it as .html. The search engine got with some dumb ajax thingy that would just perform a full text search on the link.textContent.

small print: The browser would still "download" the files before you could open them in other applications.

But I'm not sure if this local file access "security hazard" got patched.

> there doesn't seem to be a way around the fact that web apps have no persistent access to the local filesystem

A local webserver and a little scripts for writing files. Plus symbolic links to your music folders maybe? I never tried the symbolic links part, but surely there is a way to make that work.

That will certainly work, but the whole appeal of building it as a web app for me is the ability to use it anywhere without any local setup or installation. If I end up having to spin up a web server locally just to run it, I might as well build it as an Electron or React Native app instead and have access to the local filesystem directly.

You could expose your library with a plex service. Now you can play it anywhere using any plex client. You could host a web client anywhere and have it play files from your local plex service (as long as the plex service is exposed to the internet)

Plex is great, but not quite what I'm looking for. Ideally I'd like my entire collection to be synchronized and available locally on any device I use, and I'd like to be able to access the local collection through a web app (and have the web app be the thing that performs the sync'ing) without having to stream it from a remote source when the entire collection is sitting right there in my device's filesystem.

All of that is very achievable, except the "web app" part. I think it might be about time for me to just give up on that pipe dream and start building an Electron and/or React Native app instead.

I’ve used google play music for a while. All my local music is automatically uploaded through its locally installed agent and available in the cloud through a user-friendly web ui. Onedrive does the same thing but the web interface is worse.

Java? Pretty sure java can access the file system from within the browser if given permission. The only requirement would be to have jre installed on whatever machine you want to use it on

Ah Java. If this was an option on mobile devices then I would have been all over it.

Reply on news.ycombinator.com