Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split the existing Security and Privacy Considerations section #250

Merged
merged 1 commit into from
Sep 30, 2023
Merged

Split the existing Security and Privacy Considerations section #250

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
86 changes: 43 additions & 43 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1307,44 +1307,52 @@ <h2 id="MIDIConnectionEventInit">
</section>
<section>
<h2>
Security and Privacy Considerations of MIDI
Privacy Considerations
</h2>
<p>
There are two primary security and privacy concerns with adding the
Web MIDI API to the web platform:
Allowing the enumeration of the user's MIDI interfaces is a potential
target for fingerprinting (that is, uniquely identifying a user by the
specific MIDI interfaces they have connected). Note that in this
context, what can be enumerated is the MIDI <i>interfaces</i> - not,
for example, an individual sampler or synthesizer plugged into a MIDI
interface, as these would not be enumerated, unless those devices are
connected to the host computer with USB (USB-MIDI devices typically
have their own MIDI interface, and would be enumerated). The
interfaces that could be fingerprinted are equivalent to MIDI "ports",
and for each device the API will expose the name of the device,
manufacturer, and opaque identifier of the MIDI interface (but not any
attached devices).
</p>
<p>
Few systems will have significant numbers of MIDI devices attached;
those systems that do will typically use hardware MIDI interfaces, not
fanning out a dozen USB-MIDI connections through USB hubs. In this
case, of course, enumerating the MIDI “devices” will only see the
hardware MIDI interface(s), not the synthesizers, samplers,
etc. plugged into it on the other side. Given the few number of
devices plugged in, the amount of information exposed here is fairly
symmetric with the fingerprinting concern exposed by other APIs such
as the Gamepad API. The vast majority of systems have relatively few
MIDI interfaces attached.
</p>
<p>
In short: the additional fingerprinting exposure of enumerating MIDI
devices is directly analogous to the Gamepad API’s additional
fingerprinting exposure through gamepad enumeration; typical users
will only have at most a few devices connected, their configuration
may change, and the information exposed is about the interface itself
(i.e., no user-configured data).
</p>
</section>
<section>
<h2>
Security Considerations
</h2>
<p>
Separate from the fingerprinting concerns of identifying the available
ports are concerns around sending and receiving MIDI messages. Those
issues are explored in more depth below.
</p>
<ol>
<li>Allowing the enumeration of the user's MIDI interfaces is a
potential target for fingerprinting (that is, uniquely identifying a
user by the specific MIDI interfaces they have connected). Note that
in this context, what can be enumerated is the MIDI <i>interfaces</i>
- not, for example, an individual sampler or synthesizer plugged into
a MIDI interface, as these would not be enumerated, unless those
devices are connected to the host computer with USB (USB-MIDI devices
typically have their own MIDI interface, and would be enumerated).
The interfaces that could be fingerprinted are equivalent to MIDI
"ports", and for each device the API will expose the name of the
device, manufacturer, and opaque identifier of the MIDI interface
(but not any attached devices).
<p>
Few systems will have significant numbers of MIDI devices
attached; those systems that do will typically use hardware MIDI
interfaces, not fanning out a dozen USB-MIDI connections through
USB hubs. In this case, of course, enumerating the MIDI “devices”
will only see the hardware MIDI interface(s), not the
synthesizers, samplers, etc. plugged into it on the other side.
Given the few number of devices plugged in, the amount of
information exposed here is fairly symmetric with the
fingerprinting concern exposed by other APIs such as the Gamepad
API. The vast majority of systems have relatively few MIDI
interfaces attached.
</p>
</li>
<li>Separate from the fingerprinting concerns of identifying the
available ports are concerns around sending and receiving MIDI
messages. Those issues are explored in more depth below.
</li>
</ol>
<p>
In brief, the general categories of things you can do with MIDI ports
are:
Expand Down Expand Up @@ -1451,14 +1459,6 @@ <h2>
scenarios.
</li>
</ol>
<p>
In short: the additional fingerprinting exposure of enumerating MIDI
devices is directly analogous to the Gamepad API’s additional
fingerprinting exposure through gamepad enumeration; typical users
will only have at most a few devices connected, their configuration
may change, and the information exposed is about the interface itself
(i.e., no user-configured data).
</p>
<p>
The additional security concern for receiving short messages is also
small - it’s analogous to listening to keyboard, mouse, mobile/laptop
Expand Down