Web Midi API は、"midi" という名前で識別される強力な機能です。次の権限関連のフラグを定義することで、パーミッションに統合されます。

permission descriptor type

WebIDLdictionary MidiPermissionDescriptor : PermissionDescriptor {
    boolean sysex = false;
  };

{name: "midi", sysex: true} は {name: "midi", sysex: false} よりも強力

です。

Web Midi API は、デフォルトの許可リストが "self" である "midi" という名前のポリシー制御機能を定義します。

WebIDLpartial interface Navigator {
    [SecureContext]
    Promise <MIDIAccess> requestMIDIAccess(optional MIDIOptions options = {});
  };

requestMIDIAccess() メソッド

呼び出されると、ユーザーシステム上の MIDI デバイスへのアクセス要求を表す Promise オブジェクトを返します。

MIDI アクセスの要求、特にシステムエクスクルーシブへのアクセスは、ユーザーに対してプロンプトを出し、 MIDI デバイスにアクセスする旨の許可を得なくてはなりません(SHOULD)。 シナリオによっては、この許可は暗黙的あるいは明示的に既に得られている事もあり、 この場合にはこのプロンプトは表示されないかも知れません。 もしユーザーが承諾するか、他の手段で許可されている場合、Promise は解決されます。 必須ではありませんが、下層のシステムはユーザーが特定の MIDI インターフェースをこの API を通じて選択できるように、(個別の基準で選択して) 選ぶ事もあります。 また、システムエクスクルーシブはプライバシー情報をより多く含んでいるため、そのサポートを要求されたかどうかに応じて、 システムはプロンプトメッセージを出す(あるいは出さない)を選択するかも知れません。

ユーザーが拒否、あるいは別の理由で呼び出しが許可されていない場合、Promise は DOMException パラメーターと共にリジェクトされます。

requestMIDIAccess() メソッドが呼び出された時、ユーザーエージェントは次のステップを実行しなくてはなりません (MUST) :

1. 新しい Promise オブジェクト、promise を作成し、resolver をそれに結びついたリゾルバーとします。

2. promise を返し、以下のステップを非同期に実行します。

3. document を呼び出したコンテキストの Document とします。

4. document が "midi" という名前のポリシー制御機能を使用することを許可されていない場合は、以下の 失敗 というラベルの付いた手順に進みます。

5. 前もって行われているユーザー設定、セキュリティ上の理由、プラットフォームの制限などによって必要ならば、以下の 失敗 ステップに進みます。

6. 前もって行われているユーザー設定によって必要ならば、以下の 成功 ステップに進みます。

7. ユーザーエージェント固有の方法でユーザーにプロンプトを出し、ユーザーのMIDI デバイスの制御を表す MIDIAccess オブジェクトをスクリプトのオリジンに渡す事に対する許可を得ます。 このプロンプトの表示はシステムエクスクルーシブのサポートを要求したかどうかによる場合があり、ユーザーはアクセスを有効にするか無効にするかを選択できます。

   もし拒否された場合、下の 失敗 ステップにジャンプします。 ユーザーが応答しない場合、このアルゴリズムはこのステップに留まったまま進みません。もし許可された場合は次のステップに進みます。

8. 成功 : 新しい MIDIAccess オブジェクトを作成し、access とします。 (ユーザーへのプロンプトが複数回表示されるかも知れませんのであまり実際的ではありませんが、 requestMIDIAccess() を複数回呼び出す事は可能です。 そしてこの場合、毎回 MIDIAccess のインスタンスは同じではありません)

9. access を引数として、resolver の accept(value) メソッドが呼び出されます。

10. これらのステップを終了します。

11. 失敗 : 新しい DOMException 例外を作成し、error とします。 この例外の .name は、ユーザーまたはそのセキュリティ設定によって、要求されたオプションでアプリケーションが MIDIAccess インスタンスを作成することが拒否された場合、または document が機能を 使用可能 でないためにエラーが発生した場合は "NotAllowedError"、ユーザーのナビゲーションによりページが閉じられている場合は "AbortError"、下層のシステムでエラーが発生した場合は "InvalidStateError"、それ以外の場合は "NotSupportedError" になります。

