Introduction
In January, I laid out information in a presentation & blog post information for a discussion about applying Mozilla’s privacy principles in practice to engineering. Several fellow engineers wanted to see it applied in a concrete example, complaining that the material presented was too abstract to be actionable. This is a fictional series of conversations around the concrete development of a fictional mobile app feature. Designing and building software is a process of evolving and refining ideas, and this example is designed for engineers to understand actionable privacy and data safety concerns can and should be a part of the development process.
Disclaimer
The example is fictional. Any resemblance to any real or imagined feature, product, service, or person is purely accidental. Some technical statements to flesh out the fictional dialogues. They are assumed to only apply to this fictional feature of a fictional mobile application. The architecture might not be production-quality. Don’t get too hung up on it, it’s a fictional teaching example.
Thank You!
Before I begin, a big thank you to Stacy Martin, Alina Hua, Dietrich Ayala, Matt Brubeck, Mark Finkle, Joe Stevenson, and Sheeri Cabral for their input on this series of posts.
The Cast of Characters
so fictional they don’t even get real names
- Engineer
- Engineering Manager
- Service Operations Engineer
- Database Administrator (DBA)
- Project Manager
- Product Manager
- Privacy Officer, Legal’s Privacy Auditor, Privacy & Security there are many names & different positions here
- UX Designer
Fictional Problem Setup
Imagine that the EU provides a free service to all residents that will translate English text to one of the EU’s supported languages. The service requires the target language and the device Id. It is however, rather slow.
For the purposes of this fictional example, the device id is a hard coded number on each computer, tablet, or phone. It is globally unique and unchangeable, and so highly identifiable.
A mobile application team wants to use this service to offer translation in page (a much desired feature non-English speakers) to EU residents using their mobile app. For non-english readers, the ability to read the app’s content in their own language is a highly desired feature.
After some prototyping & investigation, they determine that the very slow speed of the translation service adversely affects usability. They’d still like to use it, so they decide to evolve the feature. They’d also like to translate open content while the device is offline so the translated content comes up quicker when the user reopens the app.
Every New Feature Starts Somewhere
Engineer sees announcement in tech press about the EU’s new service and its noble goal of overcoming language barriers on the web for its citizens. She sends an email to her team’s public mailing list “wouldn’t it be cool apply this to our content for users instead of them having to copy/paste blocks of text into an edit box? We have access to those values on the phone already”
Engineering Team, Engineering Manager & Product Manager on the thread are enthusiastic about the idea. Engineering Manager assigns Engineer to make it happen.
She schedules the initial meeting to figure out what the heck that actually means and nail down a specification.