PaperlayerView exact revision on arXiv

Source-linked AI summary

Advances and Open Problems in Federated Learning

Peter Kairouz, H. Brendan McMahan, Brendan Avent, Aurélien Bellet, Mehdi Bennis, Arjun Nitin Bhagoji, Kallista Bonawitz, Zachary Charles, Graham Cormode, Rachel Cummings, Rafael G. L. D'Oliveira, Hubert Eichner, Salim El Rouayheb, David Evans, Josh Gardner, Zachary Garrett, Adrià Gascón, Badih Ghazi, Phillip B. Gibbons, Marco Gruteser, Zaid Harchaoui, Chaoyang He, Lie He, Zhouyuan Huo, Ben Hutchinson, Justin Hsu, Martin Jaggi, Tara Javidi, Gauri Joshi, Mikhail Khodak, Jakub Konečný, Aleksandra Korolova, Farinaz Koushanfar, Sanmi Koyejo, Tancrède Lepoint, Yang Liu, Prateek Mittal, Mehryar Mohri, Richard Nock, Ayfer Özgür, Rasmus Pagh, Mariana Raykova, Hang Qi, Daniel Ramage, Ramesh Raskar, Dawn Song, Weikang Song, Sebastian U. Stich, Ziteng Sun, Ananda Theertha Suresh, Florian Tramèr, Praneeth Vepakomma, Jianyu Wang, Li Xiong, Zheng Xu, Qiang Yang, Felix X. Yu, Han Yu, Sen Zhao

arXiv:1912.04977v3cs.LGcs.CRstat.ML

TL;DR

Federated learning research lacks a broad synthesis of its practical constraints, privacy assumptions, advances, and open challenges. This paper surveys recent developments and organizes unresolved problems and research directions across the field.

  • Problem

    Federated learning requires a broad account of its defining characteristics, practical constraints, privacy assumptions, and unresolved research challenges.

  • Method

    The paper synthesizes recent federated learning advances, examines system and threat-model considerations, and enumerates open problems and research directions.

  • Results

    The paper identifies extensive challenges spanning efficiency, privacy, security, poisoning, and fairness in federated learning.

  • Takeaways & Limitations

    Federated learning research must account for system constraints, nonbinary privacy guarantees, poisoning risks, and fairness issues arising from federation-specific sampling.

  • Takeaways & Limitations

    Secure aggregation assumes a semi-honest server, exposes per-round aggregates, is inefficient for sparse vectors, and cannot enforce well-formed client inputs.

Abstract

from arXiv · show

Federated learning (FL) is a machine learning setting where many clients (e.g. mobile devices or whole organizations) collaboratively train a model under the orchestration of a central server (e.g. service provider), while keeping the training data decentralized. FL embodies the principles of focused data collection and minimization, and can mitigate many of the systemic privacy risks and costs resulting from traditional, centralized machine learning and data science approaches. Motivated by the explosive growth in FL research, this paper discusses recent advances and presents an extensive collection of open problems and challenges.

1 Introduction

Federated learning enables clients to collaboratively train models under central coordination while keeping raw data decentralized. The paper surveys FL’s defining settings, practical constraints, applications, and interdisciplinary open challenges.

  • Federated learning definition: Federated learning coordinates multiple clients through a central server while keeping training data decentralized, supporting focused collection and data minimization.Clients exchange focused updates for aggregation rather than transferring raw data.
  • Federated learning definition: The defining FL challenges include unbalanced, non-IID data distributed across massive numbers of unreliable devices with limited communication bandwidth.These challenges were introduced with the term federated learning in 2016.
  • Open challenges: The paper’s open problems are inherently interdisciplinary, spanning distributed optimization, cryptography, security, differential privacy, fairness, compressed sensing, systems, information theory, and statistics.The authors argue that collaboration across these areas will be essential because many hard problems lie at their intersections.
  • Federated learning settings: FL spans cross-device settings with many mobile or edge clients and cross-silo settings with smaller numbers of relatively reliable organizations.The paper primarily considers cross-device FL unless otherwise noted, while recognizing that many problems apply more broadly.
  • Applications and ecosystem: Applications include consumer products such as Gboard, Pixel phones, and Android Messages, as well as cross-silo domains including finance, pharmaceuticals, healthcare, and smart manufacturing.The paper also notes that FL tools, frameworks, and commercial data platforms are becoming available.

