Text archives Help


Re: Provisioning respectful devices - Was: [projectvrm] Who owns data generated by 'connected cars' sensor slurpers?. Some Common Sense


Chronological Thread 
  • From: Phil Windley < >
  • To: Dan Blum < >, Adrian Gropper < >
  • Cc: "T.Rob" < >, Graham Hill < >, Doc Searls < >, ProjectVRM list < >
  • Subject: Re: Provisioning respectful devices - Was: [projectvrm] Who owns data generated by 'connected cars' sensor slurpers?. Some Common Sense
  • Date: Mon, 17 Feb 2014 12:43:53 -0700
The primary reason Kynetx has worked to create an open source platform that is self-hostable is for purposes of portability and substitutability in storing and processing personal data. See http://cloudos.me/

There is still much to do. Here’s a few problems:

1.) installation is more complicated that it should be. 
2.) event signal URLs are, still URLs. As a consequence the are hardwired to a particular host
3.) portable channel policies for security purposes

These all have solutions that either resources or working with others on this list would solve. We’re a member of Respect Network, for example, and active in the XDI work (which promises to help with 2, for example). 

I hope to have an image of CloudOS that runs on an Intel Galileo for IIW in May that we can give to people to start playing with. 

In the meantime, all our stuff (SquareTag, Fuse, Guard Tour, etc.) is built on CloudOS, so we eat our own dog food in experimenting with the idea of personal data. 

One thing that might be of interest: 

