Non-promise approach to midiRequestAccess for MIDI availability

[DDS9]

I have integrated the MIDI API into a more complex HUI which gets input from a variety of sources, as basic MIDI IO tests were encouraging. The app is all based on callbacks by design.

"Promises" are proving really quite unhelpful when answering the basic question of "is MIDI/is MIDI not" available and asking for a basic list of IO ports. Why force async on the programmer, until the ports are opened and in use? C++ native calls to Win32 are not async under the hood at that point, there is no need for them to be. In fact, in loading the app, these promises are not executed until long after the DOM is created, meaning creating unnecessary workarounds for calling back into it, when these promises are likely to have finished. Would much prefer to able to write:-

if( WebMidi.isAvailable ) { 
  this.midiAccess = WebMidi.getMidiAccess();  
  "...update port list DIVs..."( this.MidiAccess.getInputs() );  
}

The current implementation is forcing a particular programming style which surely should be the programmer's prerogative.

If you are minded to update the example code to show encapsulation in a class, I for one would find that more helpful than global level declared code.

Very pleased to see MIDI offered at all however, for all that. Thanks.

[djipco]

You can verity the availability of the Web MIDI API by simply checking for the presence of the requestMIDIAccess function:

if (!navigator.requestMIDIAccess) {
  console.warn("The Web MIDI API is not available in this browser.");
}

Regarding the list of I/O ports, I don't think it would be wise to block JavaScript execution while the ports are being retrieved.

Also, you have to remember that a call to requestMIDIAccess will prompt the user for authorization. The user may or may not grant access to his/her MIDI devices and s/he may or may not do so in a timely manner.

[DDS9]

I'll try that. On this occasion, the webpage is local and will most likely never be served from the net. The app will therefore need to be lazy, and just do what it did last time. I'd (in an ideal world) simply load the page and open the last opened ports, assuming they are still there. Can't see a benefit to authorising repeatedly on a locally sourced file. But maybe I am in a world of one. I have had similar issues with opening .xml files in the same folder programmatically, even if the webpage is local.

Okay - !navigator.requestMIDIAccess works. No promise structure is needed to detect MIDI or NO_MIDI.

(Interestingly, you cannot ask if (navigator.requestMIDIAccess === true).)

[djipco]

I don't think you will get a prompt at all when opening a local file that requests access to MIDI devices (I just tried it in Chromium and I didn't get a prompt). Also, even if the page is local, there is no guarantee that the ports that were available at one point will still be available later on.

[DDS9]

I have yet to see a request for authorisation.

[DDS9]

The real issue is promises. Don't feel as if they help.

[DDS9]

Maybe it's something I have coded incorrectly - this is the bones of it - although, I added the DOM manipulation code under duress. This is completely the wrong place in the app to have DOM manipulation. There are classes for that elsewhere.

    onLoad(sysexAllowed: boolean) {
        this.sysexAllowed = sysexAllowed;
        navigator.requestMIDIAccess({ sysex: this.sysexAllowed })
            .then(this.onMidiSuccess.bind(this), this.onMidiFailure.bind(this));
    }
    onMidiSuccess(midiAccess: WebMidi.MIDIAccess) {
        if (this.logging) console.log("MIDI ready!");

        this.midiAccess = midiAccess;

        let b = document.querySelector(".container");
        if( b !== null)
            b.appendChild( this.getPanel());
    }

[djipco]

Assuming your code is TypeScript or something similar, it looks fine.

[DDS9]

Yes, it's TS. A whole lot safer that naked JS! [Shudders...]

Simply opening a port in the onMidiSuccess callback demonstrates the code works just fine.

So it looks like I'll just have to update the DOM afterwards, and insert lists of ports at that point.

And that sleep statement? It's a 1 second pause, to work around those incomplete promises from WebMidi from the main UI thread. There may be better ways to handle it, but if I have to wait anyway, I'd still like the option to scan the inputs synchronously, if I choose to.

[toyoshim]

Are you familiar with async/await that are available in the modern JavaScript? Asynchronous is a very essential consensus on modern JavaScript API design and to avoid complexity on programming, we invented Promise and async/await syntax sugar. All your concerns would be solved by using it.

[DDS9]

The underlying O/S call is not async/multithreaded, and will never need to be.

This is a "get me a list" function. There is no child process needed to answer this call. So a threaded Promise here is the OPPOSITE of good engineering, because it adds complexity where it does not need to be.