2 Relaxing the Core FL Assumptions: Applications to Emerging Settings and Scenarios

Fully decentralized learning replaces server coordination with peer-to-peer communication, addressing central-server failures and bottlenecks while introducing open problems in robustness, personalization, communication, privacy, and trust. Distributed-ledger approaches may decentralize aggregation, but public blockchain data creates additional privacy concerns.

  • Fully decentralized learning: Peer-to-peer communication over a sparse connected graph replaces server communication, limiting each client’s messaging to a small number of peers.The topology contrasts with server-based communication and is central to fully decentralized learning.
  • Open problems: Decentralized learning must tolerate unavailable or changing clients and unreliable networks, including dropouts, joins, and message loss.Robustness to these conditions remains especially challenging for deep learning.
  • Open problems: Asynchronous algorithms let clients activate independently, removing global synchronization and potentially improving scalability.Topology also affects consensus, convergence, and communication delays, creating tradeoffs between denser connectivity and messaging costs.
  • Open problems: Under non-IID data, decentralized learning requires personalized models, while local updates, compression, and quantization must preserve convergence under practical constraints.These challenges involve analyzing multiple local steps, limited bandwidth and energy, and communication-efficient decentralized optimization.
  • Open problems: Decentralized privacy mechanisms must prevent clients from reconstructing others’ private data while maintaining model utility, but local noise can reduce utility.Differential privacy is presented as the standard mitigation approach, with noise added locally by each client.
  • Practical realization: Blockchains and smart contracts could decentralize model aggregation, but public data on current platforms may discourage participation because privacy motivates federated learning.Practical realization through distributed ledgers is one family of approaches, while other implementations remain unexplored.

3 Improving Efficiency and Effectiveness · 3.1 Non-IID Data in Federated Learning · 3.2 Optimization Algorithms for Federated Learning

The section examines how federated learning can become more efficient and effective, focusing on non-IID data and optimization algorithms. It surveys data heterogeneity, mitigation strategies, Federated Averaging, convergence behavior, and practical open problems.

  • 3 Improving Efficiency and Effectiveness: Improving federated learning efficiency and effectiveness requires better optimization, communication, model, and task-specific techniques, with non-IID data as a fundamental challenge.The section also identifies personalization, hyperparameter and architecture search, debugging, and model customization as related directions.
  • 3.1 Non-IID Data in Federated Learning: Non-IIDness arises from differences across clients and over time, including user-, location-, and time-based partitioning, changing client availability, and local temporal correlation.Local shuffling can generally resolve intra-client correlation, while changing client or data distributions can create dataset shift.
  • 3.1 Non-IID Data in Federated Learning: Real-world federated datasets likely combine multiple non-IID effects, but empirical studies have largely focused on synthetic label distribution skew, leaving their characterization an open question.Different regimes may require different mitigations: a shared P(y | x) can support one global model, whereas client-specific label mappings may require personalization.
  • 3.1 Non-IID Data in Federated Learning: Non-IID data makes a single global model harder to train and motivates modified algorithms, shared proxy data, alternative objectives, and client customization.A single model remains useful for clients without data and for centralized validation or quality assurance, but local training enables customized models.
  • 3.2 Optimization Algorithms for Federated Learning: Federated optimization must handle non-IID and unbalanced data, limited communication, unreliable devices, client sampling, and stateless participation, while remaining composable with privacy and compression techniques.Large cross-device systems require only a handful of participating clients per round, and devices may participate no more than once for a model.
  • 3.2 Optimization Algorithms for Federated Learning: Federated Averaging runs local SGD steps on selected clients and averages their updated models, reducing communication while introducing optimization-theoretic challenges.This design addresses data locality and limited mobile-device communication capabilities.
  • 3.2 Optimization Algorithms for Federated Learning: In IID convex optimization, minibatch SGD achieves the optimal statistical term σ/√(TKM), while single-device SGD achieves the optimal optimization term H/(TK)^2.Local-update analyses later improved the optimization term to HM/T under weaker assumptions, but typical cross-device values T = 10^6 and M = 100 imply K = 1 when K is smaller than T/M^3.
  • 3.2 Optimization Algorithms for Federated Learning: Non-IID convergence is worse and requires assumptions on data dissimilarity; FedProx improves Federated Averaging empirically, while client-selection patterns and heterogeneous local steps remain practical concerns.Theoretical results address partial participation, semi-cyclic sampling caused by diurnal availability, and variants of Federated Averaging under smoothness or Lipschitz-gradient assumptions.

