Web MIDI API

Web Midi API は、強力な機能であり、 名前 "midi" によって識別される。これは、 次の権限関連フラグを定義することで、 Permissions と統合される：

権限記述子 型

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

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

Web Midi API は、 "midi" という名前のポリシー制御 機能を定義し、それは 'self' のデフォルト 許可リストを持つ。

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

requestMIDIAccess() メソッド

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

MIDI アクセスを要求することは、特に System Exclusive アクセスが 要求されている場合、MIDI デバイスへのアクセスについてユーザーに確認を求めるべきである （SHOULD）。一部のシナリオでは、この権限がすでに 暗黙的または明示的に付与されている場合があり、その場合、このプロンプトは 表示されないことがある。ユーザーが明示的な許可を与えるか、呼び出しが 他の方法で承認された場合、提供された Promise は解決される。 基盤システムは、この API に公開する特定の MIDI インターフェイスをユーザーが選択できるようにすることを選択してもよい （すなわち、個別にインターフェイスを選択する）が、これは 必須ではない。システムはまた、 System Exclusive サポートが要求されているかどうかに基づいて プロンプトを表示する（またはしない）ことを選択してもよい。これは、 System Exclusive アクセスが、より大きなプライバシーおよび セキュリティ上の影響を持つためである。

ユーザーが拒否した場合、またはその他の理由で呼び出しが拒否された場合、 Promise は DOMException パラメーターで拒否される。

すべての提供された Promise がまだ settle していなくても、 requestMIDIAccess() を複数回呼び出すことは 許可される。

requestMIDIAccess() メソッドが呼び出されたとき、ユーザーエージェントは 次の手順を実行しなければならない（MUST）：

1. promise を新しい Promise オブジェクトとし、 resolver をそれに関連付けられた resolver とする。

2. promise を返し、次の手順を 非同期に実行する。

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

4. document が 使用を許可されていない場合、 ポリシー制御 機能である midi を、下の failure とラベル付けされた手順へジャンプする。

5. 任意で、たとえば以前に確立されたユーザー 設定、セキュリティ上の理由、またはプラットフォームの 制限に基づいて、下の failure とラベル付けされた手順へジャンプする。

6. 任意で、たとえば以前に確立されたユーザー 設定に基づいて、下の success とラベル付けされた手順へジャンプする。

7. エントリースクリプトの origin に、ユーザーの MIDI デバイスに対する制御を表す MIDIAccess オブジェクトを提供する許可について、ユーザーエージェント固有の方法で ユーザーに確認を求める。この プロンプトは、 System Exclusive サポートが要求されたかどうかに依存してもよく、そのアクセスを有効または 無効にすることをユーザーに許可してもよい。

   許可が拒否された場合、下の failure とラベル付けされた手順へジャンプする。ユーザーが決して応答しない場合、この アルゴリズムはこの手順を越えて進行しない。許可が 付与された場合、次の手順を続行する。

8. success：access を新しい MIDIAccess オブジェクトとする。（ requestMIDIAccess() を複数回呼び出すことは可能である。これはユーザーに 複数回プロンプトを表示する可能性があるため、ベストプラクティスではない場合があり、 MIDIAccess の同じインスタンスが毎回返されるわけではない。）

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

10. これらの手順を終了する。

11. failure：error を新しい DOMException とする。 この例外の .name は、ユーザーまたはそのセキュリティ設定が、 要求された options で MIDIAccess インスタンスを作成することをアプリケーションに対して 拒否した場合、またはエラーが document がその機能の使用を許可されていないことの結果である場合、 "NotAllowedError" であるべきであり、ページがユーザー ナビゲーションのために閉じられようとしている場合は "AbortError"、 基盤システムが何らかのエラーを 発生させた場合は "InvalidStateError" であり、それ以外の場合は "NotSupportedError" であるべきである。

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

WebIDLdictionary MIDIOptions {
  boolean sysex;
  boolean software;
};

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

MIDIInputMap は、値が MIDIInput インスタンスであり、キーがその ID である maplike インターフェイスである。

