웹 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 장치 접근을 묻는 프롬프트를 표시해야 한다. 어떤 시나리오에서는 이 권한이 이미 암시적으로 또는 명시적으로 부여되었을 수 있으며, 이 경우 이 프롬프트는 나타나지 않을 수 있다. 사용자가 명시적 권한을 주거나 호출이 다른 방식으로 승인되면, 제공된 Promise는 이행된다. 기반 시스템은 이 API에 노출할 특정 MIDI 인터페이스를 사용자가 선택할 수 있게 할 수도 있다 (즉, 개별 기준으로 인터페이스를 골라 선택함). 다만 이는 필수는 아니다. 또한 시스템은 System Exclusive 지원이 요청되는지 여부에 따라 프롬프트를 표시할지(또는 표시하지 않을지)를 선택할 수도 있다. System Exclusive 접근은 더 큰 개인정보 및 보안상의 영향을 가지기 때문이다.

사용자가 거절하거나 호출이 그 밖의 이유로 거부되면, Promise는 DOMException 매개변수와 함께 거부된다.

제공된 Promise가 모두 settled되지 않았더라도 requestMIDIAccess()를 여러 번 호출하는 것이 허용된다.

requestMIDIAccess() 메서드가 호출되면, 사용자 에이전트는 다음 단계를 실행해야 한다.

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를 value 인자로 하여 호출한다.

10. 이 단계를 종료한다.

11. failure: error를 새 DOMException으로 둔다. 사용자가 또는 사용자의 보안 설정이 요청된 옵션으로 애플리케이션이 MIDIAccess 인스턴스를 생성하는 것을 거부했거나, 오류가 document가 해당 기능을 사용하도록 허용되지 않은 결과라면, 이 예외의 .name은 "NotAllowedError"여야 한다. 페이지가 사용자 탐색으로 인해 닫히려는 경우에는 "AbortError"여야 하며, 기반 시스템이 오류를 발생시키는 경우에는 "InvalidStateError"여야 하고, 그 밖의 경우에는 "NotSupportedError"여야 한다.

12. resolver의 reject(value) 메서드를 error를 value 인자로 하여 호출한다.

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 인터페이스를 구현하는 모든 객체에서 지원되어야 한다.

참고

이 객체에 EventHandler를 연결된 채로 두면 이 객체가 가비지 컬렉션되는 것을 막는다는 점을 이해하는 것이 중요하다. MIDIAccess 사용을 마쳤으면 모든 onstatechange 리스너를 제거해야 한다.

이전에는 사용할 수 없었던 MIDI 포트를 사용할 수 있게 되거나, 기존 포트가 state 속성을 변경할 때마다, 사용자 에이전트는 다음 단계를 실행해야 한다.

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가 오직 해당 포트에 대해서만 고유하도록 보장해야 한다. 사용자 에이전트는 이 id가 애플리케이션 인스턴스 사이에서 유지되도록 보장해야 한다. 예를 들어 시스템이 재부팅될 때와 장치가 시스템에서 제거될 때도 유지되어야 한다. 애플리케이션은 MIDI 설정을 다시 만들기 위해 이러한 id를 로컬에 캐시하기를 원할 수 있다. 일부 시스템은 완전히 고유한 지속 식별자를 지원하지 않을 수 있다. 그런 경우에는 다른 인터페이스가 시스템에 추가되거나 제거될 때 식별자를 유지하기가 더 어려워진다. (이는 요청된 포트의 인덱스를 어긋나게 할 수 있다.) 시스템은 MIDI API의 인스턴스 사이에서 포트를 일치시키기 위해 최선을 다할 것으로 예상된다. 예를 들어 구현은 포트 인터페이스의 제조사, 이름 및 인덱스에 대한 어떤 형태의 해시를 불투명하게 id로 사용할 수 있으며, 그러면 그 포트 id에 대한 참조가 연결되었을 때 해당 포트와 일치할 가능성이 높다. 애플리케이션은 MIDIPort의 id 비교를 사용하여 동등성을 테스트할 수 있다.

manufacturer

포트의 제조사.

name

포트의 시스템 이름.

type

포트가 입력 포트인지 출력 포트인지 구별하기 위한 설명자 속성. MIDIOutput의 경우 이는 "output"이어야 한다. MIDIInput의 경우 이는 "input"이어야 한다.

version

포트의 버전.

state

장치의 상태.

connection

장치에 대한 연결 상태.

onstatechange

기존 포트가 state 또는 connection 속성을 변경할 때 호출되는 핸들러.

"statechange" 타입인 이 이벤트 핸들러는 MIDIPort 인터페이스를 구현하는 모든 객체에서 지원되어야 한다.

참고

