book

The Architecture of Privacy

by Courtney Bowman, Ari Gesher, John K Grant, Daniel Slate, Elissa Lerner

September 2015

Intermediate to advanced

224 pages

5h 55m

English

O'Reilly Media, Inc.

Read now

Unlock full access

Who Should Read This BookWhy We Wrote This BookA Word on Privacy and Technology TodayNavigating This BookSafari® Books OnlineHow to Contact UsAcknowledgmentsCourtney BowmanAri GesherJohn K. GrantDaniel Slate
How to Think About PrivacyDefining PrivacyA Short History of U.S. Informational PrivacyToday“East Coast” Code and “West Coast” CodeWhy Privacy Is ImportantBefore You Get Started
Data Collection: Understanding Privacy’s First FrontierPolicy ConsiderationsImplementation ConsiderationsConclusion
Google Street View WiFi: Inadvertent Over-Collection of DataiPhone Location DatabaseConclusion
InfoSec Best Practices for Privacy-Protected SystemsFurther ReadingConclusion
OverviewSeparating Roles, Separating PowersMaking Roles SecureThe End UserThe Application AdministratorThe System AdministratorThe Hardware or Cloud AdministratorThe Network AdministratorConclusion
OverviewAccess-Control ModelsTypes of AccessBasic AccessDiscovery AccessManaging AccessRole-Based AccessTime-Based Access, or Data LeasingFunctional AccessStrengths and Weaknesses of Access ControlStrengthsWeaknessesAccess Controls and the Fair Information Practice Principles (FIPPs)When to Use Access ControlsConclusion

OverviewThe Case for Data RevelationRequirements of Data RevelationSelective RevelationPurpose-Driven RevelationScope-Driven RevelationHybrid Revelation and Practical ScopingDesigning for Data RevelationStrengths and Weaknesses of Data RevelationStrengthsWeaknessesData Revelation and the Fair Information Practice Principles (FIPPs)When to Use Data RevelationConclusion
Overview“Always-On” FederationAsynchronous FederationAsking Out and Being AskedStrengths and Weaknesses of Federated SystemsStrengthsWeaknessesFederated Systems and the Fair Information Practice Principles (FIPPs)When to Use Federated ArchitectureComplex Regulatory RegimesLack of TrustPR ImperativesConclusion
OverviewWhy Are Audit Records Important?But Auditing Is Easy, Right?What Are the Challenges to Effective Auditing and How Do I Meet Them?PerspectiveContextFormat and ReadabilityScaleRetrievabilitySecurityAccess ControlRetentionAudit Logging and the Fair Information Practice Principles (FIPPs)Advanced Auditing ConsiderationsReactive Versus Proactive AuditingEmergency Stop for Audit-Log FailuresAudit the AuditorsConclusion
OverviewWhat Is Data Retention?Why Is Data Retention Important?How to Set Retention and Purge PoliciesSo You Want to Purge Data. Now What?Nondeletion Purging (or Not-Quite-Gone)Deletion Purging (or Gradations of Gone)Practical Steps of Data RetentionData Retention, Purging, and the FIPPsDesigning DeletesConclusion
Basic FrameworkUse Case #1: Social Media AnalysisUse Case #2: Secure MessagingUse Case #3: Automated License Plate Readers (ALPR)Conclusion
The Role of the Privacy EngineerPrivacy Engineers: How to Find OneAvoiding Privacy Tunnel VisionConclusion
The “Death” of PrivacyLegal ReformGreater Transparency and ControlPrivacy in Plain SightThe Destiny of DataAnonymization Under SiegeExpect the Unexpected

Content preview from The Architecture of Privacy

Part IV. Putting It All Together

The building blocks of privacy are in your hands. Now it’s time for you to figure out how to put them together. In Chapter 11, we walk through some hypothetical technologies and discuss how we might fashion a privacy-protective architecture using the capabilities described in this book. Meanwhile, if you’re convinced of the importance of engineering privacy into your technology and want to make sure it develops as a core part of your organization, we offer a quick outline of how to find (or cultivate) your own Privacy Engineer in Chapter 12. Finally, in Chapter 13, we look to the future and just a few of the many privacy-related questions that the privacy-minded engineer might be called upon to answer.