(Privately, I suspect if s/w engineers have descended to the point they need "sugar" to retrieve a static list of strings, then they are probably not very good s/w engineers... ;-) )

[DDS9]

This thread can be closed. We can work around the threading issues easily enough.

[cwilso]

@DDS9 you're right, the underlying functions aren't (always) async. However, the user may well need to respond to a permission request in order to list the available MIDI devices, and this should not block the UI thread, which is why the design is async.

[DDS9]

Okay, that makes sense. How many permission tripwires are there in this? Is there a list?

[cwilso]

I'm not sure what you mean by permission tripwires. If you're asking for detail on what "may" means above - that is, when/why a UI prompt may be needed - the answer is the same as everywhere else that permissions are needed, which is that it's left up to the individual's user agent - because some browsers may run in higher or lower context, they may make such things settings, etc. For example, a browser might disallow MIDI access altogether; similarly, it might always allow it. I know that Chrome intends to ask for permission, but I believe it will be sticky (that is, once you've approved it once, it should be persistent).

Best practice should always be to presume that permission will need asynchronous response.

[DDS9]

But you are missing the point. I have been using MIDI for over 30years, and to date, a MIDI input (or even a list of 10 of them), has never ever presented a security issue. So you are trying to convince me of asynchronicity based on a need for security over non-existent security concerns, and then forcing me to write code to get around it. It's hogwash. It's like going to work for Tesla, and proposing the driver should express individual permissions for each one of the wheels to go around each time you start it up, presumably on the basis the driver might actually benefit from not moving if not.

Look, best of luck with it, but it's really not looking fit for our purpose. Think a C++ app is on the cards. One which freely and sensibly interfaces with the O/S, and where any notion of "security" is relegated to the installation process.

Thanks all for chiming in. Over and out.

[cwilso]

I, too, have been using MIDI for over 30 years. I wrote MIDI software for Windows in the early 90s. You're correct that MIDI inputs didn't create big security issues back then.

The difference, though, is how that code gets on the users' machine. If you can convince a user to install a C++ app on their machine, then yeah, you have a very high security privilege! (Less than it used to be in most modern desktop OSes, mind you, but still... pretty high.) However, that's NOT the security model for the web. If I happen to point my web browser to http://mymidiwarez.net/, as a user I don't trust that site to have the same level of security access to my hardware (or data) that I have had for all the DAWs I've used over the past decades, that I installed on my machine.

When we offer a new Web API, it has to be bulletproof - and you're missing that in your scenario, you are a trusted publisher of an application, and users are trusting you to get in your car. (I own a Tesla; obviously, your permission example would not work for me. On the other hand, my Tesla has a Web browser in it - and I absolutely do not want web APIs to be able to access the wheels in my car.

In short: you're not wrong; the problem is that the Web doesn't have "the installation process" to delegate permission/access decisions to.

[DDS9]

I respect the perception you have that there are wider issues. But not from my point of view.

• the WINMM lib is not async for port lists
• there is nothing to be gained/lost with lists of MIDI inputs, or outputs for that matter, (even with sysex (who has the time?))
• the web is not the point here, it's an app
• security is NOT the highest value on the table in this instance

So it's a C++ app for me from here, to get the truck out of the sand(box). Sure your library will work for others, and work well. All the best with it.

I think the fault is mine in choosing HTML as a cheap wireframe technology for a GUI, and that labour saving has its price. Lucky there are alternatives to developing GUIs. WPF is a stone's throw from what I have developed to this point.

[bradisbell]

@DDS9 On async access, there are other operating systems to consider as well. In any case, you can load your script as a module and do something as simple as:

try {
  const midi = await navigator.requestMIDIAccess();
  // Congrats, you have MIDI access here
} catch(e) {
  // handle the error here
}

the web is not the point here, it's an app

I couldn't agree with you more on that point. Web As A Platform is always under attack due to security fears. The constant badgering of users to authorize again and again for every feature you want is really damaging to the user experience. The file system API is all but useless now, as you mentioned previously. (Which is too bad, as it'd be a very useful API otherwise!) Fortunately though, async and initial permissions aren't really a problem for users. It looks like you're approaching this from other languages... I'd encourage you to try async/await... it works quite well once you get used to what it's actually doing.

