←back to thread

428 points coronadisaster | 1 comments | | HN request time: 0s | source
Show context
jamesgeck0 ◴[] No.23679063[source]
> Web MIDI API - Allows websites to enumerate, manipulate and access MIDI devices.

This API is actually a bit horrifying from a security perspective. In addition to allowing you to use MIDI keyboards as input devices on websites, it also allows websites to send binary firmware updates to MIDI devices. The reason is that it's common to use custom firmware to backup/restore settings and enable neat effects and functionality on MIDI devices.

Mozilla's engineers have reasonably pointed out that an attacker utilizing Web MIDI could use MIDI devices as a stepping stone to launch an attack against the user's PC outside of the web sandbox. One such attack might be by reprogramming the device to appear as a standard USB computer keyboard and "typing" commands to the host.

At least one well known manufacturer has vouched for the technical safety of their musical instruments, noting that they're physically designed in such a way that the MIDI firmware can't alter USB firmware. But there's no way to know that every MIDI device has been similarly well designed.

As neat as Web MIDI is, I think Mozilla and Apple probably made the right security call here.

https://github.com/mozilla/standards-positions/issues/58

replies(11): >>23679155 #>>23679165 #>>23679283 #>>23679303 #>>23679633 #>>23680706 #>>23681158 #>>23681737 #>>23682770 #>>23683437 #>>23683855 #
alerighi ◴[] No.23680706[source]
What is the problem if the user give the permission to do so?

I don't get this let's not allow this web api because it's dangerous, well you only move the problem to an application that the user installs on his PC.

If the permission mechanism is correct there is no danger, a web applcation wants to access my MIDI interface or my USB or Bluetooth or whatever and it can. Isn't the same for mobile applications and permission?

So maybe and I say maybe we could stop having to ship an entire Chromium engine with Elecron just for a web application to access devices or files on the computer.

replies(2): >>23680761 #>>23681442 #
oneplane ◴[] No.23680761[source]
Because users are users and they win inevitably do the wrong thing. Normally not such a big deal, but with the interconnected world a compromised user is a big problem. It's used as a stepping stone to compromise others, cause problems to other systems by using them as slaves in a botnet or simply using them to send spam.

Users need to be protected against themselves as long as they can't take responsibility for their actions.

replies(1): >>23681453 #
evv ◴[] No.23681453[source]
If the user is going to be tricked on the web, they can be tricked in other ways. If the web doesn't support MIDI, users will just download MIDI malware as an app.

By your logic, the web should not have video support either, because users are users and it will inevitably be misused.

If you were serious about addressing this: We need clear and robust and granular permission dialogs on web and native apps. Ideally they'd be consistent across web/native, which would help users trust their software, and understand the permissions they give.

replies(1): >>23682532 #
mavhc ◴[] No.23682532{3}[source]
And then we need to crowd source what the default should be for each site, because otherwise every site will have 100 permission popups
replies(1): >>23683578 #
1. forgotmypw17 ◴[] No.23683578{4}[source]
Couldn't we hide the rarely used features behind a checkbox in advanced settings?