In developing Guard Tour (see http://wnd.li/95X5Hv for details of the underlying structure), we built a system with no accounts. That’s because users are expected to bring their own personal cloud (or one they’ve created for this purpose). When a manager invites a person to the system (either as a manager or a guard) if they already have a CloudOS-based personal cloud, they can use that or create a new one. In either event GuardTour doesn’t know anything about that. It merely interacts with the guard’s cloud in order to facilitate the guard doing their job. 

This is pretty cool on one hand, but a little confusing for users since it’s not what they’re used to online. It’s exactly what they’re used to in their laptop and personal device experience. 


Respect Network a CSP that provides either a self-hosted personal cloud or at least a local keystore provides an architecture like this. We currently have 4 CSPs on board for an April development milestone and I believe that one of them has such as architecture. Additionally we're in discussion with at least 2 other CSPs that may come on board later with such an architecture. 

Andy Dale, Drummond and I are working on progressively more detailed technical and operational specs. I really like the idea of trying to take a "local keystore" under the wing of the Respect Framework's "portability promise." It occurs to me that it could be quite important to still be able to decrypt your own documents after moving!

At a high level what do you think such a spec should say?

I suspect the capability should both be able (or required) to work with existing platform key stores that are widely deployed (e.g. Windows or Apple), but that we may also need a (optional or required) platform-independent keystore spec...

Dan

As I write


On Mon, Feb 17, 2014 at 2:06 PM, Adrian Gropper < " target="_blank"> > wrote:
Now that we're all in agreement, can we consider the provisioning of devices in a way that provides the option of sovereignty without damaging the user experience for the majority.

It seems to me that some combination of local keystore (Firefox, Apache) and substitutable cloud services will be required. What do we have in the pipeline to do this?

Adrian



On Mon, Feb 17, 2014 at 1:41 PM, Doc Searls < " target="_blank"> > wrote:
Agreed.

Doc


Hi Graham,
 
Whether you have a right to something and whether and how you choose to exercise that right are two completely different things.  I do not believe Adrian is suggesting that everyone's data practices be defined by the few most demanding patients, nor am I suggesting the same for car data.  What we are saying is that as the car owner or medical device user, we have an inherent right to data that we generate with these personal devices and that we should not be denied access to that data.  In the case of medical devices and probably cars as well, it is possible to design the architecture such that the device/car owner has direct access to that data while still providing the same level of access to other stakeholders as they get today. 
 
The difference is that the current architecture in all these cases is designed on the assumption that the car/device owner's access to the data is at best mediated through a 3rd party, and enforceably non-existent at worst.  This, too, is MORALLY WRONG.
 
Kind regards,
-- T.Rob
 
 
From: Graham Hill [ " style="color:purple;text-decoration:underline" target="_blank">mailto: ] 
Sent: Monday, February 17, 2014 13:12 PM
To: Adrian Gropper
Cc: ProjectVRM list
Subject: Re: [projectvrm] Who owns data generated by 'connected cars' sensor slurpers?… Some Common Sense
 
Hi Adrian
 
Not all chronically-ill patients, (and I assume not all car drivers), want as much control over their data as you seem to do. For example, McColl Kennedy et al in a recent paper on 'Health Care Customer Value Cocreation Practice Styles' (http://www.sdlogic.net/uploads/2/7/3/5/2735531/mccoll-kennedy_et_all__jsr_2012.pdf) identified five different styles of co-creation in cancer patients, ranging from 'passive compliers' who complied with the instructions they were given to the 'team managers' who wanted to organise everything abut their treatment, handling and recovery.. Each patient had a dominant style which they preferred to work within. If they had all been forced to operate as the most active - team managers - the health outcomes for the other four types of patient would have been worse than if allowed to operate under their own preferred style. Interestingly, almost half of the patients were identified as preferring the passive compliant style. 
 
I suggest it is MORALLY WRONG to insist that all drivers be forced to adopt the policies demanded by the most demanding of car-driving data users. Any regulations, codes of behaviour or best practices developed should suit the needs of all drivers, from the most data-demanding to those who couldn't give a tinker's cuss! It would be a criminal shame if the medical needs of an unconscious driver lying in a car wreck were to be overruled by an over-zealously constructed data usage agreement that required active consent from the dying driver.
 
Common sense would dictate that we put the VRM ideology to one side and work on a pragmatic set of best practices that are in the interests of ALL DRIVERS, not just of a few obsessive zealots. Thankfully, automobile telematics should be a whole lot simpler than oncology treatment. That doesn't mean that the same approach couldn't be taken to identify their preferred styles.
 
Best regards from Cologne, Graham
 


Consider the case of connected people. Hugo Campos, for example has an implantable cardiac defibrillator (ICD) that sends his data to Medtronic before it goes to the hospital where it might go to a doctor, and finally, only after years of struggle, Hugo got to see a degraded version of his own data as an off-line file. (Activities that trigger the ICD and the resulting "tuning" are obviously a prime concern for the patient.) Hugo has been very public about this issue. Another ICD patient I advise lost track of her data when she lost her health insurance. The alarms from her device were not being monitored by anyone.
 

From my perspective, "privacy by design" is too vague. The design framework needs to be based on Fair Information Practice. Oversimplified, FIP requires consent, data minimization and transparency. All three criteria, require the patient to have convenient access to the ICD data _before_  it's sent to the vendor or the hospital. Without such access consent is being coerced, data minimization cannot be audited and transparency is more or less absent.

This brings us to the SIM card or the equivalent private key associated with the device. That key needs to be entirely in the control of the patient. In some cases the key may be associated with a certificate. It could be used for ID and encryption (although there's a case to insist the encryption also allow for perfect forward secrecy). In many cases, a trusted certificate is not required.  For my ICD patients, a self-signed certificate and in-person authentication with my physician should be sufficient.

Adrian

 

 

That would be MUCH appreciated, Graham!  I'm curious to hear their take.  Some folks from a different German auto maker scheduled 30  minutes with me 2 years back at IMPACT.  The security discussion took about 20 minutes and I spent the remaining time talking about all the data issues.  We ended up running way over and having lunch together because the data discussion was way more interesting than the back-end security discussion we'd planned.  (Because it was in my role as an IBM product manager I can't provide the name.)
 
Kind regards,
-- T.Rob
 
T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB
 
From: Graham Hill [mailto: " style="color:purple;text-decoration:underline" target="_blank"> ] 
Sent: Monday, February 17, 2014 9:56 AM
To: T.Rob
Cc:  " style="color:purple;text-decoration:underline" target="_blank">
Subject: Re: [projectvrm] Who owns data generated by 'connected cars' sensor slurpers?
 
Hi T.Rob
 
I have lunch with the head of Toyota Deutschland's legal team in a couple of weeks time. I have already let him know that this is a topic we should cover over the fish and chardonnay. I will let you know what his legal opinion is.
 
Best regards from Cologne, Graham
 

 

An analysis under German law as to who can and should own data from a connected car, implications of sharing with 3rdparties, and a call for Privacy by Design.
 
 
Kind regards,
-- T.Rob
 
T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB
 
 
 



-- 
Adrian Gropper MD
 




--
Adrian Gropper MD


Archive powered by MHonArc 2.6.19.