12. error を引数として、resolver の reject(value) メソッドを呼び出します。

WebIDLdictionary MIDIOptions {
    boolean sysex;
    boolean software;
  };

WebIDL[SecureContext, Exposed=(Window,Worker)] interface MIDIInputMap {
    readonly maplike <DOMString, MIDIInput>;
  };

MIDIInputMap は、値が MIDIInput のインスタンスで、キーはその ID になっているマップ風のインターフェースです。

この型は現在使用可能なすべての MIDI 入力ポートを表すのに使用されます。これにより、次の書き方を可能にします :

// to tell how many entries there are:
  let numberOfMIDIInputs = inputs.size;
  
  // add each of the ports to a <select> box
  inputs.forEach( function( port, key ) {
    let opt = document.createElement("option");
    opt.text = port.name;
    document.getElementById("inputportselector").add(opt);
  });
  
  // or you could express in ECMAScript 6 as:
  for (let input of inputs.values()) {
    let opt = document.createElement("option");
    opt.text = input.name;
    document.getElementById("inputportselector").add(opt);
  }

WebIDL[SecureContext, Exposed=(Window,Worker)] interface MIDIOutputMap {
    readonly maplike <DOMString, MIDIOutput>;
  };

MIDIOutputMap は値が MIDIOutput のインスタンスで、キーがその ID になっているマップ風のインターフェースです。

この型は現在使用可能なすべての MIDI 出力ポートを表すのに使用されます。これにより、次の書き方を可能にします :

// to tell how many entries there are:
  let numberOfMIDIOutputs = outputs.size;
  
  // add each of the ports to a <select> box
  outputs.forEach( function( port, key ) {
    let opt = document.createElement("option");
    opt.text = port.name;
    document.getElementById("outputportselector").add(opt);
  });
  
  // or you could express in ECMAScript 6 as:
  for (let output of outputs.values()) {
    let opt = document.createElement("option");
    opt.text = output.name;
    document.getElementById("outputportselector").add(opt);
  }

このインターフェースは MIDI 入力および出力デバイスをリストアップして、 それぞれのデバイスへのアクセスを得るためのメソッドを持ちます。

WebIDL[SecureContext, Exposed=(Window,Worker), Transferable] interface MIDIAccess: EventTarget {
    readonly attribute MIDIInputMap inputs;
    readonly attribute MIDIOutputMap outputs;
    attribute EventHandler onstatechange;
    readonly attribute boolean sysexEnabled;
  };

inputs

システムで使用可能な MIDI input ports 入力ポートです。

outputs

システムで使用可能な MIDI output ports 出力ポートです。

onstatechange

新しいポートが接続された、あるいは既存のポートの state 属性が変化した時に呼ばれるハンドラーです。

このイベントハンドラーは、MIDIConnectionEvent 型に対応し、 MIDIAccess インターフェースを実装した全てのオブジェクトでサポートされなくてはなりません (MUST)。

注

このオブジェクトに EventHandler をアタッチしたままにしておくと、ガベージコレクションが行われない事に注意が必要です。MIDIAccess の使用が終了したら、onstatechange リスナーをすべて削除する必要があります。

ユーザーエージェントは、これまで有効でなかった MIDI ポートが有効になった時、あるいは既存のポートの state 属性が変化した時にはいつでも、 次のステップを実行しなくてはなりません(SHOULD) :

1. 新たに有効になったポート、 あるいはその既存のポートに対応する MIDIPort を port とします。
2. MIDIConnectionEvent の portを port に設定し、MIDIAccess で "statechange" という名前のイベントを発行します。

sysexEnabled

この属性は、この MIDIAccess 上でシステムエクスクルーシブのサポートが有効かどうかを示します。

このインターフェースは MIDI 入力または出力ポートを表します。

