Kenneth: Didn't get any feedback on this one either.

David: We might need to open some issues in their github repo, per their request.

All: good point.

David: Some of these are more discussion points than issues, might be hard to frame as issues.

Peter: I'll leave this one as pending feedback for now.

Alice: David had a good point about things on the filesystem vs things fetched. ... some issues in their repo open... none of which are closed yet.

Dan: what's the implementation status?

Alice: Currently "proposed" in Chromium - under active development.

Dan: Feels like we have raised concerns, those have been listened to and issues raised...

Alice: It would ne nice to hear from David and for their issues to be closed...

Dan: Agreed.

Tess: Should we move this to breakout C, since David is unavailable this week and the other two assignees overlap in C?

Alice: Sure

Moved to breakout C.

Alice: Still pending feeback

Dan: Last comment from dbaron was happy.. fine to ask for rereview based on there being a new spec. Let's look at the status.

Dan: explainer updated

Hadley: updated of what's changed from 26 jan.

Lea: seems to have mime types and extensions linked to eachother.. what happens if you try to open a file with not the correct mime type. Shouldn't these be seperate?

Yves: for local files?

Peter: taking the extension and mapping it to a mime type...

Lea: shouldn't the extension be the key in that case...?

Peter: multiple extensions mapped to one mime type... convenient but error prone...

Lea: seems to make it mandatory to define a mime type - which is not something you need.

Peter: don't you need it when you open the file? Presuming you send it toa blob which is a mime type.

Peter: you're making the browser dispatch it - you go to the OS, double click the file, it sends you to the URL (of the webapp).

Hadley: explaienr gives an example on linux - requires all extensions to map to a known mime type... UA enforces app to only open files with specified extensions... introducing new rules...

Dan: I'm wondering about security boundary violations ...

Hadley: they want to follow users' applications... but what if it's doing something the user doesn't expect?

Dan: will review security & privacy...

Peter: the explainer says the UA can issue a permissiomn prompt....

Sangwhan: should check if this already launched.. it's shipped.

Amy: there's no s&p considerations.. a single privacy consideration.. points to File Access for lots of security stuff, which says "The API provides a lot of scary power to websites that could be abused in many terrible ways". Google doc for file handling security.

We apologize for the delay in getting to this review request. We note that it has [shipped in Chromium](https://groups.google.com/a/chromium.org/g/blink-dev/c/Wxuo4lZi4vM) but that there are so far no other implementations. Please let us know if you expect to progress this along the recommendation track at any point, and if/when other implementer interest emerges.

While the security and privacy questionnaire has responses, there are no security and privacy considerations sections in the spec itself. The responses to the questionnaire indicate how potentially private/sensitive data may be exposed, but there is little discussion of threat models or mitigations. We see this discussed extensively in [this document](https://docs.google.com/document/d/1pTTO5MTSlxuqxpWL3pFblKB8y8SR0jPao8uAjJSUTp4/edit) and it would be reassuring to see actionable considerations / tradeoffs for implementers succinctly documented in the specification itself, or at least references to other documents if that's more appropriate.

We will be happy to review further changes and additions in a new review request in future.

Amy: suggest closing satisfied with concerns