28 January, 2011

Privacy Icons : Phraud

See! I was supposed to use a word for fraud which starts with P (so, to go well with the other article titles). I did maintain all the constraints - but I cheated blatantly with the word that I used, exploiting the power of human cognition. Cannot similar things be done with privacy icons, to imply something that is not? Hell yeah, the possibility is endless. So what to do when we encounter such cases, or the browser does? We notify the user about the issue, right?

A classical preload-notice is cliché - USERS WON'T READ but press "OK, Proceed..." and even if they understand that there's a privacy-concern about this site, they will not have a clear idea (without reading the warning very carefully) exactly what it was about. Some other notification method may also come to your mind, came to mine one too - but none of them were 0% annoying, except for one.

Elements are painted-red if a fraud is detected with its corresponding parameter.

I said that I wanted the icons to be monochromatic 'as much' possible - but now I'd bow to this exceptional situation (Heh, ain't I histrionic? Psst. it's all pre-planned). Let's suppose, a site says it keeps the user data as long as 3 months but actually practices to keep them longer than that. Here, if we (the browser) make the persistence-arc chromatically different than the others, then voila! The icon remains intact, no annoying popup/notices/texts - but just at the very look at the icon, the user will know where exactly the trouble is (& what's better color than red in this case?). Same procedure can be applied for each and every parameter, and the browser has to do that by matching the HTML attribute-value and the site's privacy-practice list record.

Privacy Icons : Preach

Making an HTML specification wouldn't work until it gets rendered on screen of browsers. All HTML can do is to help them by providing the logical details it needs to depict the icon - and then the browser actually has to draw it on the screen. As each browser has their own font color, size, styles preferences for various tags, here also we can expect some variation in privacy-icon-species - till it retains it's meaning for anyone above IQ-80. Simple enough so far, but that's not the reason I've opened a new section.

Nowadays, we are pretty used to with the browsers taking care of some of the underlying security risks (potentially harmful site, certificate mismatch, redirection loops etc.), this gives me an idea to ask them for another hand for help... yes, I hope they won't get offended.

If a general list of sites which abuse/misuse/cheat the privacy policies, can be maintained, the system can become even more transparent. If a general list is not possible, then each browser can have their own list of sites, from which it can check and warn the user - whether they really comply to the policy they say they do, or they differ. It's not a rigorously tough act to perform if you argue; maintaining a malware site-list is lot more tough in my opinion, for which nearly all modern browsers have implemented notification facility already.

So now that we have come this far, we actually need to consider about the mode of notification - i.e. how to let the user know if there's something fishy about the site they are visiting or putting details into.

Privacy Icons : Plead

Here we are, to cry to momma W3C. Yeah, I know it's kinda too late to make another HTML5 proposition like this - but I'd hate to see a <privacy /> tag in HTML v5. i.e. as a minor update to it. The world(-wide-web) is changing; it's significantly different from the perception of someone's online presence even what it used to be just 3-years before. I will pretend not to be cynic about it, not from any side; rather, it's a big leap forward and an integrated effect of web2.0. And online-privacy is a very large issue and a huge part of it to consider about. True that we can always skip it for later, but isn't it too late already?

All I mean to say is that, if a privacy-tag is implemented to be used by the sites, the entire process of enforcing better privacy practice becomes hell lot easier. I don't say it'll reduce people mal-practicing with user data, but in case they would, it'll be easier to detect those spots (how? Well, when there's a will, there's a way!).

The <privacy leaktype="hexval" persistence="timespan" exposure="scope" /> can also very well be a sub-tag of <footer> tag - or, I'd better leave that decision for the experts to handle. I kept mentioning that there was a plan behind the hex-values of the parameters; they are actually designed to be used as the values/properties of privacy-tag's attributes (if it gets included into the next HTML specification - and the 'next' is version 5).

Privacy Icons : Preparation

Only two of the four shell-leaks we have put, are widely discussed and are supposed to cause pain in our - erm... forehead, namingly the #2(partner/barter) and #4(feds/govt.). But the other two, albeit not too many of us cared about it, but are also equally concerning. It's not necessary to have only one leak though; sites are most likely to (and will) have multiple leaks or all at once (may very well have none, too). The design that we have made up can very well handle (any of) these kind of situations - visually at least. But, is that all? No.

Let again take a look at the numbering-scheme of the leaks - they are all in powers of 2 (2^[0-3]). Thus, no matter how you make combinations taking any of them - the sum of the combination-indexes can be represented as a single hexadecimal digit (ranging from 2^0-1=0x0 i.e. no-leak to 2^4-1=0xF i.e all-leaks). Hence, it's effectively similar to the octal notation of file-system-permissions to determine the type of leak-combinations from that one digit, but in our case the parameters being four, we have to go for hex. It may seem trivial, but it's actually planned to be like this (and the conspiracy behind it is to make it easy to implement digitally - so that the software read/write them efficiently).

Not only the shell, you can now see all other parameters can also be put onto the logic table - only difference being, they are mutually exclusive. So, it's easy enough to code-the-icons the way you want it - if you have the svg/png piclets(wow!) of the icon. Ask me why this was necessary... cause I've got to tell you that next.

Privacy Icons : Provision

The privacy as it may sound, might not have same context for every purpose or scenario, not even for the same person. Your social networking self and collaborative self wouldn't have similar concerns about the privacy. Even on social networking platforms, you do treat your Facebook and Twitter differently, don't you? (Don't just say 'no' to prove me wrong - we are under a situation here!)

  1. Moderated P: This represents that you will be asked to put your information, some of which are mandatory but all of which is scope-adjustable. You can set your 'circle-of-trust' to whom you want to expose which of your data (just me, friends, friends-of-friends, everyone or some other representation). Your choice to hide the details you don't want to reveal, will be respected.
  2. The Open P: In this case, you don't have any permission to change the scope of the information that you upload. Your data 'may be' accessible throughout the web publicly; 'may not be' as well, depending upon the companies' policy and structure - but the security of your information is completely on their hand. Even if the company wouldn't sell-out your data, it has a fair chance to passively help the spammers/stalkers. So, the icon tells you here, if you want something to be secret, don't tell it in these situations.

Some web-services/applications may need some of your details, some require very handful things and for some you have to literally digitize from entire of your music choice to appetite preference. Let's think of a discussion forum which 'need' only your email ID to identify/contact you, but 'offers' to fill in a profile "if you'd like to", which will be visible by all other members/visitors/web alike, then it's significantly different from some other web-service, where it asks your details to fill in and gives you the choice to maneuver it's exposure.

So, this is about most of it for the privacy-icon designing. Now we have to consider the abuses & exceptions.

Privacy Icons : Persistence

Persistence in the sense, how long your data stays in the website's server. The implementation of it should be simple enough to understand from the visual-feedbacks (and having a chance to not have to babble a lot, I'd just present you with the icons).

Momentary 7 days to 1 month 1 to 3 months

3 months to 1 year Infinite Persistence

Although I'm not happy with the Momentary Persistence logo, I know somebody will come up with a better way to represent it. Next step is to visualize how can we handle the private-data.

Privacy Icons : Perversion

Call it the first step into our privacy icon design - we will essentially draw a circle (and something more). Let's make the outer shell is the wall of our privacy - makes sense, eh? So, where there are walls, there are leaks. And these leaks on the walls can technically be of 4 types; let's tag 'em-
  1. Frontal Leak: Nearly each and every company tracks and uses their user data for business strategy, customer services and logistic purposes. A company with many daughter projects may have super-sets of users in many of those projects, and so may use the same data for all the daughter projects, which that member has joined (or availed services). Say for example you, having a Google ID, have joined Gmail, Buzz, YouTube, Calendar, etc. and whenever you join new Google services with that ID, at the moment of first-use/basic-setup you can see your that product-related data (Name, DoB, events etc.) has been fetched from your account already. You didn't give those details to this service (explicitly), but having you as existing member, the system has done that for you. There's not much of choice which you can opt here; and this being the same organization, doesn't hurt much anyway - but none the less, the user has the right to know the information inter-sharing and thus the front (& right) side of the Icon is leaked.

  2. Privacy is Protected Frontal (Internal) Leak Backyard (External) Leak
  3. Backyard Leak: This is the fishy one, and also the most discussed one too. You want to know whether this service will give out (sell, mainly) your data to other companies (partner sites, ad-agencies) behind your knowledge or not - simple. I'm not going into examples, it's not easy to name one. If the company acts in under-the-table business, then the privacy icon has to reflect that. This leak is on the hind (left) side.

  4. Federal Leak: i.e. in simple words, whenever there's a federal/govt. pressure to hand over your user data, and you comply without going into any trouble (without verifying whether formal procedures have been performed to have the data or not,) handing over the data, then the icon will have a top-leak. For the cases where procedural approaches made by Govt. or any other upper-hand, there's nothing too much to do about it for the website, and mostly any site will have to give in. Hence we won't consider it as a leak.

  5. Security Leak: This is the controversial one (even I'm not sure, whether it's 'to-be-or-not-to-be' implemented or used ever) but, if there's a chance or history of security issues, those sites has to wear this monkey-cap. As being the spookiest and the leakiest-leak, it's at the bottom! Hope it makes sense.

  6. Federal Leak Security Leak All Leaks
Now now, as I've described those leaks, and how to visualize 'em, there's one single prick may poke in your mind if you've spotted - why the numbering is 01-02-04-08 and not 1-2-3-4? Well, I have an alibi for that; I'm smart, ain't?

Privacy Icons : Preamble

Let's take a look at Aza's privacy icons' alpha release first. Aza sure made it clear about the curves & corners to consider about; but for the icons, I don't really think he gave his best effort. (Although, I sense conspiracy that he intentionally underperformed so that people can catch up to it, find bugs & get involved;)

I find the following problems:
  1. Not usable under 64x64 resolution.
  2. Too many graphical sprites to get used to.
  3. Using color-outline with black-content... meh!
  4. For being more cognition friendly, it uses redundant representation of similar notions (graphic bar && red-color, to negate).
  5. Not quite simple.
  6. Too many icons to understand one site's privacy policy.
  7. You can't just look at 'em an understand - you have to be through (But I have ADHD AADD!).
  8. On the websites, how exactly are we going to put all these icons, eh!?!

So, let's simplify things a bit. I'd prefer a single-icon to start up with - in case I fail, we already have plan B. There's a reason behind the single-icon approach: multi-icon representation produces significantly more cognitive load for the user to parse the icons' information one by one & then decide - but all they actually want, is- just to look at it and feel safe/unsafe.

While making the icon, I've particularly kept some factors in mind. Although I don't propose them to be guidelines; it's just, we will have them as specifications for this discussion. Those are-
  1. It has to be monochrome (or monochrome-possible).
  2. It has to be simple, yet informative enough - although we are aiming for very subtle-period working memory, still will try not to make an information-overload to the viewer.
  3. It has to be page design-neutral, to be used by all types of organizations alike, and also to restrict modification (which can also be misused to cheat the system).
  4. It has to be low-resolution feasible with as less modification as possible (none, the better).
  5. The Icon is better to resemble with the existing copyright (& creative-commons) icon, to be seamlessly integrated in the web, without seeming to be an alien logo- accidentally dropped out of nowhere.
  6. Unlike the creative-commons icons having many modes, the privacy icon has many parameters - they are different.
  7. Each of the elements in the icon can be used to indicate the different parameters, but it has to synchronize well with the iconic implementation to mean it.
  8. By now, I'll stop sounding like any of those ultra-formal privacy policy texts & will try my best so that none of you require a dictionary.
The 7th point is important, because that's how I'm going top-down to create the icon, please join me.