Purpose Limitation with Policy Zones: What We Tried That Didn't Work
summary
Meta describes why three early Policy Zones designs fail at scale: dynamic propagation breaks on cycles and asynchronous jobs so policy changes ripple unpredictably and failures surface far from the originating code; a single monolithic policy forces cross-team alignment and blocks new requirements; a centralized server-side chokepoint lacks schema/context for consent and rich debugging. Fixes that actually work are per-hop static policies to localize failures, moving checks to clients to preserve context, and splitting policy into independent swim lanes so teams can progress without global consensus.
AI-written summary · about
chapters (10)
- 0:00Introduction
- 1:53Policy zones design
- 2:56Dynamic policy propagation
- 4:39Static policies for maintainability
- 5:43Server-side privacy limits
- 7:08Client-side enforcement
- 7:50Monolithic policy problems
- 8:51Policy swim lanes
- 9:56Lessons learned
- 10:36Q&A
related talks
51mPermissions: Centralized or Decentralized? Both!
22mDynamic Policy Enforcement for Privacy Techniques in Microservice Architectures
14mApproaches and Challenges to Purpose Limitation across Diverse Data Uses
28mPolicy as [versioned] Code - you're doing it wrong
32mAuthz as a Dev Workflow: Architecting Better Cloud Native Apps
27mLove, Hate, and Policy Languages
36mUnintended consequences of well-meaning changes
50mKnow Your Limits — On Discovering Boundaries ...