Desktopia is a fantastic tool that not only makes your game background transparent, but also creates colliders for your open windows that resize and reposition accordingly.  What we COULD have done (though chose not to in good faith) was basically keylog, manipulate files, and take over your computer. I'm not sure if the program actually goes that far, but everything I came across implies that it can.  HOWEVER, in the throes of a jam, <24hrs before the deadline, when core functions magically stop working, Desktopia does not offer a lot in the way of Unity-specific documentation or assistance. Hence writing a short blurb on it.

 Plugging Desktopia in and getting it going in Unity was just a few clicks. The fun starts when you realize you can't run Desktopia in the editor. We turned it off for short tests - but it still required an excessive amount of 'build-and-tests'. Creating a character that interacts with windows was just platformer logic. Desktopia has a collider prefab it generates in real time over all open windows -- the prefab can be tagged or layered like anything else.

 The hurdles of Desktopia arrived when we tried to use UI buttons and scene transitions. Before I get into this, I'm totally willing to admit that I'm a novice with the program and it's possible me and the other coder missed something. That said, you have about 7 bools for settings options so it seems unlikely... 

BUTTONS...

 This issue was possibly* less about UI buttons and more about that we wanted the user to interact with open desktop windows AND the game at the same time. 

 Problem: Clicking anywhere outside of a game loses Unity's focus. Sure, you can run the game in the background, but by default Unity assumes you'll never try to click UI buttons in an unfocused game (which makes perfect sense AND loops back to that, "how much info are we logging outside of a game" question...). Desktopia's workaround is that you can force the game to always be 'on top' (in focus), and disable 'click through' (which means losing background / desktop interactivity). We wanted buttons that were coverable by other windows, but always clickable when uncovered.

 Solution: Fast forward through days of mindless build-and-tests and we figured out that Unity's UI buttons weren't an option. As soon as the app is out of focus, Unity stops tracking ANY input (again, rightfully so). Desktopia, however, doesn't. The solution was to create our own buttons with colliders, get the cursor position and click info from Desktopia, and then send that info back to Unity to raycast and check if we hit something in the game. It's not that wild of a solution, but it took me a minute to get in the mindset of routing input through Desktopia.

SCENE TRANSITIONS

 Problem: This was the fun, last-minute hiccup. Our first scene followed the logic I've explained so far. We didn't care about background interactivity for the ending scenes. Because our own button workaround was more of a pain than Unity's UI buttons, the new scenes were built with UI buttons. During playtests we kept the Desktopia settings in those scenes to 'always be on top' and not able to click through (different than the initial scene). Everything seemed peachy until we did a full transition from the beginning - UI buttons stopped working in the end scenes. The buttons would work if I forced a premature transition - but not with a natural playthrough.

 I was stumped. I went mad trying to find what it was that OUR PROJECT was doing to make Desktopia behave differently across scenes. I disabled every working piece one by one and came out none the wiser. I made Desktopia an indestructible singleton - no change. I destroyed Desktopa pre-scene transition, then instantiated it with new settings before anything else executed. I never got to the bottom of this issue but my best guess is that Desktopia persists across scenes due to it partially dipping into the OS. The weird thing is it won't persist with consistent or predictable behavior. It just doesn't like scene transitions. 

 Solution: The fix was finding that Desktopia, in spite of its barbaric tantrums, would still track input after transitions. It's almost like that's what its core purpose is... So, we made more scrappy buttons (some using Ink functionality!) and everything was good again. If I were to do a similar project in the future, I would stick to throwing everything in one scene.

CONCLUSION

  Desktopia does not record data without explicitly being told to do so. Our game does not record data. HOWEVER, it has a lot of seemingly malicious potential.  I would be cautious when playing other games that use the software. It's great we were able to get our project working the way we wanted -- but, in retrospect, that really shouldn't be an option. Hopefully this is helpful to someone down the line!