- The access restrictions applied to File also need to be clearly applied to Blobs created with slice().
- "modified on disk since the File object reference is created" seems incorrect.  If you structured clone a File (eg. postMessage), you create a new File object.  That shouldn't "refresh" the snapshot; you should still only be able to access the file as it was when you received the *original* File.

I'd suggest defining this more precisely, and at the level of Blob.  Here's an attempt:

- In section 6, add: "Each Blob has a snapshot state, which is initially set to the state of the underlying storage.  Note: this value is preserved through structured clone."
- Also in section 6, add: "If, at the time of any read operation on the Blob, the state of the underlying storage containing the Blob is not equal to snapshot state, the read must fail with a NotReadableError."
- In 6.3.2. The slice method, add: "Let the snapshot state of A be the snapshot state of O."  (This means the snapshot state follows through slices.)
- In 7.1, remove "For synchronous reads ...".  The requirement to fail is now defined by section 6, and the way it fails (passing on the NotReadableError or an error event) should be defined by the associated read operation.

This stores a conceptual snapshot of the underlying storage at the time the Blob (or File) is created.  The "snapshot state" is purely conceptual, representing the logical underlying snapshot that the Blob represents.  If it represents a file on disk, and the file changes (or is deleted), it has a new snapshot state.

This approach puts the requirement at the Blob level.  For Blobs whose underlying storage can never be modified (regular, old-fashioned blobs), it has no effect, since the snapshot state never changes.  The snapshot is made when the a Blob (or File) is constructed, except for slice() and structured clone, which copy the source object's state.