この型は、現在利用可能なすべてのMIDI 入力 ポートを表すために使用される。

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

MIDIOutputMap は、値が MIDIOutput インスタンスであり、キーがその ID である maplike インターフェイスである。

この型は、現在利用可能なすべてのMIDI 出力 ポートを表すために使用される。

このインターフェイスは、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 入力ポート。

outputs

システムで利用可能なMIDI 出力ポート。

onstatechange

新しいポートが接続されたとき、または既存の ポートが state 属性を変更したときに呼び出されるハンドラー。

このイベント ハンドラーは、型 MIDIConnectionEvent であり、 MIDIAccess インターフェイスを実装するすべてのオブジェクトでサポートされなければならない （MUST）。

注記

このオブジェクトにEventHandler を接続したままにすると、そのオブジェクトが ガベージコレクトされなくなることを理解することが重要である。 MIDIAccess の使用を終えたら、 すべての onstatechange リスナーを削除するべきである。

以前は利用できなかった MIDI ポートが利用可能になったとき、 または既存のポートが state 属性を変更したときは常に、ユーザー エージェントは次の手順を実行するべきである（SHOULD）：

1. port を、新たに利用可能になった、 または既存のポートに対応するMIDIPortとする。
2. イベントを発火する： MIDIAccess で "statechange" という名前のイベントを発火し、 MIDIConnectionEvent を用い、port を port に設定する。

sysexEnabled

この属性は、この MIDIAccess で System Exclusive サポートが有効であるかどうかをユーザーに知らせる。

このインターフェイスは、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

既存のポートがその state または connection 属性を変更したときに呼び出されるハンドラー。

このイベント ハンドラーは、型 "statechange" であり、MIDIPort インターフェイスを実装するすべてのオブジェクトで サポートされなければならない（MUST）。

注記

このオブジェクトにEventHandler を接続したままにすると、そのオブジェクトが ガベージコレクトされなくなることを理解することが重要である。 MIDIPort の使用を終えたら、 すべての onstatechange リスナーを削除するべきである。

open

MIDIPort に対応するMIDI デバイスを 明示的に利用可能にする。この呼び出しは、 MIDIPort を使用するために必要ではないことに注意。 MIDIOutput で send() を呼び出すこと、 MIDIInput に MIDIMessageEvent EventHandler を接続すること、または MIDIInput に MIDIMessageEvent EventListener を追加することにより、暗黙的な open() が発生する。基盤となる 実装は、この呼び出しに応答して何も行う必要がない場合がある。 しかし、一部の基盤となる実装は、MIDI デバイスへの共有アクセスを サポートできない場合があるため、明示的な open() および close() 呼び出しを使用することで、MIDI アプリケーションは デバイスへのこの排他的アクセスを予測可能に制御できる。

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

ポートデバイスの state が "connected" である場合、 ポートへのアクセスが取得されると（そしてポートが入力または 出力の準備ができると）、提供された Promise は解決される。

接続済みポートへのアクセスが利用できない場合（たとえば、 排他的アクセスのみのプラットフォームでそのポートがすでに使用中である場合）、 Promise は拒否される（もしあれば）呼び出される。

open() が "disconnected" であるポートで呼び出された場合、 そのポートの .connection は "pending" に遷移し、 そのポートが "connected" になるか、それへのすべての参照が 破棄されるまで続く。

提供されたすべての Promise がまだ settle していなくても、 open() を複数回呼び出すことは許可される。

このメソッドが呼び出されたとき、ユーザーエージェントは MIDIPort を開くアルゴリズムを 実行しなければならない（MUST）：

1. promise を新しい Promise オブジェクトとし、 resolver をそれに関連付けられた resolver とする。

2. promise を返し、次の手順を 非同期に実行する。

3. port を所与の MIDIPort オブジェクトとする。

4. デバイスの connection がすでに "open" である場合 （例：open() がすでにこの MIDIPort で呼び出されている、またはポートが 暗黙的に開かれている場合）、下の success とラベル付けされた手順へジャンプする。

