Privacy policies are long legalese documents that obfuscate meaning. Nobody reads them because they are indecipherable and obtuse. Yet, these are the documents that tell you what’s going on with your data — how, when, and by whom your information will used. To put it another way, the privacy policy lets you know if some company can make money from information (like selling you email to a spammer).
Creative Commons did an amazing thing for copyright law. It made it understandable.
Creative commons reduced the complexity of letting others use your work with a set of combinable, modular icons.
In order for privacy policies to have meaning for actual people, we need to follow in Creative Commons footsteps. We need to reduce the complexity of privacy policies to an indicator scannable in seconds. At the same time, we need a visual language for delving deeper into how our data is used—a set of icons may not be enough to paint the rich picture of where you data is going.
Understanding Data Flows
With the rise of web services, your information can end up in unexpected places. To get a better understanding of some of the complexities of data flow, we sketch out how Anti-phishing works in Firefox (with help from Oliver Reichenstein).
Here’s what that looks like as a wall of text, which is the typical privacy policy mode.
The difference in understandability is huge between the text and the schematic. In fact, while we were working on creating this infographic we found a hole in our legalese and updated it accordingly.
The idea here is that by creating a visual schematic language, it is relatively painless way for a company to convert their wall-of-text into something a bit more approachable. And that the more visualization actually shines a light into the dense tangle of words, possibly highlighting flaws or trouble spots that would have otherwise remained hidden.
The simple form
The visual schematic language is a descriptive way of explaining a privacy policy and helps us to understand what’s going on underneath the hood. It doesn’t solve the problem of being able to quickly figure out the guarantees a privacy policy is making on your data.
For that, we want to move from the descriptive to the proscriptive, to a set of legally-bindings icons like Creative Commons.
As an experiment, we tried a schematic form of icons. The feedback that we’ve got so far is that the schematic is over-kill and that a set of icons more similar to Creative Commons’s would be easier to scan and understand. The next step is for us to come up with a set of orthogonal decisions about what compromises the most important aspects of a privacy policy. In the end, we probably shouldn’t have more than 5 icons in the interest of simplicity.
For now here are a set of axis we’ve come up with that need to be whittled down:
Is your information…
Shared with a 3rd Party? Shared internally within the company?
Anonymized/Aggregated before being stored or used?
Stored for more than x number of days?
Encrypted on the server?
Monetized (sold) in some way?
Usable to contact you?
Update: Based on the feedback, we’ve decided the set of attributes people should care about.
Aza Raskin, former head of user experience at Mozilla Labs and creative lead for Firefox, now runs Massive Health, a startup that aims to help people take control of their health. This post originally appeared at his blog.
Categories: Uncategorized
Hello my loved one! I want to say that this article is awesome, great written and
include approximately all vital infos. I’d like to see
extra posts like this .
A good idea.. makes it easy on the reader if they already understand the meaning of the icons or can easily click on the icon to see the exact privacy policy if they don’t fully understand it. I wonder what happens if the policy were to change at some point? Hopefully staff are informed of changes and don’t assume it’s the same because they icon is the same. Get that ironed out and it’s a great idea.
[Hits **Like**]
Rangers 2-1 in regulation. On to NJ. That’ll be gloves-off/
Coda question for “john” –
Apart from misusing “data,” does being a “brilliant kid” give you a decorum pass on using the word “suck” in the title of a blog post on a nationally known health care blog?
I know, I know; like “data,” it’s lost its meaning. It’s become simply a crass (and prime-time TV prevalent) synonym for “stinks,” or, “incompetent,” or “is burdensome/a hassle.” No longer pejoratively means you’re “gay” or “a slut.”
That’s ALL? Gimme a break. Yeah, it was irascible, and no one can deny his Sheet. I rather doubt he’ll be as Indignant as you.
I know I’ve pretty much lost the battle on “data are,” but, nonetheless, I will hold the line, pedantic as it may be. I cut my professional teeth under the now-retired head of Industrial Safety & Health Physics for Oak Ridge National Laboratory and Editor of the Health Physics Journal (John A. Auxier), — which doesn’t make me anything other than someone who knows how to use the word “data” correctly (Dr. Auxier had final cut on several of my technical papers, being my boss at the time).
I then went to work for a time as the Technical Editor in an industrial digital diagnostics firm. The product hardware and software engineers would submit to me their technical paper drafts, uniformly shot through with “data is” stuff that I would promptly change to “data are,” which would then get red-lined back out to “data is” by my Sup, our VP of Marketing (a crew-cut old-school mechanical engineer).
“It just looks wrong”
He also once banned me from using the words “affixed” and “atop” (“…with the remote FFT sensors affixed securely atop the turbine housing…”)
“They sound faggy.”
(not kidding)
“john,” whoever you are, I have PLENTY to say about privacy policies, it’s part of the work I do for my REC and HIE. See my blog. And, specifically type in “Raskin” in the top left search window.
I’m hardly living under any rock. Cute Amazon.dot.com’ish / web 2.0 privacy icons and colorful flow diagrams might be helpful here and there for patients in (this blog being, after all, about health care, not about online commerce), but the complexities of data security and privacy under HIPAA and its subsequent 45 and related 42 CFR regs (and states’ HIPAA-superceding laws and regulatory codes) might not reduce to such rolled-up e-commerce user-friendliness.
I kept waiting for the tie-in to healthcare, “data” word mis-usage aside. Would have been helpful.
Notwithstanding that I’m some pedantic, insubordinate old coot, I too can roll up complex subject matter into a concise graphic.
http://www.bgladd.com/ePHI_MU_security_model.jpg
That’s just the “PHI Security” side. “Privacy” is a whole ‘nuther, way, WAY more complicated kettle of fish (albeit intertwined with the former) when it comes to protected medical data. e.g.,
– Consent (“opt-in” vs “opt-out” and, within that, blanket vs granular, permitted uses, revocability, etc);
– Rights of data “ownership”;
– Rights of “access” (and within that, rights to timely redress of errors, and processes for “accounting of disclosures” via now mandatory “always-on” HIT audit logs);
– CE vs BA responsibilities and liabilities (HIPAA “Covered Entities” vs “Business Associates”);
– Breach Notification requirements;
– Breach remedies, both civil and criminal;
– Data retention requirements ;
– HIPAA and other federal regs vs states. On this subject, state laws and regulations trump the fed stuff, which begs a boatload of questions for both patients and health care delivery organizations. We have two inside Privacy and Security Counsel and an Outside review law firm. Sometimes I have to roll my eyes at the confusions they come up with.
BTW, PHI Security is gonna get even more inscrutably complex should PHI “encryption at rest” survive the current regulatory review period (an increasing concern regarding “mHealth’ apps).
In sum, sorry for my churlishness. I shall slither away now, Game 7, Rangers vs Capitals draws nigh.
That’s all you have, Bobby? This brilliant kid puts it all out on the line and all you got is a pedantic snarky comment. Back under your rock and stay there.
Data “are,” Aza.