[projectvrm] Re: Fuse, Carvoyant and Things

["Phillip J. Windley Ph.D." < >]

Adrian,

Thanks for the note and the discussion. This is helpful and is why I’m interested in Fuse: it’s a chance to experiment with some of this and see what works and what doesn’t. 

Your split into device aggregators (DA) and virtual agent aggregators (VAA) is a good one (there are numerous names for the VAA business, but let’s stick with that for now). 

You may have picked up that Fuse is a name specifically chosen to emphasize the VAA business model and not the connected-car specifically. My vision is that Fuse could serve as a personal aggregation point for any connected thing and even things that aren't connected, but need an online presence (SquareTag was our first experiment in that area). Fuse is designed to be used from multiple hosting providers. Neustar, for example, could provide Fuse hosting services. I'm working now on self hosting so that people don't even have to trust a hosting company if they don't want to. 

The chief problem, of course, is that everyone wants to be in the VAA business because selling devices is so 20th century. Specifically Carvoyant’s roadmap, so far as I understand it, puts Carvoyant and Fuse on a business model collision path. 

Having said that, the business model clash is a long term problem.  We chose Carvoyant because they were a good match philosophically. I don't think Bret Tobey (CEO) is on this list, so I'm cc'ing him.  They used to have a privacy policy, not sure what happened. Carvoyant has also been a great technical partner who is willing to work with us on our needs. 

Adrian points out a big factor in the device aggregator side: encryption. Carvoyant has a (good) API and it's made my life easier.  That means, however that they also hold the data. Because they want to attract you to use their API with various apps, that's critical to their business model.  There's no reason why someone couldn't be in the business of offering the devices, a cellular to Internet gateway, firmware programming, streaming API, etc. as a business, but it's likely low-margin, high-volume. Every telco is fighting to get out of that space. 

As for labeling the device, we made it a Fuse device because no one understands any other model. They expect a silo. Would that they did not. :) On the other hand, I chose, later in the game than when I printed the device labels--I was writing code at this point, to make the Carvoyant relationship explicit because doing otherwise would lead to people having an account they don't know they have, an untenable situation in my opinion. 

My medium term goal (longer than a few weeks, shorter than a year) is to integrate the Automatic API for a few reasons:

1. That will illustrate better than any thing else that Fuse is about the data and using it, not the device.

2. That will force me to root out some assumptions in the code I'm sure are there relating to Carvoyant, try as I may to avoid them. 

3. That will make it more clear why there's a need to link to Carvoyant, Automatic, etc. because Fuse won't be anymore about the device itself. 

4. That will make it so that there was no "Fuse" device necessary.  Just Carvoyant, Automatic, and any other device that comes along with a usable API. 

I'm open to others participating in building that. In fact, I'd welcome it. There's plenty to do to build out this vision.  All the code is open source. 

I believe we have a good model and architecture. We've tried to make it private by design, although I'm sure there are places we could improve. One of the side affects of PbD is that I think, done right, it also leads to greater flexibility.  

For example, this week, I had a Fuse owner who wanted to have a vehicle in more than one fleet (so one of his clients could track just that vehicle without seeing his other 8 vehicles). Because of the pico architecture, that vehicle is isolated and it's relatively easy to create a relationship between it and the client's fleet in addition to the owner's fleet without additional programming.  The ability to parse and use multiple relationships is built into the underlying structure. 

In summary, Adrian has hit on a critical question for the Internet of Things. How will we split the silo so that we are free to use our devices with the data aggregator of our choice? I see Fuse as an experiment in answering that exact question.  

On Jan 4, 2015, at 1:44 PM, Adrian Gropper < "> > wrote:

I finally activated my Fuse and read some of the posts on the Forum. This is a pioneering effort in IoT in a number of ways and worthy of support and consideration.

The post http://www.windley.com/archives/2014/12/fuse_kynetx_and_carvoyant.shtml clearly explains a vision for IoT based on two related aggregator businesses: a device aggregator like Carvoyant and a virtual agent aggregator like Kynetx. Having two cooperating businesses is what makes the Fuse VRM example interesting.

As I see it from a privacy engineering perspective, the device aggregator business (Carvoyant) should have as little to do with people as possible. The virtual agent business (Kynetx) should have as much to do with people as possible. To the extent that both businesses attempt to serve both devices and people, confusion and privacy issues ensue.

In the Fuse example, confusion abounds. As Phil puts it: "Indeed this has been the source of 90% of the support issues I deal with."

Confusion starts with the car API device being labeled Fuse instead of Carvoyant. As far as I can tell, neither Fuse or Kynetx has any control over the device firmware or policies, including privacy policies, of Carvoyant. I could not find any privacy policy on https://www.carvoyant.com/

A business that sells data to other businesses and has no visible privacy policy is what I call a data broker. Carvoyant is better than most data brokers in that they provide me with a login so I can see what they know about me, but this is little solace. Here's an unregulated broker that effectively monitors my whereabouts and presents no privacy policy. Who would knowingly agree to that?

How do we fix this? It probably starts with encrypting the data that leaves my car API with a key that Carvoyant doesn't have. That would take both Carvoyant and some of the cell provider (they can track my car _and_ me in the Fuse setup) out of the picture. The cell provider is regulated so their need for a visible privacy policy is much less than the other businesses in this Fuse story.

Unfortunately, the data broker's business model will not survive encryption. They need the plaintext data to provide the data cleaning services that Fuse needs to keep development costs in check. If all Fuse needed was a $1/mo cellular car API they could buy that directly from the regulated cell service provider.

I want to support Kynetx. I need to support at least one regulated telecom service provider. Is the data broker business model just a transitional artifact of this particular era in the Internet age?

Adrian

--

Adrian Gropper MD
Ensure Health Information Privacy. Support Patient Privacy Rights.
http://patientprivacyrights.org/donate-2/