Support seeking past the end of a file in the File System Access API

[mkruisselbrink]

HIQaH! QaH! TAG!

I'm requesting a TAG review of seeking past the end of a file in the File System Access API.

Rather than rejecting when trying to write past the end of a file this
changes the File System Access spec to require extending a file with 0 bytes
instead.

• Explainer¹ (minimally containing user needs and example code): Support seeking past the end of a file. WICG/file-system-access#266
• Specification URL: https://pr-preview.s3.amazonaws.com/WICG/file-system-access/266/65e990d...882219a.html#write-a-chunk
• Tests: tests in https://wpt.fyi/results/native-file-system will be updated
• Security and Privacy self-review²: https://github.com/WICG/file-system-access/blob/main/security-privacy-questionnaire.md (no changes for this API change)
• GitHub repo (if you prefer feedback filed there): https://github.com/WICG/file-system-access/
• Primary contacts (and their relationship to the specification):
  • Marijn Kruisselbrink (@mkruisselbrink), Google, Spec Editor
• Organization(s)/project(s) driving the specification: Google/Chromiuim
• Key pieces of existing multi-stakeholder review or discussion of this specification: feature-request seek past end of file WICG/file-system-access#262
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):

Further details:

• I have reviewed the TAG's API Design Principles
• Relevant time constraints or deadlines: We hope to ship this change in Chrome 90, branching at the end of February
• The group where the work on this specification is currently being done: WICG
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): unknown
• Major unresolved issues with or opposition to this specification:
• This work is being funded by: Google

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify @mkruisselbrink

[kenchris]

@torgo and me looked at this in our TAG Virtual F2F breakout today.

Thank you for demonstrating the developer interest. The feature seems very sensible to us and we are supportive.

[kenchris]

From Blink-Dev:

Daniel Bratell:

Just curious, what happens if someone tries to exploit this by writing
very far ahead?

Austin Sullivan:

Great question, Daniel. This was brought up in the GitHub issue which requested this feature (WICG/file-system-access#262 (comment)). I'll quote the response by mek@:

Behavior wise it should be no different than calling truncate with a very large size to resize the file. For files in the origin private file system either operation will fail with a quota exceeded error (since the empty space is still counted against quota). For files on the local file system, I imagine it does indeed depend on the underlying file system implementation. It is my understanding that pretty much every major file system today supports sparse files transparently (ntfs, apfs, and most linux file systems), although I haven't tested how exactly they behave. I don't think this will reveal more of the underlying system then other operations already do.

[torgo]

It feels to me like this needs to be spelled out in the explainer and in the spec - in a privacy & security and mitigation section maybe - considering the parallels to similar exploits in other contexts.

[mkruisselbrink]

I agree that it would be good to mention something in the security considerations section around filling up storage. I filed WICG/file-system-access#277 to track that.

[mkruisselbrink]

Proposed text in WICG/file-system-access#278

[torgo]

Thanks @mkruisselbrink - given that I think we are done here and this looks like a good result. Thanks! Dan