Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2-party Asymmetric learning #61

Open
TTitcombe opened this issue Aug 5, 2020 · 0 comments
Open

2-party Asymmetric learning #61

TTitcombe opened this issue Aug 5, 2020 · 0 comments
Labels
Priority: 4 - Low 😎 Should only be scheduled if it's important relative to other issues Status: Blocked ✖️ Cannot work on this because of some other incomplete work Type: New Feature ➕ Introduction of a completely new addition to the codebase
Milestone

Comments

@TTitcombe
Copy link
Member

Feature Description

Implement an asymmetric learning protocol when calculating the ID intersection between parties.
See this paper for more information

Is your feature request related to a problem?

Asymmetric learning is the case where one of the parties in vertical federated learning has the majority of data IDs.
The major party can learn a great deal about the individuals/entities the minor party holds data on, but the minor party
learns almost nothing about the major party's dataset.

Protocols to protect both parties in this scenario include obscuring the intersection of data IDs by adding random IDs to the set sent to each party.

What alternatives have you considered?

None

Additional Context

This may need to implemented upstream by the PSI team.

This issue is should be worked on after

  • Integration with syft (i.e. we have worker-to-worker communication in place)
  • Robust PSI strategy ( securely sending IDs to and from computational server)

Open questions:

  • Should we always do an obscuring method?
  • If not, what is the determining factor?
  • Should workers be able to agree on using/not using an asymmetric protocol?
@TTitcombe TTitcombe added Priority: 4 - Low 😎 Should only be scheduled if it's important relative to other issues Status: Blocked ✖️ Cannot work on this because of some other incomplete work Type: New Feature ➕ Introduction of a completely new addition to the codebase labels Aug 5, 2020
@TTitcombe TTitcombe added this to the Syft 3.x milestone Aug 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority: 4 - Low 😎 Should only be scheduled if it's important relative to other issues Status: Blocked ✖️ Cannot work on this because of some other incomplete work Type: New Feature ➕ Introduction of a completely new addition to the codebase
Projects
None yet
Development

No branches or pull requests

1 participant