For what it's worth, I don't think that we on the audio/MIDI side have had a better ally than @cwilso, who has done a lot of the work to get them implemented, and a lot of advocacy in holding the line to ensure we can keep them.

I think the fault is mine in choosing HTML as a cheap wireframe technology for a GUI

I don't think there's a fault here. I think you made the right decision. It's a quick way to get up and running cross-platform... usually.

[DDS9]

Yeah, I would not want anyone feeling bad about the debate or my comments. I sincerely hope none taken!

As I have sat here and thought it through, I have realised my perspective is very much that of writing an app, and not that of a web-app, or web page. I had really just hoped to use the browser as a sandbox for solving a problem with presentations on an OHP from a slow laptop. What could be faster than a webpage change? Then that moved to an RPi4, and Python... And then to MIDI in Chrome. It all feels like months ago now. Hey, I have gained a months' experience in Typescript as a result... ;-)

And as said at the top, the fact that MIDI in Chrome is here at all is great. The browser is just not the quite the right choice in this case. A faster laptop would have solved the problem just as well... But where would the fun have been in that?!

The async model has been mentioned a couple of times, yeah, I get what it does. However, my dominant experience of MIDI is multithreaded C++ (and later C#), so callbacks are more intuitive. I will bash on with this between times and see how far I get, time permitting, but I think C++ and an app will be a better onward development option, given the landscape.

[cwilso]

@dds9 I didn't take any offense. I think what I was underscoring is the Web isn't just a quick UI toolkit. Sure, you can use it that way (e.g. embed HTML UI code in your .EXE); but the Web is an end-to-end platform, including deployment and security. It has very different characteristics than native platforms like MacOS or Windows, particularly around deployment and security; that also means it has some differences in how the platform capabilities need to be exposed. If you can get a native executable on to your users' devices, great! That may be the right avenue for your scenario.

If, on the other hand, frictionless deployment of your app to multiple types of devices is a win, then the Web model's benefits may outweigh the hoops you need to jump through sometimes. For applications like Novation's Components, which lets me dump samples or edit patches on my Novation devices from any web device that I can plug into my Circuit, that is pretty awesome. For DAWs that can deploy across those boundaries, likewise pretty cool.

At the same time, those MIDI devices are getting connected to effectively untrusted code from a web page. The devices can be abused or attacked in ways that are radically different than the historical MIDI APIs in native platforms (like WINMM and CoreMIDI), because those simply aren't attacks when the user already trusts the code you're running. (or, trusts it enough to let it have access to MIDI; and yes, one fundamental difference is that native platforms tend to rely heavily on install-time permissions.) The best way to think of this is: would you want your system to automatically run an EXE that was on a web page? A web page you'd never seen before?

For example, I have dozens of MIDI devices plugged in to one of my machines. That gives it a pretty unique fingerprint. Web pages shouldn't be able to uniquely identify a user (with asking, e.g. login); native platforms, on the other hand, can do this without asking.

Also, if malicious code on web pages could also easily and silently reprogram some of my MIDI devices, that would also be bad. Users don't even think about this as an attack on native systems, because if an EXE you install wipes your MIDI devices, you're going to be able to track it back to that install; you wrapped up a lot of trust decisions into "this has good enough provenance to risk my system on".

[DDS9]

I guess I just don't think of the internet as a hive of villainy. The lion's share of my interactions are very positive, human, helpful and informative - you know, the way the internet ought to be. Villainy and suspicion are very marketable idea, of course, and drive an entire industry in antivirus s/w, etc. And rightly so perhaps. But I think I am going to draw a very sensible "snake oil" line and suggest cyber-security is out of place in MIDI exchanges of note on/off and CC messages. I assure you there really isn't anything to be gained by accessing a musical device, attempting patch theft is hardly the most profitable of pastimes I can imagine!

All humour aside, I want apps that just do what I need, without layers of needlessness. I am sure you will concur, but with age comes a certain wisdom. Coding in straight lines is counter-culture, but a lot quicker than integrating frameworks, and certainly with realtime/MIDI, all those CPU cycles are traditionally important to minimise. I think there are strong grounds for coding bravely where MIDI is concerned, and I don't want security polluting the picture. It's just not appropriate for the task at hand. And if that means making a GUI and opening a socket to do network comms, then so be it.

Very good point about cross platform, and agreed - but again, not appropriate in my case on this occasion. Win10 as a start, RPI maybe later. Useful little cards, the Pis. An exclusive RTOS for audio/MIDI O/S running on Intel/ARM would be even better. Ever evolving generic O/S are less and less fit for purpose, IMO. Less platform, and more shifting sand. Aside.

[cwilso]

Heh. I would state that I don't think of the Internet as a hive of villainy either; but these are very real problems. Already, I think we've seen that the usage of WebMIDI for silent fingerprinting quickly outstripped actual use of the WebMIDI API. Am I worried about "attempted patch theft"? Of course not. Am I worried about malicious attempts to brick MIDI devices for chaotic reasons? Slightly. Do I think Web APIs need to be designed for privacy- and security-first principles? Absolutely.

To be clear - I'm in my fifties. I started out professionally as a C++ programmer 30+ years ago, and I still have a strong affinity for that level of programming. In your scenario, it sounds like you might well be better off doing that; you don't really need the web's broad access or platform agnosticism. That's totally fine.

[DDS9]

We are agreed, and the dev decision was made back a while. C++ app.

But let's play. And I don't mean this to be condescending or patronising (which probably means it might be, so my apologies up front, just humour me.) I would like to try this security issue on for size, just to work out what you are getting at. Let's pretend you personally tried fingerprinting my rig using this library. I will tell you my rig varies day to day, it just depends on the project, and there is no machine expressible reason or data point - we musos are just prone to this sort of whim. And that's assuming I switch them all on. Which I don't. I use a subset. LEDs are pretty, but power bills are not.

To save you the trouble of writing code, you will get: two 16port ESI M8U hubs with slightly different names (as assigned by ESI and the mini dip switches on the bottom of the units), and two virtual MIDI ports. You clearly know each MIDI port has 16 channels, and you have 32x 5pin DIN sockets to explore.

I would like you to show me how knowing I have 34 MIDI ins or 34 MIDI outs (at the moment) is of use to you. I'll give you a hand. The port list has "ESI B out 1", "ESI B out 2", etc. in a long list. Propose how you intend to establish gaining the identity and capability of me, my machine, or my MIDI gear.

This would be interesting to me, because I have missed something, and I would like to take reasonable steps to add protection against your attack.

Is this WebMidi library actually far more capable than you are letting on? Or are you actually exposing issues with hard point USB descriptors from multi-function devices? Because when I say MIDI, I mean MIDI, and only MIDI. Good old fashioned stage robust 5-pin DIN sockets. I have a feeling you may actually be talking about specific USB devices that just happen to carry MIDI too amongst other things.

Another reason to never move from 5pin MIDI to USB. As if weakness of the port, cable length, brown out, intermittent behaviours weren't enough. We can now add rogue computer processes to the list.

[DDS9]

For anyone unfamiliar with ESI 16port MIDI hubs. You cannot even guarantee that a socket is an "in" or an "out" - each socket can be opened as either at the user's preference. Functionally good, but the package makes them not so great for stage usage - they are hard to rackmount effectively, the labels are too small and almost invisible printed in grey, and the location of the panel switch gets in the way of necessary tag ties. Would be fine on a desk.

[cwilso]

"Let's play" is probably not the way to start a non-condescending branch of conversation, but sure, I'll bite.

Again, I want to be clear that I understand MIDI pretty damn well, having hacked MIDI hardware and written MIDI software for around 30 years now. I, too, have a home studio with dozens of MIDI devices (both USB-based and

You seem to be missing the point when you say "when I say MIDI, I mean MIDI, and only MIDI. Good old fashioned stage robust 5-pin DIN sockets. I have a feeling you may actually be talking about specific USB devices that just happen to carry MIDI too amongst other things." Your own system is using USB MIDI - your ESI hub is a class-compliant USB MIDI device, and that's how your computer is connecting to it. It's not communicating any differently from when I plug my Novation Launchpad into a USB port.

Regardless, the MIDI system in Windows is responsible for managing all MIDI devices - USB MIDI devices (the vast majority of MIDI devices today are connected to PCs through USB), Firewire, Bluetooth, etc.). That system collapses the devices together and manages them. So far, so good - malicious messages sent (or silent "message listening") to MIDI devices wouldn't be that huge a deal. You might twiddle some lights on a keyboard, make some beep boop noises from a synth... or, at worst, wipe memory or mess with real light systems (DMX lighting control, the standard for DJ/stage lights, is MIDI-based - it generally runs over mic cables in a different hardware format, but the controls end up showing up in a PC as MIDI devices. Still, not "so" bad - chaos might ensure from malicious web pages, but not permanent damage.

HOWEVER, it's critical to realize that the vast majority of devices today use this same connection to dump firmware updates. (!). In other words, you can literally reprogram the device (my Novation Circuit, for example) by sending it MIDI sysex messages. It's bad enough that this might make it possible to brick devices - make them unusable by wiping their basic firmware - but worse yet, for some devices it might be possible to reprogram them to make them different KINDS of USB devices. (Note, in your case, I'm talking about wiping/reprogramming the firmware of your ESI hub, not whatever you have plugged into it.). If they become keyboards, they might be able to use this to fire up a password-guesser, or a keystroke logger. You might say "wait a second, then your API is more powerful than you claim!" - but no, it's actually that the MIDI devices themselves expose these capabilities, OVER MIDI. If every MIDI device were "hardened", and only accepted note-on/note-off kinda stuff, this might be different; but this is absolutely not true in the real world. Obviously, I do not know the details of your ESI hub specifically; I do know that similar devices can be reprogrammed via MIDI, and I do know that despite your claim of "5 pin DIN sockets", your device connects to your computer via USB. (BTW, many USB-MIDI devices use sysex MIDI for firmware updates because it's the easiest way to transfer data, without having to create another class-compliance on their USB device; certainly, few device manufacturers want to have to create their own drivers.)

In short, the security model of the Web is (and NEEDS to be) VERY different from the security model of an EXE on your machine. You wouldn't download and run a random .EXE from a random Web site; a random .EXE run on your machine can quickly own your machine, any data on your machine, your account... so, any Web API needs to rethink even basic functionality.

These are theoretical attacks, of course - but this isn't about attacking YOU, individually; modern security attacks are frequently a broad-scoop attack. If you can only keystroke-log credit card numbers on 0.1% of devices, but you can initiate that attack on 100,000 users - that's still 10 credit card numbers you just got. Hypothetical? Maybe. But we can't afford to just leave it hanging out there, or the Web will be unusable. At the same time, the cost of putting a web API access into an ad script somewhere is... nearly zero.

Now, as to the fingerprinting issue - again, you're thinking of this from your perspective, that your fingerprint (set of devices) changes, and thus must be useless. But the fingerprinters think of this in terms of additional bits of entropy; they don't need to be perfect, and they don't need to be unique. The vast majority of systems will have a mostly stable MIDI device map - usually it's empty, frequently it might have only one or a few devices. That's enough to be useful. I'm not suggesting this might be useful - I'm telling you that this is ALREADY in use by fingerprinting libraries, because we haven't shut down automatic exposure of MIDI devices to web pages.

[DDS9]

[Edit - I looked into "fingerprinting libraries", which was news to me. Such activity should be probably be outlawed as some form of "digital stalking". Just because people can do this doesn't mean it's ethical/legal to do so. I now understand why your port lists should require explicit permission, and your argument for the promise structure (point of the thread!) makes complete sense to me now. Thank you. I have learned something. Moving past this, assuming there is not a lot we can do, because even then, people will STILL just dismiss and grant, just like they do with cookie notices...]

So, you are saying the concern is some USB devices whose firmware can be rewritten using SysEx, if that can be achieved without a hard reset by the owner, just in case someone somewhere somehow finds a way to turn it into some form of hard spyware?

Firmware updates generally need a hard reboot with manual intervention on power up, because of the memory copy operation from flash storage to flash ROM, integrity checks, proceeding to a normal reboot. I do not have any device here which would allow a new ROM image to be installed live, or without my involvement at some point. So I find that idea quite far fetched frankly.

But, if such devices do exist, and let's assume they do, identify them publicly so users can replace them on the basis they are unaware of the security hole they represent. No one wishes to lose estate through violation of their right to privacy.

Even so, at worst this affects a handful of specific devices with poorly conceived admin functions, so the perception we are all mortally at risk here I find imaginative and even bordering on paranoia - even if it does stem naturally from other peoples' apparently endless creativity and resources for trying to ruin someone else's life, either for fun, for profit or for power.

However I just don't think it's fair to blame MIDI or even SysEx. These are perfectly useful comms formats. I also conclude my rig is secure, because it is not a nest of USB devices. Indeed, you have not persuaded me it is exposed.

Although, if you really really want to find out what gear I own, it would be so much much simpler to pop round to the studio, or come to a gig some time.

In closing, might be worth considering you are in the perfect position to make MIDI too hard for people to use because of an over emphasis on security. If web and MIDI really don't mix, on balance, I have realised I am absolutely fine with that.

[DDS9]

"Your ESI hub is a class-compliant USB MIDI device, and that's how your computer is connecting to it. It's not communicating any differently from when I plug my Novation Launchpad into a USB port."

True to a point, but I disagree. If you connect your Launchpad using a DIN socket, it remains anonymous. It's just a port and a channel, notes and ccs. If you connect your Launchpad using its USB port, its descriptor betrays its identity and opens up 2way comms.

A MIDI hub with N anonymous DIN connections is just not going to tell you anything about the ecosystem it is connected to. So even if you manage to find a MIDI DIN hub, you still have no idea what is connected to it, or why.

All these issues really seem to point to USB devices and their descriptors, and opening up 2way serial comms. They seem to have very little to do with MIDI. Well, MIDI1 anyway.

[cwilso]

@DDS9 to address your latter comment first - the actual MIDI devices plugged in to your hub are irrelevant for fingerprinting purposes (I mean, they COULD be interrogated and identified via sysex, most likely, but that takes device-specific effort).

A MIDI hub with N anonymous DIN connections is just not going to tell you anything about the ecosystem it is connected to.

This is simply wrong. A MIDI hub tells me you own a MIDI hub, which is an identifying bit. For example, if I was on my studio machine, you could tell I own a MOTU MIDI Express hub. Most users do not. That helps fingerprint me, just like if you knew my hair color, eye color, birthday, etc. - it's not a fingerprint by itself, but helps identify me.

And yes, you're right - most of the attacks have very little to do with MIDI. That is the point - ANY 2 way serial communication in the Web has to be analyzed carefully and have these attacks prevented.

[DDS9]

Thanks for your careful and patient responses @cwilso

Even so, I am unpersuaded. I am not about to start worrying about MIDI hubs or SysEx or DIN cables.

Let's rest the matter here.

[cwilso]

As to your former comments: I don't know how to put this, as I recognize I do have nearly thirty years experience in building the Web platform - yes, any possibility of abuse (of a protocol, format, API, whatever) on the Web WILL be taken advantage of. We can't rely on obscurity of hacks to save users, when the user base is a significant portion of people on the planet. Also relevant is that we can't "identify such [MIDI] devices" that might be problematic - "we" simply don't know, there are thousands of different products from the last thirty years that support MIDI, and we simply can't do a deep security analysis of each one of them. We could do an allow-list approach - but that will not provide users with a great experience, will penalize some hardware vendors, and overall be less useful for the rich diversity of MIDI devices. "It would be easier for you to just pop round the studio" misunderstands the whole way web security and privacy attacks work - this is not an attack on one user, it's an attack on billions of users at once. In the former, you need 100% success rate to be successful; in the latter, you need it to be successful in an incredible small portion of users to be worthwhile.

You are wildly misrepresenting things that I have said (e.g. "we are all mortally at risk here" and "paranoia"). All I can say is, you should be thankful there are a lot of people behind the web platform who care a lot more than you about making web experiences safe for users. I am certainly not "blame[ing] MIDI or even sysex" - in fact, I've personally been on a decade-long journey to enable and evangelize MIDI and music on the Web.

I don't particularly care if you personally use Web MIDI or not for your scenario. Indeed, I suggested you probably didn't need your application to be on the web. There are many, many other scenarios that ARE very powerful for users when they are enabled on the Web, and I'm already reaping the personal benefits of those (not having to install software on my machine). I'm not trying to get you personally to start worrying about your MIDI hub being connected, because we-the-web-platform-people will continue to ensure that is masked in a safe way.

[DDS9]

Go your way in peace. Web MIDI is not for me.

Novation have provided the following feedback in respect of SysEx firmware hacks:

"This is something that has been considered during the development of our products. Updating any of our units via SysEx requires some form of interaction from the user to have the firmware accepted by the unit. In some cases, this involves manually setting the unit into a different mode with a button combination on power up, in other cases users need to press a button on the device in order for the SysEx message to be received. Either way, the unit is not getting an update without the user setting up the conditions for it to happen. Anyone concerned about this on our products should get in touch with us directly for more information."