5. デバイスの connection が "pending" である場合 （すなわち、connection は開かれていたが、その後デバイスが 切断された場合）、下の success とラベル付けされた手順へジャンプする。

6. デバイスの state が "disconnected" である場合、 MIDIPort の connection 属性を "pending" に変更し、新しい MIDIConnectionEvent を MIDIAccess の statechange ハンドラーと、 MIDIPort の statechange ハンドラーにキューイングし、下の success とラベル付けされた手順へジャンプする。

7. システム内の所与のMIDI デバイスへのアクセス取得を試みる。 デバイスが利用できない場合（例：別のプロセスによってすでに使用中であり 開けない、または切断されている場合）、 下の failure とラベル付けされた手順へジャンプする。デバイスが 利用可能でアクセスが取得された場合、次の手順を続行する。

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

9. このポートが出力ポートであり、将来の timestamp を持つキュー済み送信データが ある場合、そのデータの送信を非同期に開始する。

10. success：resolver の accept(value) メソッドを、port を 値引数として呼び出す。

11. これらの手順を終了する。

12. failure：error を新しい DOMException とする。 この例外の .name は、ポートが利用できない場合、 "InvalidAccessError" であるべきである。

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

close

MIDIPort に対応するMIDI デバイスを 明示的に利用不可にする（その後、状態を "open" から "closed" に変更する）。この メソッドの呼び出しが成功すると、MIDIInput 上の MIDIMessageEvent ハンドラーに MIDI メッセージがもはや 配信されなくなることに注意（ただし、 新しいハンドラーを設定すると暗黙的な open() が発生する）。

基盤となる実装は、この呼び出しに応答して 何も行う必要がない場合がある。しかし、一部の基盤となる実装は MIDI デバイスへの共有アクセスをサポートできない場合があり、 明示的な close() 呼び出しにより、MIDI アプリケーションは 他のアプリケーションがデバイスへのアクセスを取得できるようにすることを確実にできる。

呼び出されると、このメソッドは、ユーザーのシステム上の所与の MIDI ポートへの アクセス要求を表す Promise オブジェクトを返す。 ポートが閉じられたとき（したがって、排他的アクセス システムでは、そのポートが他のアプリケーションで利用可能になったとき）、 提供された Promise は解決される。ポートが切断されている場合、Promise は 拒否される。

提供されたすべての Promise がまだ settle していなくても、 close() を複数回呼び出すことは許可される。

close() メソッドが呼び出されたとき、ユーザーエージェントは 次の手順を実行しなければならない（MUST）：

1. promise を新しい Promise オブジェクトとし、 resolver をそれに関連付けられた resolver とする。

2. promise を返し、次の手順を 非同期に実行する。

3. port を所与の MIDIPort オブジェクトとする。

4. ポートがすでに閉じている場合（その .connection が "closed" である場合。例：ポートが まだ暗黙的にも明示的にも開かれていない、または close() がすでにこの MIDIPort で 呼び出されている場合）、下の closed とラベル付けされた手順へジャンプする。

5. ポートが入力ポートである場合、次の手順へスキップする。出力ポートの .state が "connected" でない場合、またはその .connection が "pending" である場合は、 すべてのキュー済み送信データを消去し、次の手順へスキップする。 将来の timestamp を持つ、システム内のすべてのキュー済み送信データを消去し、 その後、timestamp がない、または過去もしくは現在の timestamp を持つ送信メッセージの送信を完了してから、 次の手順へ進む。

6. 基盤システムで開かれている場合はポートへのアクセスを閉じ、 基盤システムのブロッキングリソースをすべて解放する。

7. MIDIPort の connection 属性を "closed" に変更し、新しい MIDIConnectionEvent を MIDIAccess の statechange ハンドラーと、 MIDIPort の statechange ハンドラーにキューイングする。

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

MIDIPort に対応する MIDI ポートが state 属性を変更したときは常に、ユーザーエージェントは次の手順を実行するべきである （SHOULD）：

1. port を MIDIPort とする。

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

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

単一のMIDI メッセージの MIDI データバイトを含む Uint8Array。

