Re: [w3c/manifest] Adding file_handlers and launch consumer (#1005)

@marcoscaceres commented on this pull request.

Couple of drive-by comments... 

> @@ -72,6 +72,13 @@
           "ios_saf",
         ],
       },
+      localBiblio: {

Not sure you need this? `[[IANA-MEDIA-TYPES]]` is in [specref](https://www.specref.org/?q=IANA-MEDIA-TYPES), which is what ReSpec uses.

Is it not linking? 

> +          <li>Set |manifest|["file_handlers"] to |processedFileHandlers|.
+          </li>

Nit: maybe do this step last? Just feels like a nicer way to finish the algorithm... "create set, add stuff to it (maybe), add it to the processed manifest". 

> +          </li>
+          <li>[=list/For each=] |entry:ordered map| of |json|["file_handlers"]:
+            <ol>
+              <li>Let |file_handler:ordered map| be [=process a file handler
+              item=] with |entry|, |manifest/start_url|, |manifest/scope|, and
+              |manifest_url|.
+              </li>
+              <li>If |file_handler| is failure, continue.
+              </li>
+              <li>[=list/Append=] |file_handler| to |processedFileHandlers|.
+              </li>
+            </ol>
+          </li>
+        </ol>
+        <p>
+          On [=installation=], a user agent SHOULD run the process to

Hmmm... shouldn't this happen just as part of normal processing? Or, when processing the manifest, we maybe need a reason why the manifest is being processed... if that reason if for "install" or "update", this should happen. 
 



> +              |manifest_url|.
+              </li>
+              <li>If |file_handler| is failure, continue.
+              </li>
+              <li>[=list/Append=] |file_handler| to |processedFileHandlers|.
+              </li>
+            </ol>
+          </li>
+        </ol>
+        <p>
+          On [=installation=], a user agent SHOULD run the process to
+          [=register file handlers=]
+        </p>
+        <section>
+          <h3>
+            Registering file handlers

This feels a lot like registering protocol handlers in HTML... I wonder if we should consider stronger security protections here? It feels like this should be heavily restricted... particularly the MAY below seems pretty loose.  

> +            files in the host operating system.
+            </li>
+            <li>If there are multiple registered handlers for a file, the OS
+            allows the user to select which app should open it, and also allows
+            the user to set a default app.
+            </li>
+          </ul>
+          <p>
+            A user agent MAY prevent registered file handlers from registering
+            as the 'default' file handler for a given type if the operating
+            system allows.
+          </p>
+        </section>
+        <section>
+          <h3>
+            Privacy consideration: Default [=file handler=].

Nit: just as a style thing, we generally don't link things in heading. 

```suggestion
            Privacy consideration: Default file handler.
```

> +          <p>
+            A user agent MAY prevent registered file handlers from registering
+            as the 'default' file handler for a given type if the operating
+            system allows.
+          </p>
+        </section>
+        <section>
+          <h3>
+            Privacy consideration: Default [=file handler=].
+          </h3>
+          <p>
+            Depending on the operating system capabilities, the [=manifest/file
+            handler=] could become a 'default' handler (e.g. handling launches
+            of a given file type automatically) of a given [=file type=]
+            without the explicit knowledge of the user. To protect against
+            possible mis-use, user agents MAY require explicit user consent to

As above... the MAYs here feel very light for something so powerful. 

> +          `name` member
+        </h3>
+        <p>
+          The [=file handler=]'s <code><dfn data-dfn-for=
+          "file handler">name</dfn></code> member is a <a>string</a> that
+          represents a name to be provided to the user's operating system for
+          use with "Open with..." UX flows. This MAY be replaced by the user
+          agent for privacy & security reasons.
+        </p>
+      </section>
+      <section data-cite="MIMETYPE">
+        <h3>
+          `accept` member
+        </h3>
+        <p>
+          The [=file handler=]'s <code><dfn data-dfn-for=

hmm.... as you capture, the problem is that some OSs might recognize one MIME Type and another a different one. 



> +          agent for privacy & security reasons.
+        </p>
+      </section>
+      <section data-cite="MIMETYPE">
+        <h3>
+          `accept` member
+        </h3>
+        <p>
+          The [=file handler=]'s <code><dfn data-dfn-for=
+          "file handler">accept</dfn></code> member is a <a>dictionary</a>
+          mapping [=MIME types=] to a list of [=file extensions=].
+        </p>
+        <p>
+          In order to [=register file handlers=], some operating systems
+          require [=MIME types=], some require [=file extensions=], and some
+          support both. Thus websites MUST always provide both for each [=file

hmm.... as you capture, the problem is that some OSs might recognize one MIME Type and another a different one 🤔

If this information is lost on Windows anyway, can the file extension be made to win on Linux (and we use some default type)?  


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1005#pullrequestreview-854937125

You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1005/review/854937125@github.com>