3.3 Multi-Task Learning, Personalization, and Meta-Learning

This section examines multi-model approaches that personalize inference across clients, especially under non-IID data, spanning multi-task learning, local fine-tuning, and meta-learning. It highlights open questions about personalization methods, evaluation metrics, theoretical guarantees, and realistic FL benchmarks.

  • Multi-model approaches: Multi-model approaches assign different model parameters to different clients and may outperform the best shared global model under non-IID data.Personalization has also been studied in fully decentralized settings, where training individual models is particularly natural.
  • Multi-Task Learning: Multi-task learning treats each client’s local learning problem as a separate task, while task definitions can range from individual clients to client subsets.MOCHA directly addresses communication efficiency, stragglers, and fault tolerance in multi-task federated learning.
  • Personalization: Local fine-tuning trains one global model before deploying it to clients for additional local training, preserving federated training with only small client samples per round.The section identifies choosing the personalization technique and establishing its learning guarantees as key problems.
  • Meta-Learning: MAML-style methods meta-learn a global starting model that can adapt to a task using a few local gradient steps, with Reptile’s training closely related to Federated Averaging.The relationship includes a server learning rate in Reptile and assumes equal client dataset sizes.
  • Meta-Learning: Open problems include realistic FL benchmarks and theoretical guarantees for MAML, as well as comprehensive metrics for comparing personalized performance across clients.The section specifically questions whether small improvements for every client should be preferred to larger improvements for a subset.
  • Open Problems: Models optimized for global performance may have reduced capacity for later personalization, motivating further study of training objectives and personalization across FL settings.The section also asks whether concept drift and non-parameter-transfer methods such as ProtoNets can be analyzed or used within this framework.

3.4 Adapting ML Workflows for Federated Learning

Adapting machine learning workflows to federated learning creates challenges across data processing, model design, optimization, and debugging because data are decentralized and devices resource-constrained. Major open problems include efficient hyperparameter tuning, federated neural architecture search, and privacy-preserving inspection of decentralized data.

  • Workflow adaptation: Federated learning complicates standard workflows—including data augmentation, feature engineering, architecture design, model selection, hyperparameter optimization, and debugging—on decentralized data and resource-constrained devices.These challenges arise because conventional workflows assume more direct access to data and resources.
  • Hyperparameter optimization: Repeated training rounds with different hyperparameters can overuse limited communication and compute resources on small device populations, while large-model evaluations and on-device datasets can be expensive.The resource burden is especially restrictive for resource-constrained mobile devices.
  • Hyperparameter optimization: Federated training adds hyperparameters for aggregation, global model updates, local client optimization, and client selection beyond centralized learning-rate, momentum, batch-size, and regularization choices.Developing easy-to-tune optimization algorithms is identified as a major open area.
  • Neural architecture search: Federated neural architecture search could avoid redundant components and unnecessary device computation when predefined architectures are poorly matched to users’ unseen data.Its motivation stems from model developers lacking visibility into the data generated by users.
  • Data inspection and debugging: Privacy-preserving techniques for sanity checking, debugging misclassifications, finding outliers, labeling examples, and detecting bias in decentralized data remain a major open problem.These tasks are commonly supported by directly inspecting data subsets in centralized workflows.

3.5 Communication and Compression · 3.6 Application To More Types of Machine Learning Problems and Models · 3.7 Executive summary

