Wow, I didn't expect such a response to my rant post!
So, I've done a lot of research on the problems, mostly by doing something called a 'man-in-the-middle' attack. Attack is a bit of a misnomer, it's called such because it's often used for nefarious purposes, but really all it means is that I set up my wifi to run through a special piece of software on my laptop. I then configured my phone (and laptop web browser) to trust that software. This allows me to see the otherwise encrypted traffic being sent between the MDE app/web browser and Disney's server.
From there the reverse engineering began, a lot of stuff has really obvious naming schemes, so you can infer what's going on by reading the commands. In addition, I did a lot of things like search for a dining reservation or FastPass, then took notes on what commands were exchanged. This allowed me to start writing my own commands and testing the response. I learned a few things, primarily that their web service (the software that fields requests to MDE) appears to be awful. Every single time the app asks for something simple or benign, like "What FastPasses do I have?" the web service responds with a ton of excess information. Not only does it send you the list of passes, it sends you the list of rides, the list of the rides operating hours, a lot of underlying internal identifiers for the rides, the GPS coordinates of the rides, encoded versions of the little pictures the app shows, all kinds of things. This, at a glance doesn't seem so bad, after all these are all things the app could need to show you. The problem is, it sends it all every time. Which is why it's so slow, and also why it tends to be heavy on data and battery usage! A properly designed application would send them once, if the requesting device indicated it had need for them. In an ideal case, your phone would know which rides it has data for and which it needs data for and could ask only for information that it needs. It can even say "I have information on Small World as of last week, is it up to date?" and only get data if it's stale. This is called caching and is the workhorse of the modern web. MDE seems to be designed to not take advantage of caching at all.
So that explains the slowness and heaviness of it all, but not why it doesn't tend to work well. For that, I also noticed many operations were done as a series of commands, however these commands were done without any indication of what step of the process they were on. I also noticed if you jumbled the order, it not only didn't work, but it tended to do wacky things, or just nothing, with no error message. The web service appears to rely on assumptions on the state of the users device and if something happens to make it go out of sync, it all falls to pieces. Another symptom of this is the way it will sporadically make you log in again, that's the server giving up and trying to get you to start over, but it tries to mask it by storing a cookie of what you were trying to do so it doesn't seem broken, but that often causes it to preserve the out of sync state that broke it in the first place. This explains a lot of the weirdness and why things like Incognito windows solve the problem. Private/Incognito windows automatically force your browser to start from square one and force the process to a known state. In addition, they don't preserve state so when you close and reopen them you start all over again. This mitigates the symptoms without solving the problem.
As far as the remaining problems, my theory for those is that the code is just poorly written, there is a lot of evidence of poor technique and practice in what I've looked at so far. In some cases, when I sent some requests in the wrong order by accident, very low level error messages that implied private information about the underlying software came spewing out. This is frankly terrifying, and if I did such a thing at my job I would likely be fired. All in all, the MDE software displays a startling lack of polish and technique and I'm very disappointed and surprised that Disney would put their name on something so poorly made. I would be absolutely embarrassed and appalled to call this my work and wouldn't even list it on a resume.
Matt