WebIDL[SecureContext, Exposed=(Window,Worker)] interface MIDIPort: EventTarget {
    readonly attribute DOMString id;
    readonly attribute DOMString? manufacturer;
    readonly attribute DOMString? name;
    readonly attribute MIDIPortType type;
    readonly attribute DOMString? version;
    readonly attribute MIDIPortDeviceState state;
    readonly attribute MIDIPortConnectionState connection;
    attribute EventHandler onstatechange;
    Promise <MIDIPort> open();
    Promise <MIDIPort> close();
  };

id

ポートのユニーク ID です。 開発者はこれを、ユーザーがアプリケーション内で選択したポートを記憶しておくために使用できます。 ユーザーエージェントは id がそのポートだけのユニークなものである事を保証しなくてはなりません (MUST)。 ユーザーエージェントはその id がアプリケーションのインスタンスをまたいで、 例えば、システムがリブートした時、 デバイスがシステムから取り外された時にも維持される事を保証しなくてはなりません (SHOULD)。 アプリケーションは MIDI 設定を再現するため、これらの id をローカルにキャッシュしようとするかも知れません。 システムによっては完全に永続的なユニーク性を持つ識別手段をサポートしていないかも知れず、 そのような場合、別のインターフェースが接続されたりシステムから切断された時に識別を維持し続けるのは難易度が高くなるでしょう (これによって要求されたポートのインデックスがずれるかも知れません)。 システムは MIDI API のインスタンスをまたいだポートのマッチングに最善の方法を取る事が期待されます： 例えばある実装ではポートインターフェースの製造者、名前、インデックスを何らかの形で使用したハッシュを id とし、ポートが接続された時にポートの id が一致するものを参照するかも知れません。 アプリケーションは MIDIPort の id の比較を品質のテストのために使用するかも知れません。

manufacturer

ポートの製造者名です。

name

ポートのシステム名です。

type

そのポートが入力ポートか出力ポートかを区別する識別子です。 MIDIOutput の場合、これは "output" にならなくてはなりません (MUST)。 MIDIInput の場合、これは "input" にならなくてはなりません (MUST)。

version

ポートのバージョンです。

state

デバイスの状態です。

connection

デバイスへの接続の状態です。

onstatechange

存在するポートの状態または接続の状態が変化した時に呼び出されるハンドラーです。

この "statechange" 型のイベントハンドラーは MIDIPort インターフェースを実装するすべてのオブジェクトでサポートされなくてはなりません (MUST)。

注

このオブジェクトに EventHandler をアタッチしたままにしておくと、ガベージコレクションが行われない事に注意が必要です。MIDIPort の使用が終了したら、onstatechange リスナーをすべて削除する必要があります。

open

MIDIPort に対応する MIDI デバイスを明示的に使用可能にします。 この呼び出しは MIDIPort を使用するために必須のものではない事に注意してください - MIDIOutput での send() の呼び出し、または MIDIInput に MIDIMessageEvent ハンドラーを設定する事で暗黙的に open() を実行する 事ができます。 下層の実装はこの呼び出しに対して何もする必要がないかも知れません。 しかしながら下層の実装によっては MIDI デバイスへの共有アクセスをサポートしていないかも知れないため、 明示的な open() および close() 呼び出しを使う事で MIDI アプリケーションがデバイスへの排他アクセスを予想して制御する事が可能になります。

呼び出された時、このメソッドは与えられたユーザーシステムの MIDI ポートへのアクセス要求を表す Promise オブジェクトを返します。

もしそのポートが "connected" 状態であってポートへのアクセスが取得できれば (そしてそのポートで入出力が可能になれば)、Promise はリゾルブされます。

connected 状態のポートへのアクセスができなかった場合 (例えば、排他的アクセスシステムのプラットフォームでそのポートが既に使用中になっていた場合)、Promise は(設定されていれば) リジェクトが起動されます。