Federated learning research addresses communication bottlenecks through compression while extending beyond supervised learning to additional paradigms and uncertainty-aware models. Across these areas, substantial practical and theoretical challenges remain, including privacy compatibility, scalability, convergence, and deployment.

  • 3.5 Communication and Compression: Compression targets gradient updates, server-to-client model broadcasts, and local computation, with gradient compression often offering the greatest runtime impact.These objectives are generally complementary; slower client upload bandwidth and cross-client averaging make gradient compression especially promising.
  • 3.5 Communication and Compression: Compressed or quantized communication remains difficult to combine with Secure Aggregation and differential privacy mechanisms.A straightforward Secure Aggregation application can require O(log M) additional bits per scalar, where M is the number of clients.
  • 3.6 Application To More Types of Machine Learning Problems and Models: Federated learning is being extended beyond supervised learning to reinforcement, semi-supervised, unsupervised, active, and online learning, but these extensions remain open challenges.The paper notes that FL has primarily considered supervised tasks with naturally available client labels.
  • 3.6 Application To More Types of Machine Learning Problems and Models: Bayesian methods offer uncertainty-aware models and preliminary evidence of aggregation across non-IID data and heterogeneous platforms, while scalability and computational feasibility remain unresolved.Most modern deep learning models do not represent predictive uncertainty or provide a probability interpretation of parametric learning.
  • 3.7 Executive summary: Non-IID data and client heterogeneity remain central open problems, while theoretical analyses struggle to explain Federated Averaging’s empirical effectiveness.Known convergence rates do not fully explain the observed effectiveness of Federated Averaging, and analyses often require restrictive assumptions.
  • 3.7 Executive summary: Personalization and multi-model approaches may address data heterogeneity and surpass the best fixed global model, but their theoretical and empirical conditions remain unclear.Open questions include when a global model is preferable, how many models are needed, and which optimization algorithms best combine with local fine-tuning.
  • 3.7 Executive summary: Adapting hyper-parameter tuning, neural architecture design, debugging, and interpretability from centralized workflows presents roadblocks to practical FL adoption.These adaptations therefore constitute important open problems for widespread deployment.
  • 3.5 Communication and Compression: Communication efficiency and compression remain active research areas, especially for automating convergence-preserving compression, privacy compatibility, and wireless-infrastructure co-design.Wireless interference, noisy channels, and channel fluctuations can hinder information exchange, training latency, and system reliability.

4 Preserving the Privacy of User Data

This section defines ideal privacy goals for federated learning: limiting each actor’s knowledge and enabling informed participation decisions. It presents federated learning’s modular, data-minimizing structure while emphasizing that baseline model updates lack formal privacy guarantees and that important challenges remain.

  • Privacy goals: Ideal privacy would limit each actor to the information needed for their role and let participants make informed choices about participation.An analyst might need only a quality-threshold decision, not training data or model parameters.
  • Open challenges: Achieving these privacy goals alongside usability, quality, fairness, efficiency, and resilience is daunting for both individual modules and the complete system.The section notes that it remains unclear how to achieve all objectives simultaneously.
  • Federated learning structure: Federated learning supports modular analysis and data minimization because raw user data stays on devices while model updates are sent to the central server.The section advocates studying modular units independently while evaluating the complete system against ideal privacy goals.
  • Privacy limitations: The baseline federated learning model provides no formal privacy guarantee, since model updates can enable inference of client-held training examples.A scenario involving the previous model and a user’s gradient update can reveal information about raw data.

4.1 Actors, Threat Models, and Privacy in Depth

