I've never been noted for my brevity either, so don't worry about that part. I much prefer someone that give an in-depth description to someone that only throws out a few statements and then you have to guess/interpret the rest, or do some rounds of back and forth answers/questions until you actually get the information you need
Regarding protection approach I guess there's many out there. Personally I've had absolutely minimal such problems, and I haven't been infested by a virus since the early 90's. I have had a couple of malware installations, and those have always come from being a payload of something I've downloaded and installed. Attachements in general have never been a problem for me, I simply think they are so easy to reveal, and honestly I don't open an attachment that I didn't "expect" or that fall naturally from that person in that context. But, my basic idea is to control the software that I install on my computers (or other network devices). If I have that under control, then I'm pretty sure there's no "rouge" activity on my local network that's originating from my equipment, and I generally don't allow other equipment in there (I use mostly wired network, and if I have to use WiFi, WPA2 is the only thing I'd use).
Firewalls are there to plug the holes that's left there by other software. They are not the only line of defence, every software or OS should take care of it's own security without a firewall, and it all depends on how you configure said software. I'd never create writable local networks shares that didn't require authentication for example, since malware attacking local network resources are nothing new (the "I love you virus" etc.).
Sadly, firewalls have earned their right to exist a long time ago since there are too many weaknesses in software to trust it's own protection. But, I see it mainly as something you'd want between the network(s) you control and the rest of the world. I really don't like the idea of having such "checkpoints" in between my local devices, it becomes a lot like the West Bank. If quickly renders everything so cumbersome that it's not worth it.
It's always a balancing point, I think any strategy that says "more security is always better" is flawed. It's the same with your house. You could build multiple levels of stone walls, wired electrical fences, several levers of protection zones guared by killer dogs, cameras, high voltage etc. Yes very few of us do this, and the reason is obvious to me: It would get quickly get expensive, and it would make life unpleasant. Who would want to visit you if they risked getting electricuted and killed or severly injured by dogs, and would have to go through multiple layers of physical security to get in or out? Very few I suspect. Yet, if we lived in an environment with high enough risk, we would probably employ most or all of those measures if we could.
For me it's the same with computers. It's all about finding the right balance, and local firewalls on a "safe" network is one of those things I consider to do more harm than good. But, it would obviously depend on what information I kept on said computer. There would be circumstances where I would deem it necessary to run a local firewall, but those would be far from "normal". I do however realize that not everybody share my assessment or strategy. But, I also think though that most people don't really have a strategy or assessment, they simply do what they read or hear from friends. The OS creators think local firewalls are convenient since they can easily adapt them to suit the need of their own software, and they don't really care about everyone else's software. At the same time they don't want to be labeled "weak" on security, so the decision is easy for them. Most users then take this as a sign that using a local firewall is considered a necessary security measure, and the idea spreads. I doesn't mean it's reasonable in most situations imo.
In principle I consider firewalls something the users apply because they don't trust the software's own protection. In many cases they are right, e.g. UMS doesn't really have a protection scheme. At the same time, it's rare that the information provided by UMS would be critical if it were compromised. In any case, because it's something applied by the user, it should also be the user's responsibility to allow or block traffic according to their own needs. Most firewalls have logging capabilities, and an easy way to figure out what needs opening is to simply log everything that's blocked, try some function you want to work and see what gets blocked in the log. Open that, rinse and repeat until said function works.
I don't like the principle of software opening what it needs in the local firewall either. If I saw the need to run a local firewall, I'd very much like to control what got through it. As long as software are allowed to punch whatever holes it like in the firewall, it almost renders it useless. We're already at a point where you're rarely at risk unless you're being tricked into doing something stupid, like installing some malicious software or give away information needed to access computers, online services, bank accounts etc. Local firewalls, as long as software is able to alter their rules, don't offer any protection against that as any malicious software would simply open the access it would need to do it's business. Again, it's a compromise made because most users don't care to aquire enough information to make their own decisions, they just want everything to work as they want it to, while their protection needs is delivered "non intrusively" by "someone" else. But, it's a compromise that makes local firewalls make even less sense.
All this said, I do see a need to better guide users about what access UMS needs to work properly. In addition to the UPnP stuff there are only two cofigurable TCP ports that need incoming access as far as I know. They default to TCP port 5001 (DLNA http server) and TCP port 9001 (web interface http server). In addition UMS needs outgoing access to contact renderers, online services if those are used and to check for plugins and updates if that is desired. Outgoing ports are probably random (when a software asks for an outgoing connection, it's often just given some arbitrarty port by to OS, but I don't know if this is the case here). That's the source port however, the destination port would be predictable depending on the type of traffic. Any IP connection has a source and destination port, but often what's meant by "port" is destination port. The easy, "normal" thing to do to cover this would therefore be to allow incoming 5001 and 9001 TCP traffic, and allow all outgoing traffic.
The part I'm unsure about is the UPnP traffic. The reason why this is somewhat unclear to us is that we use a library called "cling" to do most of this. "Cling" is big and complex, and we only know what we need to use it, not all the details about it's network traffic. What I do know is that it uses multicast, and that in itself could complicate it a little bit.
This is all dictated by the DLNA/UPnP standard, and it's really not up to UMS to decide these rules. The need should be the same for any software that use the DLNA protocol. For anyone that would want to try to map this, I would recommend turning off the local firewall and capturing traffic with Wireshark while using UMS and trying to cover as many use cases as possible. Then the captures would need to be "analyzed", that is filtered and sorted until you can boil all the details down to what access is needed to allow this traffic. I'd start by filtering on the local host and the renderer in question so that only traffic between these two are shown. I'd then work my way down from there to try to get to the bottom. It might not even be very hard to do, but it's always hard to know that one has captured all eventualities.
When that's done, a set of firewall rules would have to be crafted, and the setup would have to be verified. Everything should be tested with the firewall on and off to ensure that the behaviour is identical in either case. When this is tested to a satisfactory lever, I'd say we have what we need to make an exact documentation of what's needed.