もし "disconnected" 状態のポートに対して open() が呼び出された場合、 そのポートの .connectionは ポートが "connected" 状態に移行するかすべての参照が無くなるまで、 "pending" に遷移します。

このメソッドが呼び出された時、ユーザーエージェントは MIDIPort オープンのアルゴリズムを実行します (MUST):

1. 新しい Promise オブジェクト、promise を作成し、結び付けられるリゾルバーを resolver とします。

2. promise を返却し、以下のステップを非同期的に実行します。

3. port を与えられた MIDIPort オブジェクトとします。

4. もしデバイスの状態が既に "open" の場合、(例えば この MIDIPort の open() が既に呼ばれている、または暗黙的にオープンされている場合)、 下の 成功 ラベルのステップにジャンプします。

5. もしデバイスの状態が "pending" の場合 (例えば既にオープンされ、その後デバイスが切断されている場合)、下の 成功 ラベルのステップにジャンプします。

6. もしデバイスの状態が "disconnected" の場合、MIDIPort の connection 属性は "pending" に変化し、 新しい MIDIConnectionEvent が MIDIAccess の statechange ハンドラーと MIDIPort の statechange ハンドラーに発行され、 下の 成功 ラベルのステップにジャンプします。

7. システム内の MIDI デバイスへのアクセスの取得を試みます。 もしそのデバイスが使用不能の場合 (例えば、既に他のプロセスで使用されていてオープンできない、あるいは切断された場合) 下の 失敗 ラベルのステップにジャンプします。 もしそのデバイスが使用可能でアクセスを取得できた場合、次のステップを続けます。

8. MIDIPort の connection 属性を "open" に変更し、新しい MIDIConnectionEvent を MIDIAccess の statechange ハンドラーと MIDIPort の statechange ハンドラーのキューに追加します。

9. このポートが出力ポートであり、送信を待機している保留中のデータがある場合は、そのデータの送信を非同期で開始します。

10. 成功 : resolver の accept(value) メソッドを port を引数として呼び出します。

11. これらのステップの実行を終了します。

12. 失敗 : error を新たな DOMException とします。 この例外の .name はもしポートが使用不能の場合、"InvalidAccessError" となります。

13. resolver の reject(value) メソッドを error を引数として呼び出します。

close

MIDIPort に対応する MIDI デバイスを明示的に使用不能にします (この後状態は "open" から "closed" になります)。 このメソッドの呼び出しが成功すると (新しいハンドラーの設定による暗黙的な open() にかかわらず) MIDI メッセージは MIDIInputの MIDIMessageEvent ハンドラーに もう伝達されなく事に注意してください。

下層の実装はこの呼び出しに対して何もする必要がないかも知れません。 しかしながら下層の実装によっては MIDI デバイスへの共有アクセスをサポートしていないかも知れないため、明示的な close() 呼び出しは MIDI アプリケーションに他のアプリケーションにデバイスへのアクセス を取得する事が可能な事を保証します。

呼び出された時、このメソッドはユーザーのシステム上で指定の MIDI ポートへのアクセス 要求をあらわす Promise オブジェクトを返します。 ポートがクローズされた時、(つまり排他的なアクセスのシステムではそのポートが他のアプリケーションから使用可能になった時)、Promise はリゾルブされます。 もしポートが切断された場合、Promise はリジェクトされます。

close() メソッドが呼ばれた時、ユーザーエージェントは以下の手順を実行します (MUST) :

1. promise を新たな Promise オブジェクトとし、resolver をそれに対応するリゾルバーとします。

2. promise を返却し、以下のステップを非同期に実行します。

3. port を与えられた MIDIPort オブジェクトとします。

4. もし、ポートが既に閉じられている (その .connection が "closed" - 例えばそのポートがまだ暗黙的にも明示的にもオープンされていない、あるいはこの MIDIPort で close() が既に呼ばれている)場合、下の closed ラベルに飛びます。