Federated-learning privacy requires a holistic characterization of actors, roles, threat models, capabilities, and differentiated privacy goals rather than a binary or scalar notion. Achieving these properties typically requires composing layered protections whose guarantees degrade gracefully when individual assumptions or techniques fail.

  • Actors and threat models: Privacy is not binary or scalar, so systems should characterize actors and roles before defining relevant threat models.The section distinguishes, for example, server administrators from analysts who consume learned models.
  • Actors and threat models: A system may provide differential-privacy guarantees with ε to server administrators while analysts receive stronger protection ε′ < ε.The guarantees can differ according to the observer’s view of the system.
  • Actors and threat models: Threat models must specify adversary capabilities, including server observation, control of up to fraction γ of clients, behavioral influence, and cryptographic limitations.The example considers an adversary observing server activity while controlling clients and unable to break instantiated cryptographic mechanisms.
  • Privacy goals: Privacy goals and assumptions can require concrete parameters such as ε, ε′, ε0, γ, and σ, alongside differential privacy and honest-but-curious security.Precisely specifying the system’s assumptions and goals determines which parameters and security concepts are relevant.
  • Composed protections: End-to-end privacy typically requires composing multiple tools, including layered defenses such as running secure MPC components inside trusted execution environments.Layering strategies can make components harder for adversaries to compromise sufficiently.
  • Composed protections: Privacy protections should degrade gracefully when one technique fails; MPC inside a TEE can preserve privacy if either, but not both, security assumptions fails.This design aims to retain protection despite the failure of one contributing mechanism or assumption.

4.2 Tools and Technologies

Federated learning privacy requires addressing information flow during computation, disclosure from the computed result, and verifiability of faithful execution. Relevant technologies include MPC, homomorphic encryption, TEEs, differential privacy, remote attestation, and zero-knowledge proofs, each with practical design or trust challenges.

  • Privacy aspects: FL privacy has three aspects: protecting information flow during computation, limiting disclosure from the result, and verifying faithful execution without exposing private data.MPC and TEEs address computation and information flow; differential privacy addresses disclosure; remote attestation and zero-knowledge proofs address verifiability.
  • Disclosure and verifiability: Differential privacy protects against information disclosure from the computed result, while remote attestation and zero-knowledge proofs support verifiability of system behavior.Shuffling models can achieve much smaller error than the local model under weaker trust assumptions, and SNARKs offer efficient proof-size and verification properties at the cost of stronger assumptions and trusted setup.
  • Secure multi-party computation: MPC computes an agreed-upon function over private inputs while revealing only the intended outputs, but practical systems often require custom protocols for specific applications.Custom protocols have been designed for linear and logistic regression, neural-network training, and inference because generic solutions can be impractical.
  • Homomorphic encryption: Homomorphic encryption performs selected mathematical operations on ciphertexts and can support MPC, but federated learning must prevent the server from decrypting individual client contributions.Distributed or threshold encryption addresses this issue by distributing the secret key among parties for computations such as cross-device summation.
  • Trusted execution environments: TEEs can move federated-learning computation into an attested cloud environment providing confidentiality, integrity, and measurement, but current enclaves have limited memory and no GPU access.TEEs also struggle to fully exclude all types of side-channel attacks, particularly on shared microprocessors.

4.3 Protections Against External Malicious Actors

Protecting FL against external malicious actors requires understanding what adversaries can learn from intermediate iterates and final models across clients, analysts, and deployments. Open problems include quantifying attack susceptibility, adapting privacy mechanisms to cross-device settings, auditing implementations, concealing iterates, and defending inference APIs.

  • Threat models: Malicious clients, analysts, and devices can access intermediate iterates, sequences from multiple runs, or final models, creating distinct external-adversary threat surfaces.The paper emphasizes first determining what can be learned from intermediate iterates and final models.
  • Attack quantification: Federated learning may enable tractable average-case or worst-case attack-susceptibility quantification and adaptive defenses through server control over access and influence during training.This setting could support defenses applied on-the-fly to preempt attacks.
  • Differential privacy: User-level differential privacy clips individual updates, aggregates them, and adds Gaussian noise, but cross-device FL still requires adaptive contribution bounds under highly variable participation.Privacy amplification and formal (ε, δ) guarantees remain challenging with dynamic eligible-user sets and participant dropouts.
  • Implementation assurance: Differential privacy implementations require auditing, including black-box testing, because privacy and security protocols are notoriously difficult to implement correctly.Computational differential privacy also depends on cryptographically secure randomness for privacy-ledger sources such as device sampling and additive Gaussian noise.
  • Model concealment: Even when model parameters are hidden, adversaries may reconstruct them through inference or prediction APIs, leaving protections for models deployed on end-user devices as an open question.Trusted execution environments are proposed as one way to conceal intermediate iterates from clients.

4.4 Protections Against an Adversarial Server