WebIDLdictionary MIDIMessageEventInit: EventInit {
  Uint8Array data;
};

このインターフェイスを実装するイベントオブジェクトは、 新しいポートが利用可能になったとき（たとえば、MIDI デバイスがコンピューターに初めて 接続されたとき）、以前利用可能であったポートが利用不可になったとき、 または再び利用可能になったとき（たとえば、MIDI インターフェイスが 切断され、その後再接続されたとき）、 MIDIAccess の onstatechange ハンドラーに渡される。 また（存在する場合）、そのポートを参照する任意の MIDIPort の onstatechange ハンドラーにも渡される。

MIDIPort が "pending" 状態にあり、デバイスが ホストシステムに再接続された場合、 statechange イベントを発火する前に、 そのポートを再び開くことを試みるため、 MIDIPort を開くアルゴリズムがその上で実行される。この 遷移が失敗した場合（例：ポートが基盤システム内の別の何かによって予約されており、 したがって使用できない場合）、connection state は "closed" に移動し、そうでない場合は "open" に戻る。 これは、デバイス状態変更に対する statechange イベントの前に行われるため、そのイベントは最終的な connection state と device state の両方を反映する。

一部の基盤システムは、デバイス接続状態の通知イベントを提供しない場合がある。 そのようなシステムでは、新しいデバイスをまれにポーリングするため、 長い時間遅延が生じることがある。そのため、 接続イベントに大きく依存しないことが推奨される。

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

port

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

WebIDLdictionary MIDIConnectionEventInit: EventInit {
  MIDIPort port;
};

懸念される理論上の攻撃の 1 つに、USB-MIDI デバイスに対する悪意のある ファームウェア更新がある。一般に USB デバイスは、 USB デバイス自身から送信されるデバイス記述子に基づいて動作できる。 USB-MIDI デバイスの ファームウェアが送信される記述子を変更できる場合、 そのデバイスは自身をヒューマンインターフェイスデバイスとして動作させることができる。 これにより、悪意のある Web サイトがホストコンピューター上の キーストロークやその他のイベントを読み取ったり注入したりできるようになり、 システム全体の侵害につながる可能性がある。

攻撃は次のように進行する：

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

上記の攻撃を可能にするためには、MIDI デバイスについて、 次のすべてが真である必要がある：

• 悪意のあるファームウェア更新に対して脆弱であること。 次のすべてが真でなければならない：
  • ユーザーがプログラム可能なファームウェアを持つこと。多くの MIDI デバイスは再プログラム可能なファームウェアを持つ。 そうでないものは脆弱ではない。
  • MIDI メッセージの送信によるファームウェア更新を許可すること。 多くのMIDI デバイスは、 ファームウェア更新を実行するためにSystem Exclusive メッセージを使用する。 これはSystem Exclusive メッセージの一般的な用途である。 ファームウェア更新を実行するために非System Exclusive メッセージを 使用するデバイスを作ることは技術的には可能であるが、これは非System Exclusive メッセージの 意図された用途ではない。他のデバイスは、帯域外の USB 通信を使用するか、 ファームウェア更新を実行するためにユーザーが記憶装置を直接 MIDI デバイスに接続することを要求する場合があり、 これは Web MIDI API を使用して行うことはできず、脆弱ではない。
  • デバイス上で明示的なユーザー操作なしにファームウェア更新を許可すること。 ファームウェア更新を開始するためにユーザー操作を必要としない MIDI デバイスが存在することは知られている。ほとんどの MIDI デバイスは、ボタンを押し続ける、またはメニュー項目を選択するなどして、 ユーザーが最初に特別な更新モードにすることを要求し、攻撃者がユーザーをだまして協力させない限り 脆弱ではない。
• USB-MIDI デバイスであること。ほとんどの現代的な MIDI デバイスは USB MIDI インターフェイスを持つ。一部の古い MIDI デバイスはシリアル接続しか持たず、 この攻撃を可能にしない。
• MIDI デバイスのファームウェアが、 USB コントローラーのファームウェアを変更できる必要がある。多くの MIDI デバイスには、 メインファームウェアからアドレス指定できない USB コントローラーファームウェアがあり、 この攻撃を可能にしない。

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

