With client applications, we can verify what user account is being used, but we can’t verify which application they’re using. Given the importance of maintaining the privacy of health data, that makes us concerned.
There are, of course, cryptographic protocols that could be used to verify a client application. And the kinds of folks who read this blog are among the most likely to be able to make reliable use of those protocols. But I can appreciate the dilemma. The archetypal user of HealthVault is a mom who functions as a family’s health manager. How are you going to walk her through the protocols necessary to assure that a client application she downloads from the Net is properly certified for use with HealthVault? A screwup isn’t just her problem, of course. It’s a big time problem for HealthVault. Eric concludes:
In the longer term, it may be possible to construct an application verification that is sufficiently trustworthy to grant access similar to what web applications get.
Does anyone think this problem is more tractable in the near term? If so, how?
There is, meanwhile, this interesting twist:
In the short term, we are considering allowing partners to build client applications that only have write privs – applications could use them to add data to HealthVault, but wouldn’t be able to read any data (an interesting case where write access is less privileged than read access). This would allow developers to write applications such as data importers.
A curious inversion indeed. HealthVault is going to create all kinds of fascinating thought experiments.