Protecting federated learning against an adversarial server is difficult in cross-device settings because clients rely on the server for communication and cohort formation. The section frames privacy as limiting server reconstruction of client data while examining differential privacy, shuffling, secure aggregation, and unresolved trust and trade-off questions.

  • Challenges: Cross-device clients cannot readily establish secure channels independently of the server because they communicate through a star topology and may have limited connectivity and bandwidth.These constraints complicate enforcement of a desired trust model.
  • Challenges: A malicious server can manipulate cohort formation through Sybil attacks or preferential selection of compromised devices, undermining privacy even when the protocol itself remains secure.Privacy may also fail when the adversary knows or controls many adversarial clients’ updates, including in TEE-based systems.
  • Privacy goal: The central privacy goal is to formally define the server’s view of client data and quantify and provably limit its ability to reconstruct an individual client’s input.This goal follows from FL’s objective of learning population-level patterns rather than individual inputs.
  • Existing protections: LDP avoids trusting a central server through client-side randomization, whereas hybrid and shuffle models retain unresolved assumptions about trust, distributions, or intermediaries.Hybrid methods commonly assume identical data distributions across trust groups, while shuffling requires a trusted intermediary that users may not trust.
  • Existing protections: Secure aggregation offers strong, dropout-robust privacy and can scale to billions of parties, but it assumes a semi-honest server and therefore does not fully address an adversarial one.Its FL-specific design supports large numbers of parties and vector lengths, while the semi-honest-server assumption remains a limitation.
  • Open problems: Open problems include characterizing accuracy, privacy, and communication trade-offs under distributed DP and determining realistic assumptions about compromised servers and clients.Related work also asks for optimal aggregation algorithms under fixed communication budgets and minimum achievable error.

4.5 User Perception

User perception research must clarify FL’s privacy benefits and limitations, prevent false confidence, and help users feel safe while actually understanding the protections provided. Key directions include preference-sensitive privacy, informed preference elicitation, and education about FL and data use.

  • User understanding: Practical research should make each FL implementation’s benefits, limitations, privacy sufficiency, and data-minimization claims intuitive to average users.Open questions include whether FL can create a false sense of privacy and how users can feel safe while actually being safe.
  • Preference-sensitive privacy: User-specific privacy preferences could relax differential privacy constraints when users do not equally fear all possible inferences.The Pufferfish framework protects analyst-specified predicates while allowing other predicates to be learned without differential privacy, but requires understanding users’ task-specific privacy needs.
  • Preference-sensitive privacy: Further work should incorporate user preferences into FL models and develop techniques for meaningful preference elicitation.Behavioral and field research should support informed preferences through education and preference measurement.
  • User education: Education should explain the privacy technology, data use, FL, and exactly what data will be sent to the server.Researchers should first verify that typical users meaningfully understand the privacy guarantees offered by private learning processes.
  • Behavioral research: Behavioral research on eliciting differential-privacy preferences remains limited, making its extension important for widespread private federated-learning implementations.Educational research results can support future preference elicitation, building on evidence that people behave differently when choices are public versus private.

4.6 Executive Summary

Privacy in federated learning depends on both what function is computed and how computation is executed, using complementary techniques such as data minimization, differential privacy, MPC, HE, and TEEs. Key open problems include deploying these methods without exhausting privacy budgets, reducing secure-computation overhead, building exploit-resistant TEEs, and protecting against adversarial servers.

  • Privacy: Privacy requires considering both the computed data function and execution details, including who can see or influence intermediate results.The “what” and “how” dimensions motivate distinct but complementary privacy techniques.
  • Privacy: Data minimization and differential privacy address what is computed, but adapting privacy accounting and privatization to real deployments remains an open challenge.The challenge includes overlapping populations, time-evolving data, multiple independent actors, client availability, privacy-budget depletion, and utility preservation.
  • Privacy: MPC, homomorphic encryption, and TEEs address how computation is executed, but secure functionality can remain communication- and computation-expensive, while reliable exploit-immune TEEs remain unresolved.Supporting infrastructure must also connect attested binaries to specific privacy properties.
  • Privacy: Privacy in Depth should compose techniques so privacy expectations degrade gracefully after a component compromise, while distributed differential privacy can provide high accuracy and privacy across several trust models.The stated trust models are an honest-but-curious server, a trusted third party, and a trusted execution environment.
  • Verifiability: Verifiability uses zero knowledge proofs and TEEs to establish faithful execution, yet strong protection against an adversarial server remains a significant open problem.Verifiability enables parties to prove that they executed their computation parts faithfully.