이 객체에 EventHandler를 연결된 채로 두면 이 객체가 가비지 컬렉션되는 것을 막는다는 점을 이해하는 것이 중요하다. MIDIPort 사용을 마쳤으면 모든 onstatechange 리스너를 제거해야 한다.

open

MIDIPort에 해당하는 MIDI 장치를 명시적으로 사용할 수 있게 한다. 이 호출은 MIDIPort를 사용하는 데 필요하지 않다는 점에 유의한다. MIDIOutput에서 send()를 호출하거나, MIDIInput에 MIDIMessageEvent EventHandler를 연결하거나, MIDIInput에 MIDIMessageEvent EventListener를 추가하면 암시적 open()이 발생한다. 기반 구현은 이 호출에 응답하여 아무것도 할 필요가 없을 수도 있다. 그러나 일부 기반 구현은 MIDI 장치에 대한 공유 접근을 지원하지 못할 수 있으므로, 명시적 open() 및 close() 호출을 사용하면 MIDI 애플리케이션이 장치에 대한 이러한 독점 접근을 예측 가능하게 제어할 수 있다.

호출되면, 이 메서드는 사용자의 시스템에 있는 주어진 MIDI 포트에 대한 접근 요청을 나타내는 Promise 객체를 반환한다.

포트 장치의 상태가 "connected"인 경우, 포트에 대한 접근이 얻어지면(그리고 포트가 입력 또는 출력을 위해 준비되면), 제공된 Promise는 이행된다.

연결된 포트에 대한 접근을 사용할 수 없는 경우(예를 들어 포트가 독점 접근 전용 플랫폼에서 이미 사용 중인 경우), Promise는 거부된다.

open()이 "disconnected"인 포트에서 호출되면, 포트의 .connection은 포트가 "connected"가 되거나 그에 대한 모든 참조가 제거될 때까지 "pending"으로 전환된다.

제공된 Promise가 모두 settled되지 않았더라도 open()을 여러 번 호출하는 것이 허용된다.

이 메서드가 호출되면, 사용자 에이전트는 MIDIPort를 여는 알고리즘을 실행해야 한다.

1. promise를 새 Promise 객체로, resolver를 그 관련 resolver로 둔다.

2. promise를 반환하고 다음 단계를 비동기적으로 실행한다.

3. port를 주어진 MIDIPort 객체로 둔다.

4. 장치의 연결이 이미 "open"이면 (예: 이 MIDIPort에서 open()이 이미 호출되었거나 포트가 암시적으로 열렸다면), 아래 success로 표시된 단계로 이동한다.

5. 장치의 연결이 "pending"이면 (즉, 연결이 열렸고 이후 장치가 연결 해제되었다면), 아래 success로 표시된 단계로 이동한다.

6. 장치의 상태가 "disconnected"이면, MIDIPort의 connection 속성을 "pending"으로 변경하고, 새 MIDIConnectionEvent를 MIDIAccess의 statechange 핸들러와 MIDIPort의 statechange 핸들러에 큐에 넣고, 아래 success로 표시된 단계로 이동한다.

7. 시스템에서 주어진 MIDI 장치에 대한 접근을 얻으려고 시도한다. 장치를 사용할 수 없으면 (예: 다른 프로세스에서 이미 사용 중이어서 열 수 없거나, 연결 해제되었으면) 아래 failure로 표시된 단계로 이동한다. 장치를 사용할 수 있고 접근을 얻으면, 다음 단계를 계속한다.

8. MIDIPort의 connection 속성을 "open"으로 변경하고, 새 MIDIConnectionEvent를 MIDIAccess의 statechange 핸들러와 MIDIPort의 statechange 핸들러에 큐에 넣는다.

9. 이 포트가 출력 포트이고 미래의 타임스탬프를 가진 큐에 들어간 전송 데이터가 있으면, 그 데이터를 비동기적으로 보내기 시작한다.

10. success: resolver의 accept(value) 메서드를 port를 value 인자로 하여 호출한다.

11. 이 단계를 종료한다.

12. failure: error를 새 DOMException으로 둔다. 포트를 사용할 수 없으면 이 예외의 .name은 "InvalidAccessError"여야 한다.

13. resolver의 reject(value) 메서드를 error를 value 인자로 하여 호출한다.

close

MIDIPort에 해당하는 MIDI 장치를 명시적으로 사용할 수 없게 한다(이후 상태를 "open"에서 "closed"로 변경한다). 이 메서드의 호출이 성공하면 MIDIInput의 MIDIMessageEvent 핸들러로 MIDI 메시지가 더 이상 전달되지 않는다는 점에 유의한다(다만 새 핸들러를 설정하면 암시적 open()이 발생한다).

기반 구현은 이 호출에 응답하여 아무것도 할 필요가 없을 수도 있다. 그러나 일부 기반 구현은 MIDI 장치에 대한 공유 접근을 지원하지 못할 수 있으며, 명시적 close() 호출은 MIDI 애플리케이션이 다른 애플리케이션이 장치에 접근할 수 있도록 보장하게 한다.