5. もしそのポートが入力ポートの場合、次のステップに進みます。 もし出力ポートで .state が "connected" で ない場合、すべての保留されている送信データをクリアし、次のステップに進みます。 タイムスタンプが未来のシステム内に保留されている送信データはすべてクリアし、タイムスタンプが過去または現在のすべての送信メッセージの送信を完了してから次のステップに進みます。

6. 下層のシステムをオープンしているならポートへのアクセスをすべてクローズし、 下層システムのブロックしているリソースを解放します。

7. MIDIPort の connection 属性を "closed" に変更し、新しい MIDIConnectionEvent を MIDIAccess の statechange ハンドラーおよび、MIDIPort の statechange ハンドラーに発行します。

8. closed : resolver の accept(value) メソッドを port を引数として呼び出します。

9. これらのステップの実行を終了します。

MIDIPort に対応する MIDI ポートの state 属性が変化した時はいつでも、ユーザーエージェントは以下のステップを実行します (SHOULD) :

1. port を MIDIPort とします。

2. MIDIConnectionEvent の port 属性を port に設定し、MIDIPort で statechange という名前のイベントと、MIDIAccess で statechange という名前のイベントを発行します。

WebIDL[SecureContext, Exposed=(Window,Worker)] interface MIDIInput: MIDIPort {
    attribute EventHandler onmidimessage;
  };

WebIDL[SecureContext, Exposed=(Window,Worker)] interface MIDIOutput : MIDIPort {
    undefined send(sequence<octet> data, optional DOMHighResTimeStamp timestamp = 0);
    undefined clear();
  };

WebIDLenum MIDIPortType {
    "input",
    "output",
  };

WebIDLenum MIDIPortDeviceState {
    "disconnected",
    "connected",
  };

WebIDLenum MIDIPortConnectionState {
    "open",
    "closed",
    "pending",
  };

MIDI メッセージを受信した時、このインターフェースを実装したイベントオブジェクトが、MIDIInput の onmidimessage ハンドラーに渡されます。 DOM Event の timeStamp 属性は DOMHighResTimeStamp として定義されていて、イベントが受信または送信された時刻を高い分解能で表すことに注意してください。

WebIDL[SecureContext, Exposed=(Window,Worker)]
  interface MIDIMessageEvent : Event {
    constructor(DOMString type, optional MIDIMessageEventInit eventInitDict = {});
    readonly attribute Uint8Array? data;
  };

data

1 つの MIDI メッセージのデータのバイト列を含む Uint8Array です。

WebIDLdictionary MIDIMessageEventInit: EventInit {
    Uint8Array data;
  };

新しいポートが使用可能になった時、(例えば MIDI デバイスが最初にコンピューターに接続された時)、 以前使用可能だったポートが使用不能になった時、または再度使用可能になった時、 (例えば MIDI インターフェースが切断され、再度接続された時)、 このインターフェースを実装したイベントオブジェクトが MIDIAccess の onstatechange ハンドラーに渡されます。 また (もしあれば) そのポートを参照する全ての MIDIPort の onstatechange ハンドラー にも渡されます。

MIDIPort が "pending" 状態にあり、そのデバイスがホストシステムに再接続された時は、statechange イベントが 発行される前に MIDIPort オープンのアルゴリズムが実行され、 再オープンを試みます。 もしこの遷移が失敗した場合は (例えばそのポートが下層システムの何かで予約され使用できないなど)、 接続状態は "closed" に遷移し、そうでなければ "open" に遷移します。 これはそのデバイスの状態変化の statechange イベント発行に先立って行わます。そのためイベントではデバイスの状態と同様に最終的な接続状態を反映します。

下層のシステムによってはデバイスの接続状態に関するイベントを提供しない場合があります。そのような システムでは新しいデバイスをまれにしかポーリングせず、大きなディレイが発生するかも知れません。 このような事情で、接続イベントに大きくは依存しないほうが良いでしょう。

WebIDL[SecureContext, Exposed=(Window,Worker)]
  interface MIDIConnectionEvent : Event {
    constructor(DOMString type, optional MIDIConnectionEventInit eventInitDict = {});
    readonly attribute MIDIPort? port;
  };

