Privacy Weather: Cloudy with Complications
While in San Francisco for the ABA annual meeting earlier this month, I had lunch with John Tomaszewski, the General Counsel of TRUSTe. At the end of a very good conversation on privacy, security and identity, I couldn’t help but think that Cloud computing, as it actually is supposed to work, raises a lot of questions as to how custodians of personal information will be able to meet their legal obligations under existing data protection/privacy laws.
As my last blog post indicated, NIST defines Cloud computing to have five characteristics: On-demand self-service; Broad network access; Resource pooling; Rapid elasticity and Measured Service. The one that troubles me the most is “resource pooling”, which, for ease of reference, involves “different physical and virtual resources dynamically assigned and reassigned according to consumer demand”.
Keep in mind the “Cloud computing pyramid” has software at the top, platform immediately below, followed by software infrastructure and then, below that, hardware infrastructure. Each of these layers would be provided as a service to the custodian. A nice description of the layers can be found in this Silicon Whisperer post. In a true Cloud scenario, with resource pooling and rapid elasticity, the Cloud-based IT computing resources could very easily not be under the control of the same entity on a per use basis.
What do I mean by that? Imagine a series of separate but connected cubes with different colours on each side, making a stack. A colour represents an owner of the IT resource being used. Imagine tens, hundreds, thousands of different colours. Now imagine spinning the stack of cubes. When they stop, the odds are very good that the colour of the sides facing the user will all be different. Now consider that each spin is a transaction by a custodian of personal data that represents the use of an application and involves personal information. Each transaction has different service providers assist in the processing of the information. And these service providers can change with every transaction.
How could this be? You now have to keep in mind that Cloud computing, in a true Cloud, means reducing IT to a utility business model. That involves different players providing resources when required. That doesn’t mean one provider simply calling up more internal resources to service the custodian’s business requirements or, perhaps, using one or two key sub-contractors. (That’s not Cloud computing; that’s outsourcing to a managed host – and there is a significant difference between the two). The result is a contractor using sub-contractors as required. As you deal with different applications, through one or more portals, the database, network and actual processing would likely involve different subcontractors. Why would a Cloud service provider have an enormous amount of internal capacity that it may not use? If it needs capacity it would draw it from a sub-contractor on a “pay-per-use” basis. In a true Cloud environment, the same logic that drives custodians to externalize their IT inevitably will drive Cloud providers to do the same.
The privacy implications of this are significant. Since a custodian has “accountability” obligations under data protection laws (in Canada and elsewhere where such laws are based on fair information principles), one usually sees an obligation in master service agreements that have contractors impose privacy and security obligations on sub-contractors. Lawyers will say make sure agreements are in place for all parties involved in the processing. Seems simply a paper exercise but in auditing or enforcing those obligations (whether or not there is a data breach) you now have the potential for a dazzling array of different data elements, sub-contractors, and jurisdictions. How do you really ensure accountability and safeguards in such an environment?
How can any government sensitive to the location of citizen data use a true Cloud-based service provider? How can custodians even use the Cloud if data from Europeans is being processed? Some providers such as Amazon can now limit the processing of data to specific regions but will that be the norm?
Even if you could manage this by contract, how do you explain this to the individuals whose personal information is being processed in any meaningful way? Is putting in a privacy statement “your personal information may be processed outside of your country of residency” enough? If you can’t have an informed consent, can you really say you have consent? In this context, the concepts of “onward transfer” and “consent” seem to invoke the need for a “re-think” of what privacy requirements we really want to impose.
It is very early days for “Cloud computing” and a lot of it today is simply outsourcing to a one or more service providers who have dressed the service offering up in the Cloud “hype” that is out there. One can’t help but wonder if this is the real direction of information technology or just another fad – one Cloud concept or another has been around for since the turn of the century. (Sun coined the phrase “the network is the computer” a decade ago.) So whether the world ever moves to true Cloud computing is certainly open to debate (and custodians may never want to give up total management of IT resources).
I don’t wish to come across as unduly negative about Cloud computing. The question for me is not the technology but whether our laws concerning data protection – even written broadly as principles – are sufficient to address utility-based processing of personal information.
The Office of the Privacy Commissioner of Canada, Jennifer Stoddard, held a public consultation in Calgary in June to raise awareness about privacy/Cloud computing issues and has posted links to written submissions here. It will be interesting to see the results of those consultations but if anything causes us to re-examine what privacy laws should look like in the 21st century, the impetus may very well be the operational implications of Cloud computing.