Re: [FileAPI] Blob.URN?

On Fri, Apr 30, 2010 at 10:39 AM, Eric Uhrhane <ericu@google.com> wrote:
> On Thu, Apr 29, 2010 at 9:01 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> On Thu, Apr 29, 2010 at 6:58 PM, Eric Uhrhane <ericu@google.com> wrote:
>>> On Thu, Apr 29, 2010 at 3:35 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>>> On Thu, Apr 29, 2010 at 3:00 AM, Robin Berjon <robin@berjon.com> wrote:
>>>>>> Though admittedly I'm biased because I'm not sold on the whole
>>>>>> FileSystem API and I don't expect anyone will step up and implement it
>>>>>> in firefox anytime soon.
>>>>>
>>>>> Care to elaborate?
>>>>
>>>> I don't see any significant advantages over the other storage methods
>>>> we already have defined for Files and Blobs, specifically localStorage
>>>> and IndexDB. And there are significant advantages of using a database
>>>> to store files. For example if you're storing emails in a database,
>>>> you can just stick the attachments as a property of the emails. And
>>>> things like filename collisions and finename charset encodings and
>>>> case sensitivity become a thing of the past.
>>>
>>> I quite agree that emails belong in a database.  But I don't think
>>> it's going to work very well for large media files.  Will you do video
>>> editing with your blobs stored in a database?  How's it going to
>>> handle overwriting just the id3 tag of an mp3 file?  Will it deal well
>>> with 10GB of BlueRay?  The most reasonable proposals I've seen for
>>> large media on top of a database effectively boil down to implementing
>>> something that looks like a filesystem on top of the database, which
>>> seems a lot less efficient than just going straight to the disk.  It
>>> also doesn't get you the interoperability with external apps.
>>>
>>>> Note that just because the APIs expose the files as being stored in
>>>> the database, doesn't mean that the implementation has to physically
>>>> store the files in the database if that is bad performance wise.
>>>
>>> Then for large media you've got to have a filesystem on top of a
>>> database on top of files.
>>
>> I think you're misunderstanding what I'm proposing as implementation.
>> When someone stores an object like:
>>
>> {
>>  from: "jonas@sicking.cc",
>>  to: "sven@swede.se",
>>  subject: "Glad Midsommar!",
>>  body: "Hi Sven, here are the pictures from the ABBA party at the
>> summer house.",
>>  attachments: [file1, file2, file3, file4]
>> }
>>
>> into an IndexDB store we can store the files (file1-file4) to the
>> users file system, but in a browser controlled folder and with browser
>> controlled file names. Then when this object is read out of the
>> IndexDB store, we'll return an object where the File objects refer to
>> the files on the file system. So any operations on those will be as
>> efficient as for FileSystem.
>
> You're right, I misunderstood.  This is a lot better than I was picturing.
> However, it's not a complete proposal; how do you want to handle
> modifying Files?

Indeed, modifying files needs to be figured out. But it's a solvable problem.

> You're still letting apps write to the filesystem.  They don't get to
> pick the filenames, but they can still write malicious payloads if
> they can find a way to execute them.  There's still some of the same
> security risk, but this rules out legitimate ways to share files with
> external apps, keeping the browser as a data silo.

It mitigates things in two ways. First off it makes it impossible for
the site to write files with .exe, and other extension that makes them
easily easily executable. Second, we can randomize the filename so
that just in case there's an exploit elsewhere in the browser which
allows sites execute a given filename, the site won't know what
filename to execute.

I'm not saying that we'll never implement FileSystem. However it's not
a high priority for us right now.

/ Jonas

Received on Friday, 30 April 2010 19:03:06 UTC