port

接続または切断されたポートです。

WebIDLdictionary MIDIConnectionEventInit: EventInit {
    MIDIPort port;
  };

懸念される攻撃として、理論的には USB-MIDI デバイスに対する悪意のあるファームウェアの更新があります。USB デバイスは一般的にその USB デバイス自身が送信するデバイス記述子に基づいて動作します。もし、USB-MIDI デバイスのファームウェアが記述子を書き換えられるなら自身をヒューマンインタフェースデバイスとする事が可能です。これにより、悪意のある Web サイトからのキーボードの入力の読み取りや挿入、あるいはシステムの完全な侵害に繋がります。

攻撃は以下のように進められます :

1. 悪意のあるサイトはユーザーを騙し、Web MIDI のパーミッションを付与させます。
2. 悪意のあるサイトはユーザーのマシンに接続されている MIDI デバイスを列挙し、脆弱なデバイスを特定します。
3. 悪意のあるサイトは、あらかじめ作成された一連の MIDI メッセージを脆弱なデバイスに送信し、ファームウェアを上書きして USB 記述子にヒューマンインターフェイスデバイスを追加することでデバイスを侵害します。
4. 侵害されたデバイスはキー入力を挿入して、事前に作成されたセキュリティ エクスプロイトをダウンロードまたは複製し、それを実行して、システムを侵害します。

上記の攻撃を可能にするには、MIDI デバイスが以下の条件を すべて 満たしている必要があります。

• 悪意のあるファームウェアに対して脆弱な事。次の条件がすべて真である必要があります :
  • ユーザーがプログラム可能なファームウェアを搭載している事。多くの MIDI デバイスには再プログラム可能なファームウェアが搭載されています。搭載されていないデバイスは脆弱性がありません。
  • MIDI メッセージの送信によるファームウェア更新を許可している事。多くの MIDI デバイスは、システムエクスクルーシブメッセージを使用してファームウェア更新を実行します。これは、システムエクスクルーシブメッセージの一般的な使用方法です。非システムエクスクルーシブメッセージを使用してファームウェア更新を実行するデバイスを作成することは技術的に可能ですが、これは非システムエクスクルーシブメッセージの本来の使用法ではありません。他のデバイスでは、帯域外 USB 通信を使用したり、ファームウェア更新を実行するためにユーザーがストレージ デバイスを MIDI デバイスに直接接続したりする必要がありますが、これは Web MIDI API を使用して実行できないため、脆弱性はありません。
  • デバイス上での明示的なユーザー操作なしでファームウェアの更新を許可している事。ファームウェアの更新を開始するためにユーザー操作を必要としない MIDI デバイスの存在は知られています。ほとんどの MIDI デバイスでは、ユーザーが最初にボタンを押し続けるかメニューでオプションを選択するなどして特別な更新モードにする必要があり、攻撃者がユーザーを騙して協力させない限り、脆弱ではありません。
• USB-MIDI デバイスである事。近年の MIDI デバイスのほとんどには USB MIDI インターフェイスがあります。一部の古い MIDI デバイスにはシリアル接続しかなく、この攻撃は有効になりません。
• MIDI デバイスのファームウェアは、USB コントローラーのファームウェアを変更できる事。多くの MIDI デバイスには、メインのファームウェアから指示できない USB コントローラーのファームウェアがあり、この攻撃は有効になりません。

悪意のあるファームウェア更新に対して脆弱であっても、他の条件を満たしていない MIDI デバイスは、この攻撃でホストシステムを侵害するために使用することはできません。悪意のあるファームウェア更新によって、これらの MIDI デバイスが動作を停止したり、望ましくない動作をしたりする可能性はあります。

このリスクを軽減するため、実装者は実装の際に次の点を重視しなくてはなりません :

