Add more detail to security section

[cwilso]

Perhaps some of the detail from mozilla/standards-positions#58 (comment).

[chr15m]

As per the linked discussion it might be a good idea to specifically make reference to the upload-firmware threat that Mozilla is worried about.

To address that specific concern, which is only an issue if the page wants to do 0xF0 prefixed SysEx messages, maybe it would be a good idea to add a suggestion that the user is prompted/warned. Other messages in the same range (e.g. 0xF1, 0xF8 etc.) are not a problem when it comes to this particular security concern.

[toyoshim]

The current spec already covers the case.
Any sysex won't be available by default.
Sites need to call the API with sysex option, and it results in permission prompting.

Actually the spec suggests to prompt always, and Chrome has a plan to do so in months.

[chr15m]

Thank you, yes, the current spec covers the basic case and "prompt always" is good.

However from the security perspective that Mozilla advocates it seems like the granularity of the cases in the spec is not high enough. They are worried about case (3) below where insecure user devices may be connected:

1. No-SysEx use (safe).
2. SysEx use but without 0xF0 custom SysEx messages (safe).
3. SysEx use with 0xF0 custom messages (potentially unsafe).

In my experiements the {"sysex": true} setting is required for both (2) & (3) MIDI messages. For example to enable "Song Position Pointer" (0xF2) messages in Chrome I had to pass the sysex option. SPP messages belong to (2) above.

From what I am reading from Mozilla it seems like they think situation (3) is sufficiently dangerous as to warn the user more sternly and there is nothing in the spec about this concern.

In addition it seems like (2) is closer to (1) in terms of security and functionality (e.g. SPP messages are more like note-on and control-change messages than they are like custom sysex messages). Even in the MIDI spec they are not called "SysEx" but fall in the "System Common Messages" section.

I personally do not feel the security issues raised are as serious as some people indicate on that thread, but I understand their position and I would like to see MIDI support land in Firefox.

[toyoshim]

We will clarify a sub-set of safe sysex common messages and will update the spec to explain the three level of previleges. Some platform may not support the strongest vendor/product specific messages, like updating firmware via sysex messages.

[bome]

@toyoshim that sounds fantastic! Hopefully it'll convince Mozilla that a safe implementation of Web MIDI is possible.

@chr15m, "SysEx without 0xF0" is inaccurate, please check out the MMA's classification of MIDI messages. I've just amended it with the respective status bytes to clarify. The MMA's position is that only category 5 is potentially harmful.

[chr15m]

@bome great! Thank you for this more detailed info.

[hoch]

2023 TPAC Audio WG Discussion:

• Break up the current privacy/security section into a separate section. (This is a V1 blocker.)
• Review the details provided in this issue and select the ones that are relevant to the new security section. (Not a V1 blocker, but relatively easy to do)
• Create, review, and merge a PR.

[mjwilson-google]

Here is some more information on breaking up the privacy/security section: https://w3c.github.io/documentreview/#how_to_get_horizontal_review