[nsainaney]

Because of licensing and other issues, we aren't certain yet if we can make the firmware of the mojio open source. You can totally write your own apps against our cloud api. This is to abstract away vehicle idiosyncrasies from app developers. That said, we do want more savvy OBD experts to contribute to mojio.

As for your data, you can wipe your data from the mojio servers at any time. Only you can see the data and choose which apps get to see it.

[zx2c4]

> we aren't certain yet if we can make the firmware of the mojio open source

Please do let me know when you find out. This is a very important factor for me and many others.

> You can totally write your own apps against our cloud api.

I think you might have overlooked the primary point of the post. Many folks don't want and don't trust the cloud. My coordinates, travel history, and vehicle information are my business and are not to be stored in the cloud.

> As for your data, you can wipe your data from the mojio servers at any time.

Except law enforcement.

> Only you can see the data

Except law enforcement. Except hackers. Except the other guy's insurance company's subpoena after an accident. And also, the point about remotely reprogramming the device to reflash my car firmware...

The point is -- many folks don't want to plug their car into cloud services.

> we do want more savvy OBD experts to contribute to mojio.

This is a difficult request when the platform is possibly going to be closed-source. Make it an open project, feel better when you receive funding for an open source project, and fuel good community innovation. Keeping it a closed "cloud api" platform stifles this. By the way, having an API doesn't mean things are "open", for whatever that word is worth now a days.

Anyway, I'd be interested to hear your plans for JTAG/serial headers, if you're going to be keeping the firmware closed-source.

[charlesfracchia]

I agree with zx2c4 whole-heartedly!

The main issue you are going to have is security. I can't see any evidence on your website or video that you have thought about this aspect.

The combination of a closed-source solution, cloud-connectivity and connecting to the car through OBD-II seems the wrong approach to me.

Closed-source has been the pitfall of many companies in the past because fewer people get to examine the proposed solution and thus much more prone to security implementation errors.

Cloud-connectivity is the heart of what zx2c4 was talking about.

As for the OBD-II port, what you tout as an advantage in your video is actually a disadvantage. First because since 1995, the internet connectivity landscape has changed dramatically, and security strategies have had to adapt. In fact, often struggling to keep up. This means that the OBDII port was never designed with internet connectivity in mind. This is not a commercial advantage but a security concern! Examples like CarShark (http://www.popsci.com/cars/article/2010-05/researchers-hack-...) or the recent string of thefts made easier through the use of the OBD2 (http://jalopnik.com/5923802/watch-hackers-steal-a-bmw-in-thr...) port are proof that the port is not a good candidate for wider connectivity.

In environments where security matters tremendously like nuclear power plants, a core strategy seems to be limiting capabilities in hardware. The OBDII port does not follow that spec as far as I am aware. The communication scheme allows you to do bidirectional communication. This means that if a 0-day vulnerability was found in your system (closed-source only makes this more difficult to patch), attackers could use your infrastructure to write data to the car such as programming in new keys (like the BWM attack). So it seems to me that you would need a hardware-enforced read only port which doesn't exist. Incidentally that is fundamentally the reason behind some car manufacturers ensuring that their entertainment systems (with BT connectivity etc) are fully separate from the car main computer (whose traditional access port is the OBDII).

As we have discussed, even just collecting said data and storing it in the cloud is undesirable outcome for the driver (your customer in theory...).

This is only my 2 cents, I hope it helps you understand why I think this implementation is not a desirable solution and ultimately why I won't be backing this project despite. Don't get me wrong, just like many folks here, I would love to have a JTAG to poke around and make some cool toy applications but I will never use this as you intended it and plug it into a car.

[nsainaney]

Hi charlesfracchia, Nobody wants their driving information openly available to the world - neither do we so yes, we have thought about security.

The OBD protocols do not address security and have been hacked but the moj.io does not expose the OBD protocols to the Internet. moj.io communicates to the moj.io cloud over an encrypted VPN.

When you receive a moj.io, you have to pair it to your moj.io account. To do this, you require the serial number of the device and a secret PIN (which you can change and never share). No one has access to your data unless you explicitly grant access (e.g. service garage, insurance company, family member etc.). You also see who is checking you out (once you grant them access)