• requestMIDIAccess() のアクセス許可プロンプトの文言などで、ファームウェア更新のリスクをユーザーに通知する方法で実装します。
• セキュアコンテキスト仕様に基づいて実装し、ユーザーが起動する正当なファームウェア更新の改竄を防ぐ。
• ほとんどのファームウェア更新ではシステムエクスクルーシブメッセージが使用されるため、必要な場合にのみシステムエクスクルーシブメッセージを要求するように、sysex パラメータを指定どおりに処理します。

既知の MIDI デバイスのリストにより明示的に許可またはブロックすることも、この特殊な攻撃の軽減に貢献するかも知れませんが、多くの小さな企業や個人が MIDI デバイスを開発しており、多くの MIDI デバイスが既にサポートされていないため、これを行うと Web MIDI API の使いやすさが大幅に低下するかもしれません。

利用可能なポートを識別するフィンガープリントの問題とは別に、MIDI メッセージの送受信に関する問題もあります。これらの問題については、以下でさらに詳しく説明します。

MIDI メッセージは、システムエクスクルーシブメッセージと、ショート (非システムエクスクルーシブな) メッセージに分けられます。システムエクスクルーシブメッセージは更に、一般的に認知されている MIDI タイムコードや MIDI サンプルダンプスタンダードなどのユニバーサルシステムエクスクルーシブメッセージと、他のデバイスには適用されない "Roland Jupiter-80 シンセサイザー用のパッチコントロールデータ" などのデバイス固有メッセージにさらに分けられます。

セキュリティ上の懸念について議論する前に、これらの機能を使用して MIDI でどのようなシナリオが可能かを調べると役立ちます :

• MIDI デバイスからのショートメッセージの受信 - これにより、キーボード、ドラムパッド、ギター、ウィンドコントローラー、DJ/コントローラーリストコントローラーその他などからの入力を取得し、それらのメッセージをもって楽器や Web Audio API の機能、およびその他の制御シナリオの入力として使用できます。MIDI は、プロ/プロシューマー向け オーディオおよびメディアアプリケーションと Garageband などの民生用アプリケーションの両方で、ノブやボタンなどの物理コントローラーをコンピューターに接続するために、数十億ドル規模の音楽制作業界で選ばれているプロトコルです。
• MIDI デバイスにショートメッセージを送信する - ハードウェアシンセサイザーなどの出力デバイスを接続するシナリオは今日の市場ではそれほど一般的ではないため、送信はそれほど重要ではないと言いたくなります。これに対する大きな例外は、多くの MIDI コントローラーがインジケーター照明の外部ホストコントロールを備えていることであり、これにより MIDI コントローラーは大幅に便利になります。たとえば、非常に人気のある Novation Launchpad コントローラーは、送信された MIDI ノート オン/オフ メッセージを使用して、ボタンのオン/オフと色の変更を行います。ほぼすべての DJ コントローラーにも同じことが当てはまります。
• システムエクスクルーシブメッセージの送受信 - ハイエンドハードウェアデバイスとのより高度な通信には、システムエクスクルーシブメッセージが必要です。一般的な MIDI コマンドの一部も、ユニバーサルシステムエクスクルーシブメッセージとして送信されます。たとえば MIDI マシンコントロール (一般的な開始/停止/巻き戻し/早送りコマンド) などです。多くのデバイスは、デバイス固有のシステムエクスクルーシブメッセージを使用してパッチをプログラムしたり、高度なコントローラメッセージを送信したり、ファームウェアをダウンロードしたりします。これらは Web MIDI で非常に求められているシナリオです。1 つの "メッセージ" に多くのデータを詰め込むことができるため一部のデバイスは、システムエクスクルーシブを直接制御プロトコルとして使用します。また、ほとんどのデバイスは、システムエクスクルーシブを、パッチや構成情報を安価なコンピュータストレージに保存および復元する方法として使用します。大手音楽ハードウェアメーカーのいくつかは Web MIDI を使用してハードウェアに Web ベースの構成およびプログラミングインターフェイスを提供することに強い関心を示しています。簡単に言うと、システムエクスクルーシブを全て無効にすると、ハイエンドのシナリオが無効になるだけではありません。

