It’s an agreement between you and your users as to how your organisation uses their data. Based on what permissions your users give you, you can easily control the flow of their data through your products or services.
The basic building blocks of a Micropolicy are three questions about any feature of your product that collects data. Those questions are:
A Micropolicy — the what, where, and why
So Micropolicies allow you to store this information, and easily retrieve it. This is extremely useful. Why?
You use Intercom to talk to your customers. If someone opens up a chat with you, their email address will be associated with that conversation. This is so that you, as an organisation, can automatically see which user you’re talking to. It also means that they, the customer, will get a transcript emailed to them when the chat is over.
This is all fine, but you need to get permission to share their email with Intercom. What if you just used a check box with an if statement behind it? That would only work up to a point, because it’s not a simple yes or no question. There are actually all of these questions too:
As you look at the above questions, it starts to become apparent that the best way to look at this is not “who’s give us permission to do xyz” but more like, “currently, we have permission to use this data for this purpose”.
So, for the Intercom example above, the Micropolicy would be made up of this information:
If they grant permission for their email to be shared with Intercom, your code will make it so. If they deny permission, they can still chat to you on Intercom — but their email address won’t be shared. And if they haven’t yet given/denied permission, you will know to ask.
Micropolicies also leave an audit trail: if a user revokes consent, that will be recorded. Equally, if you make a change, that will be recorded too, and most importantly:
You are also able to query this permission: you know that if a user is okay with their email address being shared with Intercom, it’s okay for you to capture that information both via your website and desktop app (because the purpose is the same).
Metomic essentially provides a ‘privacy layer’ between you and your database.
Without Micropolicies, this information was previously irretrievable, because it was not recorded anywhere. But now, it’s machine-readable, which makes your life much easier 🏄♀️
At the moment, the dominant manifestation of Micropolicies is within the Cookie Widget — so this is only cookies and script blocking. They surface as a list of website features which collect data, that your users can easily turn on or off.
This is what you see if you click ‘No, customize’ on our Cookie Widget
This article just scrapes the surface of what you can do with Micropolicies. Later they will also be used for things like modular privacy policies, and dynamic feature-walling. Stay tuned for more on this 👩💻. In the meantime, you can join our community slack channel 💬 to discuss all things relating to data privacy.
We now also have a Kampsite for product feature requests 📣