4 ms·
Somewhat related to the original post, our research team at Carnegie Mellon University has been investigating how well developers can fill out these kinds of pr
by jasonhong 4y ago
Somewhat related to the original post, our research team at Carnegie Mellon University has been investigating how well developers can fill out these kinds of privacy nutrition labels.
This paper looks at iOS developers. We found that there was a lot of misconceptions and misunderstandings that led to under-reporting as well as over-reporting of behaviors. For example, on iOS, "tracking" is defined only in the context of advertising. A lot of people also misunderstood what "Data Linked to Users" means
https://dl.acm.org/doi/fullHtml/10.1145/3491102.3502012 https://dl.acm.org/doi/fullHtml/10.1145/3491102.3502012
Our research team has also been crawling these labels on both Apple App Store and Google Play to understand changes in labels over time. One early result is that these nutrition labels are not updated very often.
https://dl.acm.org/doi/fullHtml/10.1145/3491101.3519739 https://dl.acm.org/doi/fullHtml/10.1145/3491101.3519739
Lastly, we've developed an IDE plugin for JetBrains to help developers fill out labels more accurately (and hopefully more easily too) for Google Play. The key idea is to have developers add privacy annotations (in the form of Java annotations) directly into their code. The plugin uses a bunch of heuristics to flag where you might need an annotation, and helps you fill out those annotations. These annotations are then used to generate a CSV file that can be uploaded to Google Play.
https://matcha-ide.github.io/ https://matcha-ide.github.io/
I also have a talk called Helping Developers with Privacy. It summarizes the last decade of our team's research on this topic. (Note that Slideshare has become a bit spammy, inserting ads in between slides, sorry about that)
https://www.slideshare.net/jas0nh0ng/helping-developers-with-privacy-253988827 https://www.slideshare.net/jas0nh0ng/helping-developers-with...
Stepping back, our team has been looking at two big ideas for privacy. One is these privacy annotations. I think annotations has the potential to be transformative for the privacy ecosystem. They can help developers, they can be assisted with IDE tools, they can be embedded into compiled code, they can be used to help auto-generate privacy user interfaces, and can also be used as a major hint to check the behavior of the apps (by app stores, by auditors, by journalists, and by researchers).
The second is that every app should have a simple manifest that whitelists an app's privacy-related behaviors. The manifest describes what data will be used and a chain of transformations, similar to Unix pipes. In the context of smart homes, an example might be: get access to microphone -> transform to loudness -> send to sleep.com. While we don't know exactly what sleep.com will do with the data, we can have more assurance that it's not sending raw microphone data. Here's a paper at Oakland Security that describes our ideas. An interesting part of our initial analysis is that the vast majority of apps don't need raw data (raw microphone data, GPS data, logs, etc). Rather, they need a processed and more granular form of it (e.g. loudness, what city you are in, etc).
http://haojianj.in/resource/pdf/peekaboo-preprint.pdf http://haojianj.in/resource/pdf/peekaboo-preprint.pdf
Happy to chat more about these topics, we've been working on privacy for quite a while and have had some successes with industry and with the US Federal Trade Commission.