それぞれの潜在的なセキュリティへの影響は次のとおりです :

• MIDI デバイスへのショートメッセージの送信 - ノートオン/ノートオフ/コントローラーメッセージを送信すると (Mac および Windows では) デフォルトの仮想シンセサイザーも含み、接続されたデバイスで音が再生される可能性があります。 これ自体は、懸念される露出を引き起こすものではありません - 既に <audio> や Web Audio を介して操作なしで音の生成は可能です。 接続されたデバイスの中には、プロ仕様の照明制御システムがある場合があり、ステージ照明を制御することが可能ですが、これはまれであり、ショートメッセージのみに基づいて永続的な損害や情報漏洩を引き起こす可能性のあるシステムは知られていません。 最悪の場合、悪意のあるページがライトを点滅させ、ユーザーがページを閉じて照明コントローラーをリセットする可能性があります。 ショートメッセージの送信に関する懸念は、オーディオ出力に似ています - ユーザー情報を上書きしたり、ユーザー情報を露出したりすることはできませんが、音を発生させたりパッチを変更したり、(まれな構成では) 照明を切り替えたりすることができます - しかし破壊的なものではなく、永続的でもありません。
• MIDI デバイスからのショートメッセージの受信 - ノートオン/ノートオフ/コントローラーメッセージの受信では、識別的なデータではなく制御メッセージのストリームのみが受信されるため、情報の漏洩やセキュリティの問題は発生しません - これらはすべて、その MIDI デバイスでユーザーが起動する必要があります (クロックタイプのメッセージを除く)。これはキーボード、マウス、モバイル/ラップトップの加速度計、タッチ入力、またはゲームパッドのイベントを読み取るのと類似しています。追加的な情報は露出せず、クロック信号以外のすべてのメッセージはユーザーが起動する必要があります。
• システムエクスクルーシブメッセージの送受信 - これは最大の懸念事項です。 システムエクスクルーシブメッセージに対するシステム固有の応答を探すコードを記述して、使用可能なハードウェアを識別し、それをデータ (例えばサンプラーに保存されている音声サンプル) のダウンロードに使用できます - またはそのデータを入れ替える (サンプルデータやパッチデータを消去するなど) 事もできますが、それでもこれらのシナリオでは特定のデバイス向けにコーディングをする必要があります。 一部のサンプラーでは、システムエクスクルーシブメッセージによりサンプルの録音を開始することもできます - そのため、サンプラーに専用のマイクが接続されていた場合 (実際にはまれですが、可能です)、特定のデバイス向けに固有のコードを記述して、短いサウンドサンプルを録音し、ユーザーの介入なしにネットワークにアップロードすることもできます。 デバイスからオーディオをストリーミングすることはできません。 また、ほとんどのサンプラーのメモリはかなり限られています。 また、MIDI サンプル ダンプ sysex は、7 ビットにトランスコードする必要があり、データ転送に時間がかかるため長時間録音することは難しいでしょう。 パッチ情報/保存されたサンプル/ユーザー構成によってシステムを一意に識別できるため、より明らかにフィンガープリントが懸念事項です。 この場合も多くのデバイス固有のコードが必要になります。 標準化された "すべてのパッチを取得してハッシュする" 機能はありません。 これは、システムエクスクルーシブメッセージは独自のセキュリティカテゴリにあることを示唆しています。 このような潜在的な可能性は低く、ユーザーセキュリティフックをより慎重に提供するために、API で SysEx の要求を区別することは良い考えであると思われます。 提案されたセキュリティモデル ではユーザーエージェントが MIDI デバイスへのアクセスを許可する前にユーザーの承認を要求することを明示的に許可していますが、現時点ではユーザーにこの承認を求める必要はありません。 ただし、その要求の一部としてシステムエクスクルーシブのサポートを要求する必要があることも詳しく説明されています。