このリスクを軽減するため、実装者は実装において 次の点を重視するべきである：

• requestMIDIAccess() を、 権限プロンプト内のテキストなどを通じて、ファームウェア更新のリスクを ユーザーに知らせる方法で実装する。
• ユーザーが開始した正当なファームウェア更新が改変されることを防ぐため、 指定どおりに SecureContext を実装する。
• sysex パラメーターを指定どおりに扱い、ほとんどのファームウェア更新が System Exclusive メッセージを使用するため、開発者が必要な場合にのみ System Exclusive メッセージを 要求するよう促す。

既知の MIDI デバイスのリストを明示的に許可またはブロックすることも、 この特定の攻撃を軽減するのに役立つ可能性がある。しかし、 多くの小企業や個人が MIDI デバイスを作っており、 多くの MIDI デバイスはもはやサポートされていないため、 これを行うと Web MIDI API の使いやすさが大幅に低下する。

利用可能なポートを識別することによるフィンガープリンティングの懸念とは別に、 MIDI メッセージの送受信に関する懸念がある。 それらの問題は以下でより詳しく検討される。

MIDI メッセージは、System Exclusive メッセージと、短い（非System Exclusive）メッセージに 分けることができる。System Exclusive メッセージはさらに、 広く認識されている MIDI Time Code や MIDI Sample Dump Standard のような Universal System Exclusive メッセージと、 他のデバイスには適用されない「Roland Jupiter-80 シンセサイザーのパッチ制御データ」のような デバイス固有メッセージに細分できる。

セキュリティ上の懸念を議論する前に、これらの機能を使用する MIDI によって どのようなシナリオが可能になるかを調べると有用である：

• MIDI デバイスから短いメッセージを受信すること - これにより、キーボード、ドラムパッド、ギター、ウィンドコントローラー、 DJ／コントローラー奏者向けコントローラーなどから入力を取得し、 それらのメッセージを入力として使用して、Web Audio API の 楽器や機能、およびその他の制御シナリオを制御できる。 MIDI は、プロ／プロシューマー向けオーディオおよびメディアアプリケーションだけでなく、 Garageband のようなコンシューマーアプリケーションにおいても、ノブやボタンなどの 物理コントローラーをコンピューターに接続するための、数十億ドル規模の音楽制作業界で 選ばれているプロトコルである。
• MIDI デバイスへ短いメッセージを送信すること - 今日の市場ではハードウェアシンセサイザーのような接続された出力デバイスのシナリオは あまり一般的ではないため、送信は大幅に関心が低いと言いたくなる。 これに対する主な例外は、多くの MIDI コントローラーが インジケーターライトの外部ホスト制御を持ち、これによって劇的に有用になることである。 たとえば、非常に人気のある Novation Launchpad コントローラーは、 送信された MIDI note on/off メッセージを使用して、ボタンのオン／オフや色の変更を行う。 ほぼすべての DJ コントローラーにも同じことが当てはまる。
• System Exclusive メッセージを 送受信すること - ハイエンドのハードウェアデバイスとのより高度な通信には、 System Exclusive メッセージが必要である。 MIDI Machine Control（汎用の開始／停止／巻き戻し／早送りコマンド）など、 一部の一般的な MIDI コマンドも Universal System Exclusive メッセージとして送信される。 多くのデバイスは、パッチのプログラム、高度なコントローラーメッセージの送信、 ファームウェアのダウンロードなどにデバイス固有のSystem Exclusive メッセージを使用しており、これらは Web MIDI に対して非常に需要の高いシナリオである。 一部のデバイスは、1 つの「メッセージ」により多くのデータを詰め込めるため、 System Exclusive を直接制御プロトコルとして使用する。 また、ほとんどのデバイスは、低価格のコンピューターストレージ上に パッチや設定情報を保存および復元する方法として System Exclusive を使用する。 主要な音楽ハードウェア製造者のいくつかは、Web MIDI を使用して 自社ハードウェア向けの Web ベースの設定およびプログラミングインターフェイスを提供することに 強い関心を示している。要するに、 System Exclusive を完全に無効にすることは、 ハイエンドのシナリオだけを無効にするわけではない。

