bump

Dan: reprises the convo in breakout C

Lea: this is important - parity with native platforms -

Yves: we didn't say rule it out - but trying to get others (even apple and mozilla) to figure out a way to make acceptable for the user... how to design it properly?

Lea: maybe a different level of permission dialog... shouldn't be on the same level of notifications

Dan: or geolocation...

Lea: although i'm not sure that "show file picker" needs to be behind that...

Peter: i think you have to have a picker... file or directory...

Lea: then there is very clear user action...

Peter: moving talks about origin file system ...

Lea: this model of having APIs live on the general web and trying to get web apps to compete with native apps... clearly not working. Maybe this needs to be solved on the architectural level. Explicit user action "I want to "

Dan: i think it's explicit. .. but maybe worth revisiting.

Peter: i don't ever want a web app to have unfettered access to my entire filesystem... even native apps are getting locked out by OSs in some cases... this is somewhat scoped... there are things like file pickers... once the user has picked a file or directory then the app can inetract with that directory. If the move api can only access directories that the user has previously allowed then that's OK.

Hadley: user need?

Dan: one of the documented user needs is moving or renaming a big video file...

Hadley: i can see about renaming... don't know about moving files though.

Yves: during the call we discussed if renaming could restrict to same directory only...

Lea: i think web apps should be able to do things that other apps do.. right no the arch doesn't allow for this.

Peter: I agree - and - I think native apps have too much freedom. The web is a different conetxt. There is the guarantee of the UA providing a sandbox.

debate on the nature of the web and the nature of nature

Hadley: I agree with Peter's point, but also.. example of google doc on a native word processor, saving a document to local disk is trivial... on a web based word processor it's not, since you have to download the file to downloads folder and then move to the right directory in the OS (outside of the web).. as a user that's frustrating...

Lea: input type=file... hack... it's bad for accessibility...

Peter: there is a show open picker API .. what does that not give you that that hack does?

Yves: negative standards position from Mozilla on this one.

Dan: explainer and spec points to PRs which is making things difficult.

Yves: this is local file system...

Yves: Webkit position is negative as well...

discussion on whether this is OPFS or not

Sangwhan: the use cases are in explainer

Dan: Security Consideration - how does a site gain explicit write access to a file? I'm very concerned about security mitigations...

Yves: it's not only ststem files... directories in home directory that set environemntal variables etc... Lots of data writable in user directory. Once you know you're in a safe environment then move() is a no-brainer but ...

Sangwhan: There is this

Dan: "might want restrict" is loosey-goosey

Yves: "default download" is difficult - you may have sensitive info such as statements from your bank...

Sangwhan: move can be a destructive operation...

Dan: we previously reviewed https://github.com/w3ctag/design-reviews/issues/390 and this became native filesystem?

Sangwhan: yes. Positive. There were multiple iterations... we arised issues. they addressed our feedback. Not everyone in TAG was happy. But we discussed it as a group and decided it was probably OK.

Dan: concerns about mitigations in file system access...

Yves: having user agent showing you files in your directory... but doing the same from javascript is very different because you're already leaking some information. Unless there are good security requirements -enforceable security aspects in the spec. Move() is not really the issue...

Hi @a-sully - thanks for this. We're reviewing today and noting that this is built on top of File System Access which we previously [reviewed positively](https://github.com/w3ctag/design-reviews/issues/390).  Can we set up a session where y'all join us to discuss the security issues, abuse cases, and potential mitigations?

Sangwhan: is there a way to have secure file access besides OPFS? It seems to me the answer is no. Philosophical question ...

... for this API to enable malware then the malware would have to access on the disk. Even OPFS if you have a file handle you can push malware.

Yves: recommendation of multi-stakeholder support and that includes security aspects because that's where apple and mozilla have issues as well... If we fix the security aspect - won't be easy but it's doable - then it will provide lots of benefit.

Sangwahn: Expresses concerns about this pushback... I don't see how the issues can be mitigated...

Dan: I will follow up.

Dan: I think Sangwhan was going to talk to the developers about strengthening the language around threats and abuse cases so let's wait until he updates us on that.

we discussed some issues the current state of the review and process - e.g. lack of an expaliner and any prviacy & security considerations section

Dan: back and forth on security concerns. Maybe worth putting this into the issue. In the explainer it says user agents are recommended to perform checks on files moved. There's no spec, only an explainer. S&P considerations is in another spec somewhere else.

Dan: leaves comment

Dan: asking for clarity about distinguishing between local file system and Bucket file system. Does it add additional security guarantees for the local filesystem?

Sangwhan: what do normative security guarantees look like in a spec? Eg. if you say the UA must detect malware that's a wide net...

Dan: the user agent must not allow files to be moved into protected directories

Sangwhan: that's defined

Dan: it was not normative

Sangwhan: you'd have to ensure that the spec is always up to date to the OS specs. That becomes a bigger spec than the spec itself..

Dan: I don't think the spec needs to normatively define every location which is a protected directory. How does this make it clear to implementers that they must implement protections against this being used to manipulated files in protected areas? Arguably things like the downloads directory is a protected area, as Peter was mentioning. Can we ask them to strengthen the language? Based on this change they've made, which is great, that they can differentiate - what does that enable them to do to allow for protecting users? I can just ask that.

Sangwhan: fine to ask. It's difficult to define normatively.

Dan: response from them..

Yves: I think other browsers won't support because they won't want to give access to filesystem outside of bucket file system in general...

Dan: My suggestion is to close this at the plenary with "satisfied with concerns" - specifically the concern about multi-browser support.

sets to proposed-closed

mv *.zig # for great justice chown us:us *.base

Dan: Still pending...

bumped 2 weeks

Sangwhan to reach out

Dan: Some new comments from @a-sully. They have addressed many of our concerns - in particular with regard to security considerations. There is still a multi-stakeholder issue because webkit and mozilla both oppose. The issue not to do with the move capability itself but the whole concept of access to local file system.

Dan: My proposed closing comment follows:

Dan: Suggesting satisfied with concerns result.

we agreed to close