Persistent blob urls

[petkaantonov]

Update: See https://gist.github.com/petkaantonov/37a9c64ea2bbd1aa3ca5

Currently blob urls don't persist between browser restarts / page refreshes etc so the user has to add same files to the app over and over again everytime the app is started.

For certain kinds of apps it is necessary to be able to create a persistent blob url. For instance a media player app that has access to the media files the user has added to the app so they don't have to keep readding the files (possibly thousands) every time the app is started. Duplicating copies of the files in FileSystem or IndexedDB is out of the question as this duplicates possibly gigabytes of data which takes a long time, wastes a lot of storage and hits limits quickly.

Reading

I suggest a method like URL.createPersistentObjectUrl is added. The url is valid as long as the original file exists in exactly same location with exactly same attributes and contents as they were when the URL was created. When the file is modified, moved or altered in any way, the url should become invalid (perhaps URL.isPersistentUrlValid can be used to check it?). This can be probably done just by checking the last modified attribute.

Writing

One could also be allowed to write to a valid persistent object urls by sending binary data as a POST request to the url. However, every time such a POST request is made, the browser should prompt the user for confirmation that "the app wants to modify the flie at [path], is this ok?". Also such requests should probably only be allowed to made in response to user event like click. After successful write, the browser should update the persistent object url to match the new file attributes and contents that were updated.

Security considerations

As far as I can see, this should not give the app access to any more information than existing APIs already give.

[annevk]

It seems better to just store the files in FileSystem or IndexedDB and let the browser worry about deduplication. That's what we recommend elsewhere.

[petkaantonov]

Deduplication is absolutely required, not an optional optimization that browser could do if it wants. And it doesn't address the writing part, which is better experience than downloading, browsing and clicking the file to replace.

Edit: Actually I need to question how is such an optimization even possible since you just give IndexedDB a blob of bytes, it isn't going to crawl my hard disks to find a file whose contents match exactly those bytes and have the entry refer to that file...

[petkaantonov]

A chromium developer said that what is proposed here is fundamentally impossible with IndexedDB.

I also don't see anything about FileSystem API that deals with references to actual files in the actual file system like File objects behave currently. What is proposed is File objects current behavior retained across refreshes and browser restarts (protected with e.g. ctime attribute), this is nothing like the FileSystem API.

[petkaantonov]

Even more reasons why IndexedDB cannot be used for this https://code.google.com/p/chromium/issues/detail?id=476959#c6

I also found out that even the current temporary blob urls already have to check for file modifications and deny access, so that is not a new security issue for persistent blob urls after all.

[annevk]

This repository is not actively maintained as far as I know which makes adding new features unlikely. Especially features that extend a feature nobody is a big fan of.

[petkaantonov]

Well, I don't care for the API if that's what you mean. Just the capability. It could be done through indexeddb or service worker, as long as the capability is there.

[chaals]

It is maintained, although perhaps not as actively as the world (or I) would like.
Whether a given feature request is going to be met or no is therefore an open question - there is no need to summarily dismiss them.

(And suggesting nobody is a big fan of a feature that people are making feature requests against seems to be jumping the gun…)

[petkaantonov]

It could even be an entirely new api. E.g. a very lightweight FilePointer object that can be used from FileReader and which does similar bookkeeping as Blob URLs with regards to outside modifications so that the app has no access to new information. You could then persist it in IndexedDB which wouldn't have to care about the actual file semantics, because only the pointer is part of the transaction not the File itself.

There are so many cases where this would give much better UX than is currently possible for no additional security issues that aren't already there. Like any app that could do edits on a file, you would no longer have to save a new copy every time. Say rotating an image, you would just rotate it and be done. You wouldn't have to open 'save as' file browser and find out where the old image was and overwrite it etc. Then there is the media library case I already mentioned.

[petkaantonov]

Ok screw blob urls :) I have better idea I think. I wrote a rough outline here: https://gist.github.com/petkaantonov/37a9c64ea2bbd1aa3ca5

[inexorabletash]

Closing this out then.