#390: Native File System API
Discussions
2019-07-10
Dan: danger will robinson
Hadley: [danger noises]
Dave: 5th time?
Hadley: would lukasz be interested in joining?
Dan: this might have privacy issues.
Lukasz: yes.
[milestone set for 3 weeks
2019-07-31
Kenneth: Apart from contentious parts, API seems nice. Filed a few issues; haven't gotten response yet. Spec seems early, they want an origin trial soon. Spec just has API, not a whole lot of other info there.
Sangwhan: The API itself is fine -- the "just a javascript API". I'm not entirely convinced about the mitigations that are in place to prevent terrible things happening to your home directory. The getDirectory method seems (missed).
Sangwhan: API surfce seems fine. Alternative proposal from another chromium person that might change it a bit; seems like improvement, but not that significant a change.
Sangwhan: alternative is what Kenneth linked to: https://github.com/WICG/native-file-system/issues/19#issuecomment-490579093
Lukasz: Questions as well about aspects in security & privacy quesstionnaire. Would be nice if they clarify. They say they encourage UAs to protect access to file based sensors, i.e. special files like /dev/something, but little clear on that. They also say API will behave differently in PWAs. I my view this is probably among the first such approaches, if not the first. Would be reasonable to have a close look at that. We did not receive feedback, bump?
Alice: They also requested github issues in their repo; they might not be tracking comments in our issue.
Hadley: Naive question: why is this useful to take out of the UA and status quo for the way things are done and put into this set of defined APIs? That is, what's the benefit of standardizing this rather than having the UA handle things as done now.
Sangwhan: Not there now.
Kenneth: Today you can get a handle in indexed db. Today you can't build something like Visual Studio code on the web.
Sangwhan: Supposyou wanted build a web app that handled a 100mb file-- can't do incremental updates today.
Alice: Somebody file an issue on their repo to sugest adding those examples directly to their explainer (multi-file editor, large file)
Sangwhan: It's there (multi-file editor), in the goals section.
Alice: large file isn't.
Alice: And seems like the words could be fleshed out a bit.
Hadley: I don't see a use case described in this explainer; it's a bunch of functionality. Not written to say what the problem for the user is.
Lukasz: persistent access to filesystem -- user gives permission for persistent access to directory. Visits site again, no permission prompt. Streamlining access to the file system. Yes, possible Privacy issue. How to mark that this kind of access is actually being retained?
Peter: That you can send a handle through postMessage also scares me.
Kenneth: only on same origin, right?
Peter: checking
Kenneth: Other point, could only access handles in specific cases. Not really writtten here, but was told that's the idea.
Sangwhan: One question I did have: any way to do equivalent of mmap -- I think the answer is no.
Kenneth: file an issue?
Sangwhan: So what do we think about this?
Hadley: At a bare minimum would like the explainer to explain use cases more.
Lukasz: mmap would also access /dev/ filesystem?
Sangwhan: /dev/ filesystem is out of scope... says so in the spec... or maybe the explainer?
Lukasz: I asked them in the this ... not really clarified.
Sangwhan: I think "encouraged" is too weak. I'm also uncomfortable going to a point outside of your home directory -- should be as restrictive as possible.
Lukasz: Not only too weak, but also not being written anywhere. Even that would be scary.
Kenneth: Lukasz, could you file your issue on the repo?
Lukasz: I ??? my question but received no response.
Kenneth: Yes, but you should file it in their issue tracker.
Lukasz: ??? these kinds of answers in their issue tracker.
Sangwhan: I put it in there.
Kenneth: Add "in response to" so we get a link back?
Sangwhan: done
Peter: more to discuss with this issue?
Hadley: I'm opening an issue on their repo about the explainer.
Kenneth: I already did.
David: Are browsers going to be willing to ship this given security risks?
Sangwhan: Should it be PWA-only?
Kenneth: Get a modernized API if not a PWA -- but can't store handles in IndexedDB. How it's going to be implemented in Edge and Chromium.
Kenneth: The other thing, not implementing this all at once in Chrome, staged rollout. Would be nice to know what's in what stages, and what we should be concentrating on.
Sangwhan: I'm also concerned about exclusive access -- multiple tabs operating on the same file at once.
Kenneth: Have ??? about that. They're copying files unless you set specific markers "in place" etc.
Sangwhan: Does "in place" twice reject, lock, etc.?
Kenneth: How does that interact with native apps doing the same?
Sangwhan: Can use OS-level functionality.
Kenneth: file an issue.
Sangwhan: Did you already file it?
Peter: What to do with the issue? Pending feedback at this point? Kick it out a few weeks?
Kenneth: seems to be moving slowly.
Sangwhan: 3 weeks?
Kenneth: TPAC?
Sangwhan: Haven't followed up on issues they've filed themselves. Downprioritized? Vacation?
Peter: 4 weeks then?
2020-02-17
[some discussions on covid-19 and impact on next f2f]
Sangwhan: general binary blob access - a filesystem - is useful. or do developers want access to "the" filesystem - which is a can of worms.
Dan: agreed it's a can of worms - interested to see what this proposed design is...
[bumped to f2f and dan will try to get more info about the mdn survey
OpenedJun 24, 2019
こんにちはTAG！
I'm requesting a TAG review of:
Further details:
You should also know that...
As mentioned above, we fully expect to be iterating on the best shape of this API for at least the duration of the origin trial (i.e. most of 2019). We have some idea of what we want the API to look like, and what use cases we want to support, but also expect to learn from the origin trial that perhaps we were wrong about what is needed for which use cases.
We'd prefer the TAG provide feedback as (please select one):