Sounds awesome, right?
You were waiting for the “but”?
They collect an email address. That’s it.
They use it to communicate with you and provide the service. That’s it.
- Mix Panel
- Cloud Flare
What the hell were GeniCan thinking?
Of course, I’m a glutton for punishment so I kept drilling down.
From time to time, CloudFlare may notify you about an offer from one of our promotional partners (e.g., Apps Marketplace partners) via our website or email. While we may target particular types of users for these offers, we will do all of the targeting within our system. Our business partners will not have any access to the targeting information, including the names of the people who may be interested in a particular product or service. Until you affirmatively respond to a promotional offer, we will not reveal any identifying information about you to any of these partners.
If you install an App from one of our third party partners, CloudFlare may provide your email address to that partner for account creation and communication with that partner.
Note that in both cases, these partners may have their own Privacy Policies and may not be covered by CloudFlare’s policy.
…we will post changes on this website along with the effective date of those changes.
OK, I’ll bite. Here’s the text from http://mixpanel.com/terms
We may make changes to these Terms from time to time. When we do, we will revise the “last updated” date given above. It is your responsibility to review these Terms frequently and to remain informed of any changes to them. The then-current version of these Terms will supersede all earlier versions. You agree that your continued use of our Services after such changes have been published to our Services will constitute your acceptance of such revised Terms. These Terms contain the entire understanding of the parties on the subject matter hereof.
To track opt-outs we use a persistent opt-out cookie placed on your Users’ devices. Our opt-out cookies will not stop you from sending other data about that user from your servers to Mixpanel, nor will it prevent any other data collection methods.
This one is basically summed up as “we own your ass” but there were surprises nonetheless. Such as that Google sells the ability for business partners to place their own cookies using Google’s servers. That makes sense. If 3rd party cookies are blocked, just simulate 1st party cookies and pass them back and forth between the back end servers of the various collaborating companies.
Say…I wonder if this approach is also used to work around scripting’s “same origin policy”? No, don’t go there. Do NOT go there. Some things you do NOT want to know.
I just wanted an instrumented waste stream, for Grid’s sake! For that I was willing to drop some money on the crowdfunding campaign and test the web site’s security and account recovery like I normally do. And, as usual, I fully expect to find a device I would not put n my home network and a service I would not entrust with my data. Who knows, perhaps this is the time I’ll be surprised by a truly user-centric data model and privacy-by-design architecture. Hey, don’t laugh. It could happen.
We collect an email address. That’s it.
We use it to communicate with you and provide the service. That’s it.
I repeat: GeniCan, what were you thinking?
Herd of elephants in the room
At that time I’ll be curious whether the UPS code on a can of beans is considered PII. It will be correlated to an email address, correspond to the line-item purchases at the grocer grocer, and can be thus correlated to credit card, address, name and so forth. Your unique fingerprint of purchases is as unique, probably more so, than your actual fingerprint and the definition of “personally identifiable” includes identity derivation through correlation. At this point, the line that defines what is and isn’t personally identifiable is simply the break-even point of cost versus value. Given enough value or sufficient funding, it’s pretty much all personally identifiable. So where do you draw the line? More importantly, where does GeniCan draw the line?
The VRM Version
There is a possible version of this device that I’d actually use. It would be the one with the VRM-y, personal cloud architecture. How does that work? Same architecture I described in San Francisco:
- The device emits signed data over pub/sub so that secondary and tertiary recipients of data can trust it.
- By default, the device talks to the vendor’s service so users don’t need any other service or device to make it work.
- The device can be configured to talk to a service of the user’s choosing instead of, or in addition to that of the manufacturer.
- The device API is open.
I hope GeniCan goes down that road. Given the IoT track record so far though, I’m not holding my breath. No matter how pure the intent of the founders, all the devices I’ve looked into so far easily qualify as surveillance data portals designed for deployment inside boundary of the last private domain you have left on Earth – your home.
Assuming the current IoT architecture, by the time you deploy half a dozen wearables, instrument your switches and thermostats, receive the smart meters from your utilities, buy a smart TV that reports on your watching habits, switch your music to Pandora or Spotify, move your library to Kindle, and instrument your appliances and trash can, will you really be able to look a judge in the eye and claim with a straight face that you had any expectation of privacy in your own home?
If the devices use a VRM/Personal Cloud/Privacy By Design architecture, the answer is “yes.” This is the IoT 2.0 architecture and when the time comes that you can choose between this and the current IoT 1.0 spyware, which will you choose? What will happen to all your IoT 1.0 devices and subscriptions when an IoT 2.0 replacement is available?
Vendors would do well to consider their customers’ answers to these questions and plan accordingly. Don’t mess about with the butterflies and daffodils that are IoT 1.0. Start with IoT 2.0 and lasers. Eight o’ clock. Day one.