5 Defending Against Attacks and Failures

Federated learning faces adversarial attacks and non-malicious failures arising from its distributed architecture, third-party participants, unreliable devices, private data, and constrained communication and computation. The section surveys attack goals and capabilities, failure modes, defenses, and the tension between robustness and privacy.

  • 5.1 Adversarial Attacks: Data poisoning attacks are special cases of model update poisoning, but it remains unclear which model update attacks data poisoning can achieve or approximate.Recent work suggests data poisoning may be weaker, especially when participation is limited.
  • 5.2 Non-Malicious Failures: Non-malicious federated failure modes include client reporting failures, data pipeline failures, and noisy model updates.These failures require techniques specialized to cross-device and cross-silo federated learning because the setting has unique features.
  • 5.1 Adversarial Attacks: Federated learning introduces new adversarial capabilities and attack vectors through third-party training participants.The paper organizes important adversary-capability axes in Table 11, while noting that the list is not exhaustive.
  • 5.1 Adversarial Attacks: Model update poisoning is a federated-specific attack, while federated learning remains susceptible to data poisoning and inference-time evasion attacks.A single-shot attack may introduce a backdoor, and compromising 10% of participating devices can succeed despite server anomaly detectors.
  • 5.3 Privacy and Robustness: Federated learning creates tension between robustness and privacy, while limited raw-data access makes non-malicious failures especially difficult to address.Differential privacy can defend against data poisoning, but injected noise can hurt learned-model performance.

6 Ensuring Fairness and Addressing Sources of Bias

Federated learning creates unique fairness opportunities through more diverse, decentralized data, while introducing bias through client sampling, data limitations, and privacy-related tradeoffs. Open problems include fairness without sensitive attributes, adapting centralized methods, and jointly achieving fairness, privacy, and robustness.

  • Sources of Bias: Bias in FL can arise from training-data underrepresentation and federation-specific sampling of clients, devices, locations, activity patterns, connection quality, and local dataset size.Sampling can over-represent night-shift users, newer devices, or users with less data, potentially correlating model outputs with work schedules, socioeconomic status, or product use.
  • Fairness Without Sensitive Attributes: Many FL deployments lack sensitive-attribute data, complicating fairness measurement and motivating fairness definitions based on equal access to effective models.Attribute-independent methods for equitable model performance remain an open research opportunity, especially as FL reaches real populations without known sensitive identities.
  • Opportunities: Federated learning can improve fairness by enabling privacy-preserving use of larger, more diverse, multi-institutional, and feature-partitioned datasets.More representative stakeholders and data may improve both downstream model quality and fairness.
  • Open Problems: It remains open whether centralized fairness methods such as constrained optimization, post-shifting, and distributionally-robust optimization transfer effectively to FL.Determining the additional assumptions required for these methods in federated training is an unresolved question.
  • Privacy, Fairness, and Robustness: FL’s privacy-sensitive deployments can intensify tensions among privacy, fairness, and robustness, requiring integrated approaches rather than isolated treatments.Further research must evaluate fairness impacts when sensitive attributes are unavailable, including how to identify poorly served subgroups and quantify differential privacy’s price.

7 Addressing System Challenges

