Comment by fencepost | Hacker News Reader

Comment by fencepost | Hacker News Reader

Didn't they do some of this kind of storage crap back on 4.x? And for that matter, isn't this pretty much exactly what Microsoft was doing with Windows Phone?

My annoying use case for those was ebook readers - I have a pretty massive library of epubs (Thanks Baen Webscriptions!) and have tended to just dump a ton of them into a folder in storage on a device. I can then pull those up in CoolReader, Moon+ Reader (position sync!) or FBReader as I desire. On Windows Phone every reader app (not that there were many) had to have its own independent download because god forbid you have shared freaking storage.

Somehow I feel that this is also going to end up hitting things like third-party gallery apps such as ones that allow tagging, along with the multimedia stuff that other folks are concerned with. Oh, and music. The death of MP3s saved locally to a device and used by multiple apps?

So much of what Google has been doing with Android (turning it into a minimal platform for running the massive Google Play where all functionality lives) seems like they're heading down the walled-garden that Apple has always been, but with creepy monitoring and ad-driven revenues layered on top.

I always dismissed iOS as an option because I didn't like how locked-down it was and I really liked swipe-based input, but now that iOS allows keyboards and the locked-down aspect is happening everywhere perhaps it's time to reconsider.

Edit: removed disparagement of Windows Phone apps

I do think sandboxing the file system makes sense. I recall on early Androids just seeing an arbitrary dumpster of files on the SD card for different apps and uses, and tons of apps had access to all of them. That's concerning.

But ideally, the user should be able to create an arbitrary storage location (say, a folder), and then permit specific apps to access it, without granting the app "file system access" as a whole.

Capability-based systems with a powerbox/picker UI are designed this way, so my guess is Fuchsia will work a bit more like this.

Totally agree. It works pretty well on iOS with APFS so multiple file copies occupy the same storage space. Not sure about Android though.

That you can still do. The future notion is that that storage directory is yours, and apps don't have total access ("write anywhere, read anything, delete whatever"). FBReader cannot dump some more ebooks in that directory.

FBReader has a directory of its own, and can provide other apps with access to ebooks or other files in that directory, mediated by its own code, access-controlled as it pleases.

It doesn't sound bad to my ears, except that the APIs involved need love and attention, and their documentation even more so.

(Edit: Not picking on FBReader, just using it as an example.)

> The future notion is that that storage directory is yours

One problem is that unless I want to plug my phone into my computer each time I need to manage the storage or use the rather limited built-in file explorer, I'm going to have to use some third-party apps myself (that I have decided to be trustworthy enough) in order to manage "my" storage. From Google's point of view those apps remain third-party-apps though, and as such remain subject to some set of restrictions.

> FBReader has a directory of its own, and can provide other apps with access to ebooks or other files in that directory, mediated by its own code, access-controlled as it pleases.

I don't want my ebooks to "belong" to FBReader, though. Now yes, you can still do that as long as you only open the books from inside the respective reader apps (copy your ebooks into a general ebooks directory on the storage and then give each of your reader apps permission to access that directory), but

> can provide other apps with access to ebooks or other files in that directory, mediated by its own code, access-controlled as it pleases.

Google wants the above to be the only way to pass file references around between apps, which is stupid when a) that file doesn't actually conceptually belong to the sending app, and b) the receiving app would have had permission to access that file itself anyway.

As Google has currently implemented content://-URIs for example, even if FBReader has been explicitly granted access to my ebooks directory, if I happen to open a book from my file explorer instead, then because in that case the access is "mediated by" the file explorer, FBReader cannot reliably tell that the incoming file is actually one that is already part of its library, so I potentially end up with a duplicated LRU/history entry, my reading position might not properly remembered because FBReader doesn't know whether those two files are in fact one-and-the-same or not, and, and, and... And if I happen to switch my file explorer app and uninstall the old one, all references to files opened through the file explorer become invalid, even if FBReader had permission to directly access the file by itself, too.

I think the point you make about walled gardens needs to be addressed more than it is. It seems to have become normalized across all platforms and that is disturbing.

I fundamentally disagree with the premise of a walled garden when there are no other options to install on a device.

The web is the only freedom devs have left and even that is starting to erode - article 13, neutrality etc.

To be honest, the last freedom of small portable devices are the Pi and the NVidia cards and a build your own solution. While I understand this isn't a true replacement for a mobile, as it doesn't have access to the web everywhere, I can't seem to think of an independent alternative that hasn't been hobbled quite a bit.... plus they're pretty fun to build. You can build pretty neat ones the size of a DS that do what you want, but again, it's not a true replacement for what you're looking for. It is a hacked solution in the truest sense. =[

> On Windows Phone every reader app (not that there were many) had to have its own independent download because god forbid you have shared freaking storage.

That's not entirely accurate, even for Windows Phone at its most restrictive (7.x). The reader app would ask for storage apps and the storage apps would provide the files. It was quite common that the storage apps seemed like they would download multiple copies each file separately for each reader app, but that wasn't always the case. Unsurprisingly, some storage apps were just dumber than others.

Windows Phone 8.x and 10 opened up more direct file system access without going through an intermediary storage app, though of course possibly too late for the impression of stupid storage apps to linger.

ETA: Not that any of this currently matters given the current state of Windows on mobile devices. :(

Reply on news.ycombinator.com