호출되면, 이 메서드는 사용자의 시스템에 있는 주어진 MIDI 포트에 대한 접근 요청을 나타내는 Promise 객체를 반환한다. 포트가 닫히면(따라서 독점 접근 시스템에서는 포트를 다른 애플리케이션이 사용할 수 있게 되면), 제공된 Promise는 이행된다. 포트가 연결 해제되어 있으면 Promise는 거부된다.

제공된 Promise가 모두 settled되지 않았더라도 close()를 여러 번 호출하는 것이 허용된다.

close() 메서드가 호출되면, 사용자 에이전트는 다음 단계를 실행해야 한다.

1. promise를 새 Promise 객체로, resolver를 그 관련 resolver로 둔다.

2. promise를 반환하고 다음 단계를 비동기적으로 실행한다.

3. port를 주어진 MIDIPort 객체로 둔다.

4. 포트가 이미 닫혀 있다면(그 .connection이 "closed"이면 — 예를 들어 포트가 아직 암시적으로 또는 명시적으로 열리지 않았거나, 이 MIDIPort에서 close()가 이미 호출되었다면), 아래 closed로 표시된 단계로 이동한다.

5. 포트가 입력 포트이면 다음 단계로 건너뛴다. 출력 포트의 .state가 "connected"가 아니거나 그 .connection이 "pending"이면, 큐에 들어간 모든 전송 데이터를 지우고 다음 단계로 건너뛴다. 시스템에서 미래의 타임스탬프를 가진 큐에 들어간 전송 데이터를 모두 지운 다음, 다음 단계로 진행하기 전에 타임스탬프가 없거나 과거 또는 현재의 타임스탬프를 가진 모든 전송 메시지의 전송을 완료한다.

6. 열려 있다면 기반 시스템에서 포트에 대한 접근을 닫고, 기반 시스템의 모든 블로킹 리소스를 해제한다.

7. MIDIPort의 connection 속성을 "closed"로 변경하고, 새 MIDIConnectionEvent를 MIDIAccess의 statechange 핸들러와 MIDIPort의 statechange 핸들러에 큐에 넣는다.

8. closed: resolver의 accept(value) 메서드를 port를 value 인자로 하여 호출한다.

MIDIPort에 해당하는 MIDI 포트가 state 속성을 변경할 때마다, 사용자 에이전트는 다음 단계를 실행해야 한다.

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를 여는 알고리즘을 실행하여 포트를 다시 열려고 시도한다. 이 전환이 실패하면(예: 포트가 기반 시스템에서 다른 것에 의해 예약되어 있어 사용할 수 없는 경우) 연결 상태는 "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 장치의 펌웨어가 전송되는 설명자를 수정할 수 있다면, 스스로를 인간 인터페이스 장치처럼 동작하게 만들 수 있다. 이는 악성 웹 사이트가 호스트 컴퓨터에서 키 입력이나 다른 이벤트를 읽거나 주입할 수 있게 하며, 시스템 전체의 손상으로 이어질 수 있다.

공격은 다음과 같이 진행된다.

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를 구현한다.
• 대부분의 펌웨어 업데이트가 System Exclusive 메시지를 사용하므로, 개발자가 필요할 때만 System Exclusive 메시지를 요청하도록 장려하기 위해 지정된 대로 sysex 매개변수를 처리한다.

알려진 MIDI 장치의 허용 목록 또는 차단 목록을 명시적으로 사용하는 것도 이 특정 공격을 완화하는 데 도움이 될 수 있다. 그러나 많은 소규모 회사와 개인이 MIDI 장치를 만들고, 많은 MIDI 장치가 더 이상 지원되지 않으므로, 이렇게 하면 Web MIDI API의 사용성이 크게 낮아질 것이다.

사용할 수 있는 포트를 식별하는 fingerprinting 우려와는 별개로, 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 명령도 MIDI Machine Control 같은 Universal System Exclusive 메시지로 전송된다. 이는 일반적인 시작/정지/되감기/빨리감기 명령이다. 많은 장치는 패치를 프로그래밍하거나, 고급 컨트롤러 메시지를 보내거나, 펌웨어를 다운로드하는 등 Web MIDI에서 많이 요구되는 시나리오를 위해 장치별 System Exclusive 메시지를 사용한다. 일부 장치는 더 많은 데이터를 하나의 “메시지”에 담을 수 있기 때문에 System Exclusive를 직접 제어 프로토콜로 사용하며, 대부분의 장치는 저렴한 컴퓨터 저장소에 패치와 구성 정보를 저장하고 복원하는 방법으로 System Exclusive를 사용한다. 주요 음악 하드웨어 제조사 몇 곳은 Web MIDI를 사용하여 자사 하드웨어에 대한 웹 기반 구성 및 프로그래밍 인터페이스를 제공하는 데 강한 관심을 표명했다. 요컨대 System Exclusive를 완전히 비활성화하는 것은 고급 시나리오만 비활성화하는 것이 아니다.

