WebMIDI #58
Comments
|
Thanks for the extra context, that made reviewing this easy. The big concern here is SysEx messages. Those have the same concerns as WebUSB. From the text in the specification, these appear to grant unrestricted access to the device. Simply asking for permission isn't a good answer to this class of problem: we can't expect someone to understand the full implications of this if the potential extent of capabilities they are extending to the origin includes rewriting firmware. The mitigations doc says:
That's not relevant. The same applies to the language assessing likelihood or difficulty of attack. What is relevant is that the possibility exists. And that includes rewriting the MIDI device to be a (remote controlled) keyboard, which has implications for not just browser security, but system security. It would be irresponsible of us to ship this without addressing this concern. As I see it, the safe options are: disable SysEx, whitelist devices for SysEx, and don't ship. I don't see a huge amount of harm in shipping without SysEx or with a whitelist. I'll let others speak to the benefits of the API. I don't do MIDI or know anyone who does, so don't have any investment. |
|
I'm also not a MIDI person, so don't really know the implications of not including SysEx. The doc says the consequences are "severe" with respect to limiting functionality. @qdot, should we ask some MIDI folks for opinions (e.g., Chris Wilson)?
5 years ago, I spent a lot of time helping with editing, implementing a polyfill, and testing this specification. I've personally seen some pretty amazing things done with it at conferences and events I've attended: like, whole parties DJ'ed realtime using the API, and really impressive controller software written specifically for the API. While I was looking into Web MIDI, I also investigated the iOS MIDI ecosystem... it's pretty vibrant (see example native apps). I mention iOS here because I believe we have an opportunity to tap into that community through the Web. From the perspective that this allows the creation of really amazing musical experiences (and it makes the web a creative outlet for talented musicians) - I'd strongly support shipping this API. It would make a lot of people happy - and make more events pretty awesome 🎹💃🕺. |
|
I agree with @marcoscaceres on the possibilities here. I'm pretty sure @obensource & friends have used the Web MIDI API in the https://github.com/websound project - I'll check with Ben for details. |
|
@qdot With respect to whitelisting, is this something that we could co-own with Google or crowdsource with the MIDI community (including device vendors)? |
|
Thanks for letting me know about this issue @marcoscaceres. Some random thoughts about SysEx and Web Audio off the top of my head: I think that (security issues aside), rewriting the firmware of a midi device is probably one of the coolest potential use cases for Web MIDI. Also a lot of devices use sysex to backup and restore presets (yet another potentially great web midi use case).
Besides system level stuff, SysEx can be vital for certain midi controllers to access advanced functionality. I use it personally in Loop Drop with the Launchpad MK2 for setting the colors of the RGB lights. Another case is for updating the LCD screen on the Ableton Push (original). I'm not sure how standard this is, but I have noticed that it is quite common for devices to only accept firmware updates when they are booted in a special mode. Most likely exactly to avoid the case where some random software pushes malicious firmware updates to a device. Unfortunately this is not the case with all midi controllers. So I think in combination with a security prompt "Would you like to allow full access to this midi device (SysEx)", this should be good enough. Maybe a warning in the message that this might allow the web page to update the firmware of the connected device? We need to find a way to support sysex safely in Web Midi, otherwise we'll be missing out on a tonne of possibilities. Still, I'd much prefer Web Midi API without SysEx than no Web Midi API at all! |
|
@marcoscaceres I've already pinged Chris Wilson, Paul Adenot, and a couple of vendors who've implemented applications using WebMIDI that are currently running on Chrome. I hope that we'll hear from them over the next few days. @stpeter Possibly! I'll let Chris Wilson speak to that, though I may try to loop in other Chrome engineers working on WebMIDI also. |
|
@mmckegg In that gdocs file in the top comment, I listed firmware reflash instructions from a few devices from different manufacturers. From the instructions, it looks like some require user gesture to reflash, while others it appears can be reflashed by just having them connected. It's that second set that are the worrisome ones, unfortunately. I should say that these firmware attack issues really only apply to USB MIDI devices too. If a device uses actual 5-pin MIDI, that'll be going through an adapter that most likely cannot be reflashed, so the potential there is less security and more annoyance. |
|
Ah, thanks @qdot. That document is a good analysis! The only addition I have would be to the Blacklist approach. Rather than blacklisting SysEx entirely on an device, could blacklist certain SysEx prefixes. For example, the Launchpad MK2 is one of the devices that can be updated without being put into a special mode. Instead this mode is achieved by sending a particular sysex message ( If the SysEx message itself was blacklisted for that device, there would no longer be a risk of the firmware being updated, and we can still have access to updating the LED colors, and scrolling text etc. |
|
Thanks @qdot & co for the hard work and commentary! I just wanted to raise that sysex firmware upgrades are the reason we built our Components app. It's the single most important use case for our customers - getting new content onto their hardware with a minimum of fuss. Yes, this means firmware upgrades without gestural input, as @mmckegg describes above. In fact, writing new third-party firmware to our devices is something we encourage (e.g. with open firmware development tools like https://github.com/dvhdr/launchpad-pro). I'm no security expert and don't wish to downplay the concerns raised. I'd happily support any initiative that gets sysex-capable WebMIDI out into the wider world, even if that does compromise the user experience. But please - it's got to have sysex! |
|
A few notes: "So I think in combination with a security prompt "Would you like to allow full access to this midi device (SysEx)", this should be good enough. Maybe a warning in the message that this might allow the web page to update the firmware of the connected device?" The problem here is that it's not obvious to users that this allows the site to quite likely take control of the user's computer. The initial framing of this was: how do we avoid this mechanism being used for firmware updates, but if that's actually a feature you are trying to enable, I don't see how to make it safe. |
|
There's still different levels of security inside of firmware updates too. For instance, are we /just/ worried about USB descriptor rewrite, which is what's required for the HID attack referenced? If so, there's nothing saying firmware rewrite would always enable that. Firmware is sometimes but not always responsible for USB descriptor handling. If manufacturers are specifically open to third party firmware, it doesn't seem like the not-security-but-annoying issue of bricking is a thing we can reasonably worry about stopping. We'd have to expect the manufacturer to put in a way to always boot to bootloader, and to make sure the bootloader can't be overwritten by USB. Not sure if this level of nuance matters in the argument or not, though, since we're mostly trying to cover unwanted firmware reflashes period. |
|
@ekr --
I think I'm reading that as "how do we avoid this mechanism being used for unwanted firmware updates?" For those devices that require the user to physically manipulate the device to initiate such an update, this seems to provide the right level of agency (unless I've overlooked something important). So whitelisting SysEx those devices that are known to have such a property would seem to get us to "safe," right? |
|
@adamroach: again, I think the user has a lot of trouble meaningfully consenting to a firmware update, so "unwanted" seems difficult. |
|
Is there any reason why SysEx access needs to be raw? Is it possible to identify common functions that are enabled by SysEx and build APIs specific to those functions? My intuition is that the breadth of applications are large and the use of SysEx is sufficiently non-uniform as to make this untenable. Thus, I might conclude that whitelisting would need to be contingent on some guarantee that either the device can't do bad things. Bad things definitely includes firmware updates, unless we have other guarantees that (for instance) this extends to a guarantee that a firmware update can't cause a device to change type or enable other new bad functions. That's a hard guarantee to extract, and a lot of effort to police effectively. I'm fairly sure that we don't want to be in that position. |
|
Hi, I'm working on Chrome Web MIDI implementation. I'm happy to discuss better permission handling to improve Web MIDI security. So, here are our mitigation approaches we already do for Web MIDI:
All three approaches are also used for other newly added device APIs that have similar concerns. For common discussion around device APIs' security, Web USB implements a device chooser prompt that is believed to be better than usual permission prompts. It's considerable to introduce a similar approach to Web MIDI. Some more information about SysEx that may be an answer for the question by @martinthomson . Major use case of SysEx is to edit sound parameters on synthesizers. Sound librarian or editing applications need it. Since such application can be developed by third-party, whitelisting does not work. Such third-party often develop an editor for retro synthesizers because original native application does not run on recent versions of Windows/Mac, or just such old devices do not have good applications. Firmware update is another major usage, and first parties really want this in Web MIDI. If SysEx is only for firmware update, whitelisting would work well. Unfortunately, just playing back Standard MIDI File (aka, .mid files) needs SysEx because it's very often used in most data to modify sound colors. |
|
Thanks for the extra info @toyoshim. I'm hearing that MIDI without SysEx is virtually useless and MIDI with SysEx is a security nightmare. Are there a common set of SysEx commands that would allow us to enable common use cases without exposing us to the possibility of things we don't want like firmware updates? For instance, if modifying sound colors is something that is common across multiple devices with the same commands, could we provide access to those commands only? Or is that too constraining? Or do certain commands have different interpretations when sent to different devices? Is it possible to develop whitelists for completely safe devices and for other devices whitelists of safe commands? That's a pretty big exercise, but it might be the only way that this could be shipped safely. I don't consider the measures that Chrome have deployed to be adequate against this level of threat. Obviously this is where Firefox and Chrome differ. Firefox doesn't ship WebUSB either, for almost precisely the same reasons. |
|
Sysex messages are supposed to work by having a manufacturer-specific header (Novation's is So you could whitelist by MMA registered vendors, and then as @mmckegg suggested, blacklist the small number of messages that can flip a device into bootloader mode without user input. I'd be surprised if there's more than a handful of devices that do this - ours do. You'd always have the possibility of tricking a user into doing a firmware update - but that possibility exists with raw *.syx files too. An attacker could disguise malicious firmware as feature update, and trick users into installing it using software they already have. But if you're going to do that, you may as well just trick them into downloading an executable. |
|
A couple of thoughts: It's totally fine to ship initially without sysex. Sysex is something most consumer use cases do not need, eg you can still send note, sync and control data without sysex. I would be fine eliminating sysex from the MVP. sysex is most commonly used for updating firmware of user data on midi devices and as was hinted at in other parts of this thread this functionality is very device-dependent. The most common workflow is something like:
You need physical access to the device, and midi hardware varies hugely in terms of how this actually works. Also, while it may be true that I personally have a midi device or two connected to my system at all times, most people do. The potential attack surface is small and diverse.
I think to initiate sending sysex from the web to hardware a permission prompt might be reasonable. If the user is in this mode, they are typically already doing a bunch of manual steps on the hardware as well as in the midi app to make this happen, and extra click isn't the end of the world. |
|
SysEx is really useful in a lot of scenarios like triggering patch changes during live performances. It would be a shame to disable it and I think it it should be the responsibility of the device to take measures against things like unilateral firmware modification. I seem to recall my keyboards requiring confirmation for things like things that overwrite memory. This situation exists with any native midi sequencer already. |
|
While I think that SysEx is the main area of threat, I don't want to lose the fact that anything is a threat here. It seems pretty clear that these devices were generally not intended to operate in an environment where the computer they are connected to them is controlled by the attacker. That means that there are quite likely defects in the processing of the non-SysEx messages that could lead to vulnerabilities and RCE, at which point we have the same problems. |
|
MIDI (standardized in 1983) assumes trusted communication among physically connected devices. Grafting that trust model onto the Web seems challenging... |
|
@ekr If we're at the point of arguing that any MIDI hardware period is vulnerable, what does that mean for our ship/don't ship criteria for this? I'm not quite sure how I'm supposed to work with that. If we're looking at it that way, GPUs were/are vulnerable too, we've seen sandbox escapes with them, yet WebGL shipped and continues to ship, and we sometimes blacklist drivers there as needed as part of that mitigation. The attack surface there is huge in terms of the user base, since video cards are kind of a requirement for computing. How is that different than what's being proposed here, between whitelisting/blacklisting/etc? I realize no one can expect full security guarantees, nor can we just hand out access everywhere and trust the world, but I'm personally not feeling like we're moving toward any middle ground in this thread so far. I'd like to poke this in that direction more, or else understand what might be missing. |
|
Also, in general for this thread, I'd say that I see WebMIDI as sort of a small litmus test for hardware API integration in Firefox in general. MIDI is a smaller use-case compared to things like Bluetooth and Sensors (WebUSB is still so new and contentious that I don't really want to bring it in to consideration quite yet for sake of not derailing completely), and those are also APIs that I'd like to maybe see happen at some point, so I'm hoping to take some points and lessons from this discussion to apply to those, if/when they come along. |
|
@qdot: I don't think that moving to a middle ground is necessarily a virtue here. The question is whether we think that this feature can be safely shipped to our users, and either it can or it can't, but it's not like if it's half-safe then it's OK to ship. WRT to the general security of MIDI hardware, my experience with embedded software is that it tends to be especially bad about defending against this class of attack, so absent either some research that suggests its generally safe or some representation from the manufacturers that it is, then it really needs to be presumed to be unsafe. Are the manufacturers willing to make that representation? I don't get the impression that they are. Now, maybe on balance that's a risk we're willing to take, but my point above is that we need to be taking that risk into account, not just assuming that !SysEx == safe. |
|
I agree with Kyle's capturing of WebMIDI as a good litmus test for hardware
API integration, as it is far more limited in scope than most.
A few specific points I want to address:
@martinthomson <https://github.com/martinthomson>> I'm hearing that MIDI
without SysEx is virtually useless and MIDI with SysEx is a security
nightmare.
This is not true. First, MIDI without SysEx will still let you use most
common keyboard controllers - at least, the keys/sliders/drum pads kind of
stuff - as ways to provide musical input to web apps. That's not useless
at all. If that's all you feel you can do, then at least you can do that.
Second, I think the concern over the scope of potential damage via sysex is
a bit out of kilter, and the user opt-in and secure origin not being
considered as any protection at all. Trust is important; but just as you
need to gain the user's trust for permission to access the camera, I don't
see this as much different.
SysEx is used for a bunch of things:
1. There are some common, non-vendor-specific controller features that
are coded via SysEx commands. Examples of these would be things like MIDI
Machine Control (MMC - http://midi.teragonaudio.com/tech/mmc.htm), which
enables extended play/pause/stop/record type control, or the MIDI Sample
Dump Standard (SDS, which lets users transfer sound multi-samples from one
device to another in a non-vendor-specific way). You could probably
recognize these as a category. Some of my keyboard controllers have
buttons like this
2. SysEx is used to edit system-specific patch settings or other
controls, or transfer whole patches or libraries (or sound samples or the
like) to and from devices. For nearly the whole of its 30 year history,
this has been an incredibly important feature, as individual instruments
tend to have limited screens and UI controls, and limited storage for
patches, and users have developed lots of communities around transferring
and trading patches. These are typically applicable only to a specific
vendor if not device. This is also used for things like configuring
flexible controllers, like DJ launchpads or LIVID controllers or the like.
3. There are some devices - like the ROLI Blocks, particularly the
Lightpad Block (https://roli.com/products/blocks) - that simply can't
map their massive data streams into the basic MIDI messages, and they
bitpack into sysex messages. These controllers wouldn't be usable without
sysex at all.
4. SysEx is most DEFINITELY used to update firmware. Vendors know this
can be reverse-engineered and hacked; they also know that users might brick
their devices if, say, someone happened to send out a Standard MIDI file
that claimed to be a killer bass sound for a particular synth and actually
contained a bricking malicious firmware update. (Yes, SysEx can - by
design - be embedded in SMFs.) This is actually an incredibly powerful
feature - for example, I have sitting just to my right as I type this a
Novation Circuit groovebox, which has updated its functionality several
times via a web page - and yes, they tell their users they need to use
Chrome or Opera for now. This is the only way to update the firmware on a
Circuit, actually - they don't have an .EXE updater, you need a Web MIDI
browser. They also offer patch updates, and unlimited library storage in
the cloud, as well as new samples you can dump on to the device this way.
Obviously, any exploit here would only be applicable to a particular device.
In short - you can, and should if that's all you're comfortable doing, ship
Web MIDI with all sysex disabled. That's not useless. However, I wouldn't
characterize sysex support as "half-safe" -I would suggest it's a powerful
feature, and should be treated like any other powerful feature.
As to @stpeter <https://github.com/stpeter>'s question - I would NOT want
to use a whitelist. There are hundreds if not thousands of new types of
MIDI devices every year, and a very large number of manufacturers.
Requiring entries on a whitelist would harm the richness of that
ecosystem. If there was every an exploit that was actually causing
significant user issues, as @toyoshim said I think we would hit the kill
switch and then start blacklisting devices; however, we've been shipping
sysex - requiring a permission prompt and secure origin - for a couple of
years now without any concerns raised.
If you're not already talking to manufacturers like Novation and Yamaha on
this concern, you should be. I'm happy to connect you if you need.
…On Thu, Mar 1, 2018 at 4:51 PM, Kyle Machulis ***@***.***> wrote:
Also, in general for this thread, I'd say that I see WebMIDI as sort of a
small litmus test for hardware API integration in Firefox in general. MIDI
is a smaller use-case compared to things like Bluetooth and Sensors (WebUSB
is still so new and contentious that I don't really want to bring it in to
consideration quite yet for sake of not derailing completely), and those
are also APIs that I'd like to maybe see happen at some point, so I'm
hoping to take some points and lessons from this discussion to apply to
those, if/when they come along.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#58 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAe8eV0_Y-qZmA-v8MBKCIe9zdeiYce_ks5taJd9gaJpZM4SVw-v>
.
|
I think it's pretty clear from upthread why it's different: the threat here is compromise of the device leading to compromise of the user's computer. Not only does no such threat exist from access to the camera (though of course USB access to the camera would present such a threat), but the user is easily able to apprehend the threat from the camera, whereas this threat is almost entirely unobvious (and in fact the discovery of the threat in other settings such as VMs lead to several academic papers). It's worth noting that we delayed releasing screen sharing for a very long time for a threat that was a lot less severe but similarly unobvious (as compared to the camera). I don't think a secure origin is relevant here. It's trivial for an attacker to get a certificate.
Hmm... I'm not sure what you mean by "without any concerns being raised". I'm pretty sure I expressed these concerns to several people at Chrome. I know I did for WebUSB and WebBT. |
|
While we're on the topic of WebUSB, https://www.wired.com/story/chrome-yubikey-phishing-webusb/ |
I'm going to guess @cwilso means "no reports of compromised devices or sites maliciously taking advantage of SysEx" (yet!). But that only holds until there is one such attack (and the severity of such an attack), which, if history is anything to go by, we can be fairly certain will happen. Reading over the arguments, it seems like MIDI devices are different from USB devices, in that there is a at least some expectation from MIDI device owners that their devices will be "patched" and/or have their firmware rewritten. Would that be a fair assessment? And would a sufficiently informative/scary permission prompt, like "You do understand that by enabling SysEx your MIDI device could be destroyed by this website? You really want to do this??!" be sufficient? In a sense... it's similar to allowing users to proceed on sites with invalid SSL certs, where we put up a bunch of roadblocks and try to get them back to safety... but if they really want to go there, they can. |
If I read the preceding comments correctly about the capabilities of SysEx, it's more like "this website could reprogram your MIDI device to act like a keyboard, and then use keyboard commands to do literally anything it wants to your machine, including uploading sensitive information -- such as your passwords, tax returns, or basically anything else of value on your machine -- to a hostile remote server." That's a lot for a dialog box, and it really only captures one dimension of the possible harm. |
|
Web MIDI API is discussed in the audio working group, and here is the GitHub repository and issues to discuss spec details. |
|
For what it's worth, I would be very interested to see this implemented in Firefox! Even if it is only a partial implementation (no SysEx), though SysEx support (with a permission popup, like what Chromium does) would be ideal. I'm building https://synth.kitchen/beta which uses the Web Audio API as an engine for in-browser modular synthesis. I'm currently only targetting Chrome because Firefox is lacking in the MIDI area. The purpose of Web MIDI in this app is to enable integration of the browser-based synth with external software/hardware MIDI devices. |
|
My Roland MT-32 basically requires SysEx messages to operate sanely. They're used for programming the voices on the device, since it's not GM compliant in its default configuration. I understand it's an ancient device by now (1987), and I'd support this API whether I could use SysEx or not, but I'd really much prefer having the ability to configure the browser to allow all SysEx messages to go through for a given Midi device/port (e.g., my USB adapter). |
|
Google Chrome is becoming more and more anti-privacy so this issue is becoming more important than ever. Because of that, I just switched to Firefox, but now I cannot even run my own apps with a MIDI device I created myself without needing to rely on a 3rd party developer's plugin (JazzMIDI). There are many suitable solutions proposed here, but this is still looking just as dead in the water as it was years ago. This is especially difficult because I am working on a medical application that incorporates musical instruments. Medical tech companies like Epic and Cerner feature streamlined deployments within their medical system that rely on standards like HL7 and SMART on FHIR. This lets you easily deploy your app within a hospital's login/authorization flow while ensuring HIPAA compliance, and in the vast majority of cases these apps are deployed as embedded web apps within a browser. It can sometimes be difficult and costly to get a native application (connected to the network) approved for use within a hospital, but if you have a web app, it is much simpler to get it approved with one of these large companies and deploy it within their system, which is browser-based. This situation also has some parallels at college campuses, though usually those systems are a little more lenient. It would add an immense amount of value to all of our projects to be able to deploy them on the web. Right now, if you want to make a web-based MIDI app, you will probably also need to make a native app to actually reach all your potential users, because asking people to download 3rd party software cuts off everyone in an IT system where that is impossible, let alone the many who pass because it's inconvenient. Depending on the business model, this could have a real impact on a small business. If we could just write a single app that runs in the browser, we can reach those extra customers without needing to repeat the work in a native app if necessary (since we could just wrap the browser in a native iOS or Android app). In reality, when faced with this choice most people will just skip implementing their app on the web, leading to this extremely frustrating musical desert that is WebMIDI in real life. For some reason non-musicians always seem to overlook the value in music software and music standards. It isn't just for people making music. It's for therapists, health professionals, educators, and researchers. The value isn't just in the software available, but what the people exposed to that creative software will create. We're years behind where we should be in terms of music technology. It's only slowly starting to come around, and Mozilla is the main roadblock holding us back right now. The fact that WebMIDI is not implemented in one of the major browsers is really holding back potential economic growth in multiple areas. It's stifling innovation in both music, computer science, and business. It's frustrating that it is not a higher priority to whoever is making the decision to hold back on implementing a web standard that has been around for years. I don't think the people doing the cost/benefit analysis on whether to implement this really know the actual cost of not having this in Firefox. |
|
Chris I share your frustration with Firefox's pace on this, but have you considered running the Brave browser? It uses Chrome's core (and therefore gets web MIDI), but should protect you from Googles "anti-privacy" issue. Side benefit, unlike Chrome or Firefox, you can read the New York Times etc without hitting a paywall. :) |
|
Long time MIDI user, first time caller. Just want to add an additional voice to the "Skipping SYSEX for an MVP is absolutely ok!" contingent. Particularly as a counter to some of the "MIDI without sysex is useless" type comments above. The vast majority of use cases for MIDI (making music) do not involve system exclusive messages at all.
I'm an old MIDI head. Yes, sysex matters. It's used for all sorts of wonderful things. That said, the lack of sysex support is not a blocker for doing a wide range fun and useful things with MIDI. |
|
I've locked the conversation for now as a diverse set of opinions have been captured, and this has given us a lot to reflect on. Thanks everyone for your input! |
|
Unlocking so we can move this forward towards closure. |
|
Mozilla has done a bit of work implementing this API (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=836897) and there are sites experimenting with it. Are we ready to tag this API with some positive signals like "worth-prototyping", since it seems like we have? @bholley |
|
Hi folks, we've done some work on this recently and are aiming to ship WebMIDI in Firefox 108 (currently Nightly, will ride to Beta next week). It uses a novel add-on-based exposure mechanism, for which I've outlined our thinking in #704. Please give our implementation a try, and let us know how it works for you! Constructive feedback is welcome, ideally on Bugzilla. |
|
I think that it is more appropriate to answer questions regarding this position here, on the issue, rather than a pull request, so I'm moving discussion over into a single reply:
The dialog we are using here is the totally generic "install an add-on" one, which includes this text. We did discuss not using this dialog, but we concluded that this is not an exaggeration and this level of warning is appropriate. We are enabling sysex access through this API, which can very much lead to problems in poorly-implemented MIDI devices.
This is fair, though I believe @bholley was only referring to the current state of the Chrome implementation. This comparison is important because the approach taken by Chrome (in the past) creates some web compatibility challenges for us. @fabricedesre asks and so does @johannhof what benefits we see from this approach. There are several:
Edit to add: Some of these benefits can be realized by other means; but these are just the approaches we believe strike a reasonable balance. |
Is that backed by user testing, with regular browser users (not security / privacy engineers)? I find it doubtful that people will not just click on whatever prompt, however strong the warning can be.
How do you block synthesized add-ons? Don't they get a random ID? I would also like to note that in the end, this all looks very similar to the chrome model. In particular this does not address issues with malicious code being served unknowingly of the site maintainer. |
|
It might be helpful to take a step back here and examine the existing capability and consent surface in Firefox. A simplified view is that sites can do four kinds of things, in order of increasing risk:
The latter two suffer from the usual difficulties of conveying the concrete nature of risk, but they’re baked into the preexisting rules of engagement. The metaphor is: browsing a website is something you can do casually, but installing software requires you to trust it. Not every user understands this, but most seem to, and protecting those who don’t is a hard problem. This is how things already work today. Returning to WebMIDI, our view is that the risks of direct access to non-hardened hardware devices are too high for bucket (2). Thus far, the fallback for these use-cases has been (4). We see an opportunity to move them to (3), which improves on the safety and ergonomics of native software while remaining covered by the “install” metaphor and the associated concept of trust [1]. It’s a valid concern that expanding usage of (3) risks making the experience less novel and making users more inclined in the future to just click through. Our hypothesis is that the good-faith use-cases of this API are infrequent and intentional enough to mitigate this, but this is one reason we’re treating WebMIDI as a limited experiment for this approach. [1] Technical note: the implementation differs in a few minor ways from regular extensions, e.g. they have a separate category in the add-on manager, we’ve tweaked the consent text a bit, and the blocklist is indexed by domain rather than UUID. |
|
When users install a browser extension, this is a flow they trigger explicitly. That sets the expectations properly, and they install them from a trusted site (AMO or similar). Here the context is different since the add-on installation is triggered as a side effect of opening a site that uses some api. Maybe using a gating add-on helps with blocking etc. but from a UX point of view it's very unconvincing. |
|
@bholley is there a blog post or the like that explains how things work now? (because if it's locked behind a third party gatekeeper website again, rather than having firefox auto-generate whatever addon it needs when it sees a website try to use the web midi APIs, that's still a hard pass for me) |
|
@Pomax it's auto-generated. Grab a recent Nightly and give it a try. |
|
Just did: that's so much nicer! Glad to see this finally landing with a low-friction solution! If I could make one recommendation though, when it pops up the initial "do you want to install this addon?" dialog, it's probably a good idea to say what that addon is for. As is, it doesn't actually tell you why a website is causing an addon dialog to pop up until after you allow it, when it tells you which specific permission(s) the site is trying to use. |
|
@Pomax thanks. We've updated the UX a bit in a way that I think should address your feedback. |
|
let me know when that's in nightly and I'll give it another spin! |
and others
Request for Mozilla Position on an Emerging Web Specification
Other information
WebMIDI has been in development in Firefox since 2015. The DOM API (https://bugzilla.mozilla.org/show_bug.cgi?id=1201590) recently landed, but is pref'd off on all branches, runs only in tests, and was mostly landed to curb bit-rot. Platform implementation bugs exist at:
The major blocker right now is security issues related to device firmware hijacking. There's a public google doc available listing issues and ideas for mitigation at
https://docs.google.com/document/d/1SjYRmNvQKxOPHufWbx6n0NOeTKKd_O1WIiTBZAjVj5E/edit#heading=h.lavkfo6fb57g
The text was updated successfully, but these errors were encountered: