Intent to Deprecate and Remove: Web MIDI use on insecure origins

217 views
Skip to first unread message

Takashi Toyoshima

unread,
Jan 23, 2019, 5:22:29 AM1/23/19
to blink-dev
Contact emails

Summary
Deprecate Web MIDI use on insecure origins.

Motivation
Web MIDI use is classified into two groups, one is non-privilege use, and the other is privilege use with sysex permission.
Until today, only the latter use prompts users for permission, based on the early day's spec. But to reduce security concerns,
we will change this behavior to prompt permission always regardless of sysex use.

The current spec allows user-agents to implement user-agent-specific permission handling at the step 7 below.

For Chrome, asking permissions means it deprecates Web MIDI use on insecure origins as powerful features policy explains below.

This is the reason to send this intent-to-deprecate mail.

Interoperability and Compatibility Risk
Today, there are many production sites that use Web MIDI, but such company managed sites are hosted on https.
So this basically affects only personal or hobby uses. Also today there are many options to host personal sites over secure origins for free.
Also major utilities such as sound librarians require sysex permissions, and are already hosted over https.
Thus, this change should not introduce a critical limit for Web MIDI use and adaption.

Firefox is implementing Web MIDI (tracking bug says firefox66 affected), and as far as I know, they ask the permission always.

Entry on the feature dashboard

Requesting approval to remove too?
Will start showing console message to deprecate this in M74, and want to get an approval to remove this if everything go well.


--
Takashi Toyoshima
Software Engineer, Google

Anne van Kesteren

unread,
Jan 23, 2019, 6:06:44 AM1/23/19
to Takashi Toyoshima, blink-dev
On Wed, Jan 23, 2019 at 11:22 AM Takashi Toyoshima
<toyo...@chromium.org> wrote:
> Firefox is implementing Web MIDI (tracking bug says firefox66 affected), and as far as I know, they ask the permission always.

As far as I'm aware there are no plans to ship Web MIDI in Firefox. As
the discussion you linked to shows, there's no agreement that the
setup is secure enough. (That marker appears to be added due to a
compatibility issue, but has no impact otherwise.)

Takashi Toyoshima

unread,
Jan 23, 2019, 6:31:11 AM1/23/19
to Anne van Kesteren, blink-dev
We talked in the Audio WG, and they said the security concerns were already solved, and they worked closely with music manufacturers to ship it.

2019年1月23日(水) 20:06 Anne van Kesteren <ann...@annevk.nl>:
--

Takashi Toyoshima  <toyo...@google.com> - from mobile

Paul Adenot

unread,
Jan 23, 2019, 8:34:46 AM1/23/19
to Takashi Toyoshima, Anne van Kesteren, blink-dev
There must have been some confusion here, it's probably my fault. I said that some security concerned had been looked at and there was midi vendors involved (that was part of the security discussion), but we're not shipping it, as you can see by the lack of activity on the code in Firefox, and the lack of clear answer on the thread posted by Anne above. We'd have to write quite a lot of code to start considering shipping it.

Thanks, happy to talk more off list if needed.
Paul.




--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFWCB1n8EfJQqNUEsLWT9EFh1npzaL56cMFdx%3DfU8j0yewTu1g%40mail.gmail.com.

Daniel Bratell

unread,
Jan 24, 2019, 9:47:50 AM1/24/19
to Takashi Toyoshima, Paul Adenot, Anne van Kesteren, blink-dev
toyoshim, do you have any usage numbers? I tried looking for one but the closest I found was RequestMIDIAccess_ObscuredByFootPrinting which I don't know how to interpret. That number is 0.1% which might be a ceiling of how many page loads would be effected.

/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANWt0WoVMpymweqYOHxWPxhu-6ig0NSyapccexL%2ByqQHbRAPUg%40mail.gmail.com.



--
/* Opera Software, Linköping, Sweden: CET (UTC+1) */

Takashi Toyoshima

unread,
Jan 24, 2019, 1:02:15 PM1/24/19
to Paul Adenot, Anne van Kesteren, blink-dev
Thank you, Anne and Paul, for correction. My "to ship it" was very confusing.

So the point here is if Firefox implemented Web MIDI, Firefox won't allow using it without a permission prompting or something better trick even if the page does not request sysex permission.

This is based on current Firefox's ongoing implementation and Kyle's comments in this thread: https://bugzilla.mozilla.org/show_bug.cgi?id=836897#c59
> Note that we will be requiring user permissions for both non-sysex and sysex access. Also, we will only be exposing WebMIDI over secure contexts.

So this Chrome side change is not something takes different directions, but a thing makes potential behavior differences among implementations small.

Takashi Toyoshima

unread,
Jan 24, 2019, 1:26:01 PM1/24/19
to Daniel Bratell, Paul Adenot, Anne van Kesteren, blink-dev
Hi Daniel,

We know that some ads scan unused APIs just for footprinting, and Web MIDI's entry, navigator.requestMIDIAccess, is also called in the past days.
Today, FeaturePolicy mitigates this issue, but the number is still not so accurate. That's what 'ObsecuredByFootPrinting' means.

So, it's really hard to know how many sites really use Web MIDI, but we count the number how many users actually interacts with MIDI devices in web sites, instead.

This may draw actual users' use. It's counted only when actual connected device is opened for use.
It's about 0.001%, and major sites are hosted over both HTTP and HTTPS, but I can see some HTTP-only sites in the Sample URLs section.
So, probably we need to monitor this Sample URLs data so that often-used sites can have time to migrate.

Anyway, showing warming message would be a good starting point to reduce such HTTP-only uses, and we can postpone the milestone if HTTP-only uses are still high.

TAMURA, Kent

unread,
Jan 24, 2019, 10:05:08 PM1/24/19
to Takashi Toyoshima, Daniel Bratell, Paul Adenot, Anne van Kesteren, blink-dev
Less than 0.001% sounds low enough.  LGTM1 to remove.




--
TAMURA Kent
Software Engineer, Google


Mike West

unread,
Jan 25, 2019, 2:41:45 AM1/25/19
to TAMURA, Kent, Takashi Toyoshima, Daniel Bratell, Paul Adenot, Anne van Kesteren, blink-dev
Locking things to secure contexts always LGTM2. :)

The usage is low, only 9 sites show up on HTTP Archive after dropping duplicates, and only three of those aren't available over HTTPS. That seems like a good indication that this deprecation will go smoothly.


-mike


Yoav Weiss

unread,
Jan 25, 2019, 5:51:19 AM1/25/19
to Mike West, TAMURA, Kent, Takashi Toyoshima, Daniel Bratell, Paul Adenot, Anne van Kesteren, blink-dev

Takashi Toyoshima

unread,
Jan 29, 2019, 4:18:05 AM1/29/19
to Yoav Weiss, Mike West, TAMURA, Kent, Daniel Bratell, Paul Adenot, Anne van Kesteren, blink-dev
Thank you for discussing this.

Since the branch-cut was already passed, M75 is the current milestone to make it happen.

Andrew MacPherson

unread,
Sep 9, 2019, 12:26:04 PM9/9/19
to Takashi Toyoshima, blink-dev
Hello,

Just wondering on the status of the sysex-related part of this in M77 (latest Beta), I'm seeing this warning in the console:

"Web MIDI will ask a permission to use even if the sysex is not specified in the MIDIOptions since M77, around September 2019."

However I'm not getting a permission request and Web MIDI seems to work fine, we are running with https and not requesting sysex. Should we be seeing a permission request dialog?

Thanks!
Andrew

Reply all
Reply to author
Forward
0 new messages