이들 각각의 잠재적 보안 영향은 다음과 같다.

• MIDI 장치로 짧은 메시지를 보내기 — note-on/note-off/controller 메시지를 보내면 연결된 장치에서 소리가 재생될 수 있으며, 여기에는 (Mac 및 Windows의) 기본 가상 신시사이저도 포함된다. 이것 자체는 우려할 만한 노출을 일으키지 않는다. <audio> 또는 Web Audio를 통해 이미 상호작용 없이도 소리를 낼 수 있기 때문이다. 일부 연결된 장치는 전문 조명 제어 시스템일 수 있으므로 무대 조명을 제어할 수 있다. 그러나 이는 드물며, 짧은 메시지만으로 지속적인 손상이나 정보 유출을 일으킬 수 있는 알려진 시스템은 없다. 최악의 경우 악성 페이지가 조명을 깜박이게 할 수 있고, 사용자는 페이지를 닫고 조명 컨트롤러를 재설정할 수 있다. 짧은 메시지 보내기에 대한 추가적인 우려는 모든 오디오 출력과 유사하다. 사용자 정보를 덮어쓰거나 노출할 수는 없지만, 소리를 발생시키거나, 패치를 변경하거나, (드문 구성에서는) 조명을 토글할 수 있다. 그러나 이는 파괴적이지 않고 지속적이지 않다.
• MIDI 장치로부터 짧은 메시지를 수신하기 — note-on/note-off/controller 메시지를 수신하는 것은 정보 노출이나 보안 문제를 일으키지 않는다. 식별 데이터가 수신되는 것이 아니라 단지 컨트롤러 메시지 스트림만 수신되며, 이 모든 메시지는 (clock 유형 메시지를 제외하면) 해당 MIDI 장치에서 사용자가 시작해야 하기 때문이다. 이는 키보드, 마우스, 모바일/노트북 가속도계, 터치 입력 또는 게임패드 이벤트를 듣는 것과 유사하다. 추가로 노출되는 정보는 없으며, clock 신호를 제외한 모든 메시지는 사용자가 시작해야 한다.
• System Exclusive 메시지를 보내고 받기 — 이것이 가장 큰 우려이다. System Exclusive 메시지에 대한 시스템별 응답을 찾는 코드를 작성할 수 있으며, 이를 통해 사용 가능한 하드웨어를 식별하고, 그 하드웨어를 사용하여 데이터(예: 샘플러에 저장된 샘플)를 다운로드하거나 그 데이터를 대체(장치의 샘플 데이터나 패치를 삭제)할 수 있기 때문이다. 다만 이 두 시나리오는 모두 특정 장치에 맞게 코딩되어야 한다. 또한 일부 샘플러는 System Exclusive 메시지로 샘플 녹음을 시작할 수 있게 할 가능성이 있다. 따라서 샘플러에 전용 마이크가 연결되어 있다면(실제로는 드물지만 가능함), 특정 장치에 맞는 코드를 작성하여 짧은 사운드 샘플을 녹음하고, 추가적인 사용자 개입 없이 네트워크에 업로드할 수 있을 것이다. 장치에서 오디오를 스트리밍할 수는 없고, 대부분의 샘플러는 메모리가 상당히 제한적이며, MIDI Sample Dump sysex는 데이터를 전송하는 느린 방식이다. 7비트로 트랜스코딩해야 하기 때문이다. 따라서 장시간 엿듣기는 어려울 가능성이 높다. 더 명시적인 fingerprinting도 우려된다. 패치 정보/저장된 샘플/사용자 구성이 시스템을 고유하게 식별할 수 있기 때문이다. 다시 말하지만, 이는 많은 장치별 코드를 필요로 한다. 표준화된 “모든 패치를 가져와 해시한다” 기능은 없다. 이는 System Exclusive 메시지가 그 자체의 보안 범주에 속함을 시사한다. 이렇게 덜 한정된 잠재성 때문에, 사용자 보안 hook을 더 신중하게 제공하기 위해 API에서 SysEx 요청을 별도로 구분하는 것이 좋은 생각으로 보인다. 제안된 보안 모델은 사용자 에이전트가 MIDI 장치에 대한 접근을 제공하기 전에 사용자의 승인을 요구할 수 있도록 명시적으로 허용한다. 현재는 이 승인을 위해 사용자에게 프롬프트를 표시해야 하는 것은 아니지만, System Exclusive 지원은 그 요청의 일부로 요청되어야 한다는 점도 자세히 명시되어 있다.