A recent post by Mary Hodder on the VRM list discussed the news of the Swedish Data Inspection Board banning Google cloud services such as Docs, calendar and email over privacy concerns. Mary writes:
It’s going to be a PR struggle to convince regular people that “personal” or personally directed services (VRM) style are different than general cloud services.. because I bet that Google would argue that Google apps are personally directed.. nothing happens unless the individual uses the services, from Google’s perspective. But the individual’s data isn’t controlled by the individual, VRM style.
So I think this will be the pivot point.. convincing the public, as well as the companies and governments, that it’s not “personal” unless the individual controls their own data, not just the use of the product.
What is interesting to me about the privacy issues unfolding of late, especially in the wake of the PRISM revelations, is that VRM-y cloud apps already exist that address the issues raised by the Swedes and for privacy in general. If Cole Sear were here he’d tell you the same thing: “I see VRM apps. Floating around the cloud like regular apps. They’re VRM except, they don’t see each other. And they don’t say they are VRM. They don’t even know they’re VRM.”
An interesting counterpoint to Google cloud apps is the example of LastPass. (And probably DashLane, but they were too far behind LastPass in implementation when I first met them at PDNYC for me to switch in mid-stream. I should probably check back in with them.) LastPass provides a true cloud service for password management. All your passwords are stored in an encrypted vault on your device and synced to the cloud. Because it’s in the cloud, the password database syncs in turn to all your devices. But because only you hold the key, it is completely opaque to LastPass, immune from government snooping, etc. Because they opened their software for inspection by security pros, we have reason to believe that it actually is coded as promised, which is to say it’s transparent to users in all the ways that count.
Despite their having no access to the keys or data, LastPass managed to build a sharing system into the product. A special share key is created and distributed to the intended recipient using a strong crypto key exchange algorithm. The exchange provides complete protection from Man In The Middle attacks, which is good because LastPass is in the middle by design – they just cannot break the key exchange even though it occurs fully in their view. Using this feature, it’s possible to securely share a password and login details with another person without sending it in email, dictating 12 random characters over the phone, dispatching FedEx, or raising pigeons. The beauty is that LastPass does all the complex key management under the covers. All the user sees is
Click for full-size image
But the kicker here is that they only market it for passwords. The service also has the concept of “secure notes” which is basically a database free-form text entry. If you took the time to UUENCODE a binary file and paste the result into the secure note, you could actually use it today to share files securely. It’s a short hop from that to providing first-class binary file attachment sharing support. Start with that, give it an API and the ability to point it to the cloud storage host of your choice and you now have a completely user-controlled, elastic, crypto-secured platform for VRM-y sharing and personal cloud. For example, use the API I just proposed to make LastPass secure notes appear to the user as just another folder in the file system. Given the sharing capabilities, you now have a VRM-y Google Docs. Toss some photos in there you now have a VRM-y Instagram or Flickr.
An architecture like that addresses the Swiss concerns. Consider an apparently local folder backed by my hypothetical enhanced LastPass app as a replacement for Google Docs and in the context of the concerns raised in the linked article:
… uncertainty over how data may be mined or processed by Google …
The data in my version is opaque to Google.
… lack of knowledge about which subcontractors may be involved in the processing.
The data is opaque to the contractors.
…no certainty about if or when data would be deleted after expiration of the contract.
Not only don’t you care with the LastPass-style app (the encrypted data is useless to anyone but you) but you’d actually like them to hold onto the data in case you change your mind.
I’m sure one immediate reaction to this suggestion is that the vendors will never go for this if all the data is opaque to them. Well, as the supplier of the app they become one of the eligible recipients for sharing. Such a system could compile stats or other metadata about your usage, put these into a folder, and then you share that folder with the vendor. Since you see the same files they do, you know EXACTLY what’s being shared and with who. In return for their investment in the platform, the vendor might offer several levels of sharing for the user to choose from where progressively greater transparency resulted in progressively reduced hosting rates. This turns the Freemium on its head. Currently the user starts with Free and can upgrade to the Pro account to get fewer ads, more functionality and more privacy. The VRM version assumes by default a base subscription rate and full functionality, and you can work your way down to free by opting in to progressively greater levels of sharing.
There may also be a question of how to get the data to the vendor in a way that anonymizes you. Solve that and provide the ability for users to view the data being shared, people may be willing to share more. There is on GitHub a system called DeadDrop, designed by Aaron Swartz by the way, which is like a truly anonymous version of PasteBin. The New Yorker just set one up under the name StrongBox to receive anonymous documents but it could be as easily used in a commercial setting. Back to my enhanced LastPass, encrypt the anonymized data with the vendor’s public key, but don’t sign it with your own key, then send it to the DeadDrop where the vendor finds it. They get their data, you control how much and whether to be anonymous. And, again, remember that most of what I’m talking about exists today and is already successful in the market. All I’m proposing is repurposing the existing technology, tweaking it a bit and then applying it to personal data.
So the big problem with privacy, VRM tools and the cloud isn’t that the technology needs to be invented, but rather that the current IT culture assumes the vendor has rights rather than privileges to harvest and exploit your data and that you must opt out rather than opt in. If you start with an assumed right to the data, then of course the apps that get built ignore existing privacy enhancing technology.
A related problem is that, at least until very recently, people have believed that passwords needed more security than the things they protect, and so an architecture such as that used by LastPass has been viewed as appropriate for passwords but overkill for things like docs and photos. That we collectively believe password security is more important than security of things protected by those same passwords is self-evidently true. The basis for such a belief is not. Obviously, if you lose the password you lose the data, hence passwords need to be protected strongly. But wait – if you lose the data but the password is intact, what good was that password security? So why do we readily accept something like a cryptographically strong, expert-tested product like LastPass as routinely necessary but simultaneously believe using the same tech to protect vital documents, family photos or contact lists is complicated, scary and way to complex?
The essence of VRM is embodied in the notion that the things protected by the passwords deserve the same level of protection as the passwords themselves, and that this is not overkill but rather the default baseline stance that we should expect from our applications.
That is of course not all there is to VRM, but simply starting with current password technology and applying it to an individual’s personal data gets us 80% or more to the VRM architecture that looks and feels like tools we already use (such as folders) but with greatly enhanced privacy and user control of their own data.
One final note – when I say “current password technology” I mean things which are actually fit for purpose. Some products claiming to provide security… well, see for yourself.
Leave a Reply