File Handling

[fallaciousreasoning]

Góðan dag TAG！

I'm requesting a TAG review of:

• Name: File Handling
• Specification URL: N/A
• Explainer
• Tests: N/A
• Primary contacts: @fallaciousreasoning @raymeskhoury

You should also know that...
The spec isn't written yet, so this is more of an opportunity to review the proposed API.

Further details (optional):

• I have read and filled out the Self-Review Questionnare on Security and Privacy. The assessment is here.
• I have reviewed the TAG's API Design Principles

We'd prefer the TAG provide feedback as (please select one):

• open issues in our GitHub repo for each point of feedback
• open a single issue in our GitHub repo for the entire review
• leave review feedback as a comment in this issue and @-notify @fallaciousreasoning @raymeskhoury

[hober]

Hi,

Thanks for bringing this review to us. We're trying to require all requests for review to have considered the questions in our security & privacy questionnaire. Please let us know via a comment here when you've run through the security & privacy questionnaire and can share your findings with us.

Currently, your explainer mentions several previous attempts at addressing this use case on the web, but it doesn't consider why the previous attempts failed, nor does it say what makes this new approach more likely to succeed. For instance, registerContentHandler was dropped due to a lack of multi-implementor interest. Why not just resurrect that, since there is now apparently interest from a different vendor from last time?

[fallaciousreasoning]

Updated with a link to the security & privacy questionnaire.

[fallaciousreasoning]

I’ve expanded the section on why we can’t use registerContentHandler.

See here

[fallaciousreasoning]

Hey, just wondering if you folks need anything else from us before the review?

[kenchris]

The launch event seems to happen in the service worker and be called "launch", but in the explainer you are handling this from the main document with the "load" event. So would both options be supported? and how would that work? Maybe worth adding to the explainer

Also it is probably useful to be able to deal with this in the service worker, for instance, clicking on a calendar url (webcal like) you might not actually want to open that but just show a notification that that calendar has been added.

[dbaron]

I'm looking at this with @kenchris in a breakout at the TAG meeting right now.

One thought is that there seem to be a bunch of similarities between handling a file with a given MIME Type (or extension) that's already stored locally, and handling such a file that the user has downloaded from the web. That is, if your app can handle application/atom+xml off the local filesystem, it can probably handle that off of the Web too -- and maybe that should just work automatically without anything substantial needing to be done, if at that point it's the local application handling application/atom+xml. On the other hand, one thing in the past that's led to overuse of registerProtocolHandler is that there are cases where file type handlers want the URL of the resource rather than the current representation of it. In other words, many handlers for application/atom+xml probably want to be able to re-fetch the feed at arbitrary later times rather than being concerned with just the current contents of the feed. Maybe we've already settled on using the hack of registerProtocolHandler with a fake protocol for that -- but it's a pretty unpleasant hack. (That is, webcal is really just http, but the fake protocol was invented to allow certain HTTP resources to be dispatched by-URL (rather than by-representation) to an app that handled calendars.)

At the very least, it seems like perhaps the explainer should talk a little bit more about how this gets used both for already-local files and files coming from the web -- but it would also be interesting if there were a better solution for the "want the URL rather than the representation" problem.

[dbaron]

Another question is that of permissions. It seems like at some point the browser probably wants to ask the user for permission as to whether they want this particular installed web application to be able to access a particular file on the native file system. At the very least, it seems like a risk if there's no permission prompt anywhere in the system -- and it it at least seems like it might be easier to explain that stuff to users at use time rather than at registration time (since it's not clear that it's easy to explain to a user what a application/foo file is). This leads me to two thoughts:

• the dependency on the native file system API might be a barrier to adoption by other browsers -- it might be that other browsers might be interested in implementing something with this set of capabilities but nonetheless aren't willing to implement the native file system api. (I'm not at all sure about this -- just speculating without having given it a lot of thought -- although I think there's a bunch of resistence to the native file system API.)
• it's a little concerning that there doesn't appear to be asynchronous stuff in the explainer that gives a UA that wants to prompt the user for permission to have an opportunity to do so. Perhaps that's OK because the native file system API is sufficiently asynchronous to give the UA a chance to ask for permission through its API surface -- but it would be good to see examples in the explainer that show at what points a UA might choose to ask the user for permission.

[dbaron]

@kenchris also brought up the issue of what happens when multiple web applications register for the same extension and/or MIME type. It seems like many OSes have some sort of chooser model for that (which often have features such as remembering the choice). Will this be able to integrate well with such OS choosers? Or would it be problematic for the browser to register multiple web apps with different names and icons into such a chooser?

[kenchris]

@fallaciousreasoning @raymeskhoury the above is more like a discussion and thus not filed as issues on your repo. It would be great if you could have a look!

[raymeskhoury]

Sorry for the delay! Thanks for having a look and pinging! @mgiuca is actively working on this - Matt, could you take a look with @fallaciousreasoning ?

[mgiuca]

I haven't had a chance yet. Sorry. I'll try to get to it this week and file bugs on the repo for any appropriate issues.

[dbaron]

@alice and I just looked at this quickly during the Cupertino face-to-face. It looks like there's stuff happening as of the last few days, and we'd probably like to take another look at the explainer once these additions/clarifications are made. So we'll leave this as pending external feedback for now.

[evanstade]

Updated spec link: https://wicg.github.io/manifest-incubations/#file_handlers-member

[rhiaro]

We apologize for the delay in getting to this review request. We note that it has shipped in Chromium 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 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.