Federated learning systems face distinct cross-device challenges because heterogeneous, intermittently available devices are difficult to deploy, monitor, debug, and represent efficiently. These constraints can induce systematic participation bias, whose realistic quantification and mitigation remain open problems.

  • Deployment, Monitoring, and Debugging: Heterogeneous end-user devices create vast edge-case spaces that automated testing cannot fully cover, while limited and delayed telemetry makes monitoring and debugging difficult.Federated learning further restricts investigation because raw device data are inaccessible and individual contributions are anonymous, ephemeral, and aggregate-only.
  • Cross-Device System Constraints: Device availability varies over time and across devices, and federated computations must tolerate interruptions, operating-system quotas, connectivity changes, and device-state constraints.Mobile-phone participation may require idleness, charging or sufficient battery, unmetered connectivity, and no concurrent federated-learning task.
  • Cross-Device System Constraints: Device capabilities are typically lower and more variable than data-center nodes, with network, compute, memory, and data differences producing unequal execution profiles.Availability profiles for mobile phones are often periodic with a one-day period and differ across devices in phase, shape, and amplitude.
  • System-Induced Bias: System-induced bias can under-represent devices active at fleet-wide availability peaks or troughs and favor devices with better networks, faster processors, lower CPU load, or less data to process.Models may consequently over-represent demographics with high-quality internet or high-end devices, while ranking models may under-represent high-engagement users whose larger data volumes lengthen training.
  • System-Induced Bias: A systematic study that qualifies and quantifies bias in realistic settings remains open, and expected device contribution rate is proposed as a proxy for measuring non-uniform participation.In an unbiased system, the expected contribution rate would be identical for every device; deviations can help identify causes and guide mitigation.
  • Code Representation: Representing federated computations as original high-level programs may be infeasible on end-user devices because of binary-size, memory, performance, or security constraints.A Python TensorFlow program would require a Python interpreter with a TensorFlow backend.

8 Concluding Remarks

Federated learning brings model training to decentralized client devices, enabling collaborative learning while keeping training data on device. This paper surveys recent advances and open problems, emphasizing practical efficiency requirements and privacy’s dependence on threat models and assumptions.

  • Core concept: Federated learning lets client devices collaboratively train a shared prediction model while keeping all training data on device.This decouples machine learning from storing data in the cloud and extends beyond using local models only for prediction.
  • Field growth: The field has experienced explosive growth across industry and academia, including production deployments, startups, and interdisciplinary research.These developments target privacy and data collection challenges across various industries.
  • Paper scope: The paper surveys recent advances and extensive open problems, highlighting efficiency requirements imposed by federated learning’s system constraints.Many of these requirements are less challenging in other settings.
  • Open problems and limitations: The paper argues that data privacy is not binary and presents threat models for varied assumptions, while acknowledging that its open-problem coverage is not comprehensive.The authors’ selection reflects their interests and backgrounds and excludes non-learning problems such as decentralized descriptive statistics and histogram computation.

A Software and Datasets for Federated Learning

Federated learning software spans research simulation platforms and production-oriented frameworks, while datasets must represent decentralized, unbalanced, and non-IID data across clients or silos. The section highlights both existing benchmarks and the need for more realistic, feature-partitioned datasets.

  • Software for simulation: FL simulation software must process partitioned datasets across variable simulated devices and measure communication, client arrivals, and client dropouts.These requirements differ from datacenter machine learning research.
  • Software for simulation: TensorFlow Federated targets research with large-scale simulation and flexible sampling orchestration, while FedML supports on-device, distributed, and single-machine platforms plus diverse algorithms, models, and datasets.FedML includes decentralized, vertical, and split learning support.
  • Production-oriented software: Production-oriented platforms address authentication, communication protocols, encryption, and deployment to physical devices or silos beyond simulation capabilities.Examples include secure computing, cross-silo privacy protection, enterprise fabrics, mobile-device experimentation, and joint institutional modeling.
  • Datasets: Common federated benchmarks include EMNIST’s 3,400 unbalanced writer-based clients, Stackoverflow12’s more than 342,477 users and 135,818,730 examples, and Shakespeare’s 715 character clients.EMNIST is non-IID through writing style, Stackoverflow12 preserves timestamps for incoming-data simulation, and Shakespeare uses contiguous lines as client examples.
  • The need for more datasets: Existing datasets remain limited in realism or scale, motivating new datasets and partitions that preserve unbalanced, non-IID, temporal, geolocation, and feature-partitioned structure.Stackoverflow12 is described as the most realistic cross-device example, while small datasets may not reflect challenging scenarios; feature partitioning can split medical-record features across institutes.
Loading 1912.04977v3…