Support for the exclusion/inclusion of specific data types to be passed through the network.

[yuliasherman]

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.

[teoparvanov]

A couple of questions and comments from my first read-through:

[rahulga1]

Please rebase you PR.

[ishant162]

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?

[yuliasherman]

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.

[scngupta-dsp]

In addition to individual comments, a valid (close to real world use case) use case / Tutorial for this feature should be demonstrated. This would significantly enhance the understanding of this feature

[teoparvanov]

Thanks @yuliasherman, I think this approach would functionally work - although I'd prefer an object-oriented implementation of the allow/prohibit lists (if at all possible).

Here are some additional thoughts and comments:

[teoparvanov]

Approving this PR, as this seems like the best currently known approach to including/excluding "next" function parameter types. This is likely the solution that will go into 1.9, but I suggest not merging it until the alternative approach has been fully considered.

PS: In parallel, we are exploring a solution where the allow/prohibit lists become Runtime instance variables, and are passed around via the plan.yaml. This method is conceptually cleaner, but it may be hindered by the limitations of the runtime object itself (esp. from the collaborator side).