securefederatedai
Support for the exclusion/inclusion of specific data types to be passed through the network.
Summary
The Workflow API allows object code to be sent today - in part because we want the Workflow API to be more flexible and give model owners / workflow definers the ability to do things outside of horizontal federated learning. But there should be a way to configure a Workflow (at the Runtime level) that ensures that unwanted data types could not be sent. The benefit of this is that when we eventually implement the SecureFederatedRuntime, we can attest OpenFL code to ensure that malicious code can not be sent during execution.
Type of Change (Mandatory)
Security improvement
Description (Mandatory)
Allow a system to be configured in a way that prohibits/allows passing arguments of chosen types through the FLSpec 'next' function. The new parameters are defined as a Runtime class attributes to be able injecting them into the aggregator object from which the runtime object is not available.
Testing
Manual
Additional Information
The mechanism to terminate a failed experiment in a clean way while using FederatedRuntime yet to be developed.
For the FederatedRuntime, how does the Aggregator become aware of the allowed or prohibited data types configured in the Jupyter Notebook, especially in a distributed infrastructure setup? Also, have these scenarios been tested on a distributed infrastructure?
prohibited_data_types and allowed_data_types are class attributes of the Runtime class. These attributes are configured in the aggregator code and can be reviewed in the PR. The scenario has been tested with both Local and Federated runtimes. The FederatedRuntime test is expected to behave equivalently to the distributed setup.