これらそれぞれの潜在的なセキュリティ上の影響は次のとおりである：

• MIDI デバイスへ短いメッセージを送信すること - note-on／note-off／controller メッセージを送信すると、接続されたデバイス （Mac および Windows 上の既定の仮想シンセサイザーを含む）で音が再生される可能性がある。 これはそれ自体では懸念される露出を引き起こさない。 <audio> や Web Audio を通じて、すでにユーザー操作なしに音を出すことができるためである。 一部の接続されたデバイスはプロ用の照明制御システムである可能性があるため、 舞台照明を制御できる可能性がある。しかしこれはまれであり、短いメッセージのみに基づいて 永続的な損害や情報漏えいを引き起こす能力を持つ既知のシステムはない。 最悪の場合、悪意のあるページがライトを点滅させる可能性があるが、 ユーザーはページを閉じて照明コントローラーをリセットできる。 短いメッセージを送信することに関する追加の懸念は、任意の音声出力と類似している。 ユーザー情報を上書きしたり公開したりすることはできないが、 音を発生させたり、パッチを変更したり、（まれな構成では）ライトを切り替えたりできる。 ただし、破壊的でも永続的でもない。
• MIDI デバイスから短いメッセージを受信すること - note-on／note-off／controller メッセージの受信は、情報露出やセキュリティ問題を 引き起こさない。受信される識別データはなく、コントローラーメッセージのストリームだけであり、 それらはすべて（クロック型メッセージを除き）その MIDI デバイス上で ユーザーによって開始されなければならないためである。これは、キーボード、マウス、 モバイル／ラップトップの加速度計、タッチ入力、またはゲームパッドイベントを リッスンすることに類似している。追加で公開される情報はなく、 クロック信号以外のすべてのメッセージはユーザーによって開始されなければならない。
• System Exclusive メッセージを 送受信すること - これは最大の懸念である。なぜなら、 System Exclusive メッセージに対するシステム固有の応答を探すコードを書くことが可能であり、 それによって利用可能なハードウェアを識別し、それを使用してデータ （例：サンプラーに保存されたサンプル）をダウンロードしたり、 そのデータを置き換えたり（デバイス内のサンプルデータやパッチを消去したり）できるためである。 ただし、これらのシナリオはいずれも特定のデバイス向けにコード化されている必要がある。 また、一部のサンプラーでは System Exclusive メッセージによってサンプル録音を開始できる可能性がある。 そのため、サンプラーに専用マイクが接続されていた場合（実際には一般的ではないが可能である）、 特定のデバイス向けのコードを書き、短い音声サンプルを録音して、 追加のユーザー介入なしにネットワークへアップロードすることが可能になる。 デバイスから音声をストリーミングすることはできず、ほとんどのサンプラーはかなり限られたメモリしか持たない。 また、MIDI Sample Dump sysex はデータを転送する遅い方法であり、 7 ビットへトランスコードする必要があるため、長時間盗聴できる可能性は低い。 より明示的なフィンガープリンティングは懸念事項である。なぜなら、パッチ情報／保存されたサンプル／ ユーザー設定がシステムを一意に識別し得るためである。 繰り返しになるが、これは多くのデバイス固有コードを必要とする。 標準化された「すべてのパッチを取得してハッシュ化する」能力は存在しない。 これは、System Exclusive メッセージが独自のセキュリティカテゴリに属することを示唆している。 このように潜在的な影響範囲が限定されにくいため、ユーザーセキュリティの フックをより慎重に提供するために、API において SysEx の要求を別個に区別することは 良い考えであると思われる。推奨される セキュリティモデルでは、ユーザーエージェントが MIDI デバイスへのアクセスを与える前に ユーザーの承認を要求することを明示的に許可している。ただし、現在この承認について ユーザーにプロンプトを表示することは必須ではない。また、System Exclusive サポートは その要求の一部として要求されなければならないことも詳述されている。