Today's piece of privacy engineering is about structuring access control lists so that they can be actually used and comprehended by humans. 🧵
Quick recap: every time a user takes an action, they need to know who (what identity are they using), what (what action are they taking), and where (where does it show up and for whom).
iapp.org/news/a/interfa…
iapp.org/news/a/interfa…
Well, once someone's taken an action, if it's visible on an ongoing basis (like Alice shared a document with Bob), then Alice needs to be able to understand and control that.
The rule of thumb for this is: who, why, and how to make it stop.
The rule of thumb for this is: who, why, and how to make it stop.
WHO: Who can see my stuff? What can they do with it? For example: Alice can see that Bob can view and comment on her document, but not delete it.
Pretty intuitive.
Pretty intuitive.
WHY: Why do those people have access?
I cannot explain just how many times people have reported a privacy incident and they had literally forgotten that they'd shared data. It's even more harder when more than one person can share. Explaining "why" in an interface avoids panic.
I cannot explain just how many times people have reported a privacy incident and they had literally forgotten that they'd shared data. It's even more harder when more than one person can share. Explaining "why" in an interface avoids panic.
HOW TO MAKE IT STOP: and it should be easy to stop. All the way. No copies somewhere else, the stopping should be fast.
Sometimes when people see who has access, they may be unhappy about it. Don't make them panic. Let them stop it quickly.
Sometimes when people see who has access, they may be unhappy about it. Don't make them panic. Let them stop it quickly.
