how should outstanding file-backed blobs be handled when site data is cleared?

[wanderview]

Spinning this off from some questions I had in:

https://bugs.chromium.org/p/chromium/issues/detail?id=795701

It seems over there blob were being kept alive in such a way that it prevented the storage from completing the clearing process. I think the immediate fix being worked on is to essentially make any outstanding blobs start throwing.

How should blobs work if the underlying storage is deleted?

The spec has a weak "should" stating that the snapshot state should be based on the time at which a File object was created. See the note here:

https://w3c.github.io/FileAPI/#file-section

If this is implemented then removing the file should not be visible to script. Its unclear if any browser implements this "should", though.

For blob objects that are not explicitly File objects, but are backed by a file simply by browser implementation, it seems a bit weird to me to leak that implementation detail via a disk wipe command.

Also, it seems that structure cloning a Blob or File should conceptually create a copy. It seems unexpected that modifications to the underlying storage in the original origin would be reflected in a cross-origin context that received the structured clone of the object.

Anyway, there are likely multiple issues going on here. I just wanted to file some spec issue to discuss how we think this situation should be handled for the Clear-Site-Data case.

[annevk]

w3c/FileAPI#75 and w3c/FileAPI#99 track this to some extent. Basically we need to be much more clear about Blob's lifecycle.