I was going to chime in to make clear my unease about this regressive trend towards globalized parameters on the grounds of security, but @tfoote gladly beat me to it!
This design pattern was notorious to try and account for in SROS1, where the parameter server was hosted in the ros-master, and ownership was unclear. The width of the global parameter API and its pervasive use was so much in conflict with principle of least privilege (POLP) that there was little we could do of secure parameter to any meaningful degree without breaking the establish API. See slide 14 from a previous ROSCon 2017:
I’m already quite uneasy with the growing trend of flat level parameter_events topics and its current read and write access requirements for all basic nodes:
This defeats much of our efforts to restrict data flow within the computation graph at the starting line, as every node on the network must then be given both read/write access to a commonly shared global topic. Thus much of the access control efforts in SROS2 lose their teeth, as a means for strict policy enforcement point for isolating/protecting subsystems in the same computation graph is rendered unachievable by design.