Nov

21

Here I am, right here

18 years ago, mid-November | 7 Comments

Some time ago I wrote what I called the “Ramius” edition of my tracker application for the TomTom Go. The limitations of the Go SDK caused more than its fair share of grief and I shelved the project, hoping to revive it later. Now I’m thinking that it’s time to bring it back to life.

At the moment I’m selling my house in The Netherlands and moving back to the UK. Until the house sells I flit between the UK and Holland every couple of weeks. I’ve taken to using the Chunnel for this because it means I can drive through the night rather than have to bend to the ferry or flight schedules. The trouble is, my wife gets worried that I’m going to crash and burn. She does this every time I do the trip, in either direction. She wont go to bed until she knows that I’ve at least got to the Tunnel.

I brought the original code out of my archive and started looking at it, removing anything that was TomTom specific. I’m pretty sure that I’ll have a workable solution fairly soon, I may butcher the openmoko-agpsui2 application a bit too, just to add a face to the tracker application code. Obviously, it will need a network connection of some sort so I’ll be looking at starting and stopping a gprs connection, or using wifi when the GTA02 arrives.

On the topic of gprs and network connections, I was mulling over some points in my mind about this. Nobody wants their Neo to pull an iPhone, and give us all large bills because of roaming, so there needs to be some mechanism where the user can deny or allow access to things like gprs connections. These could be based on dates, times, even locations with the built in gps. The problem is not that it is difficult to do, the problem is that we need to be able to force applications to use an API to open gprs and wifi conections, and possibly even access the gps. There’s a whole kettle of fish here. Openmoko is opensource, not the Google kind of ‘opensouce’, the real kind. That in itself poses a few questions and perhaps some not so nice answers.

If we want to force people to use an API, then we have to make sure that they can only use the API and not bypass it. If they can bypass it, it’s useless because the malicious ‘l33t h4x0r’ is going to abuse your connection. The problem is, since we are opensource, the same abuser can simply replace the API. Sure you still have to install the application, but just think about it. Right now how many places do you update your Neo from with ipkg? If any one of those gets compromised or the owner deliberately alters packages, the first you’ll know of it is when you bill hits the mat with a thud rather than the usual ‘ftht’.

We can think about signed images or signed packages etc but that is not really going to help, this is opensource. As an application developer I’m going to want to publish applications, I don’t really want to have to get them certified or signed by someone else just so other people can use them. If you alert the user that an application or package is not signed, you know that they’ll just click ‘ok install it anyway’ and ignore it.

I think I’m going to have to ponder this one a little longer.

_{»crosslinked«}

Tagged with: api • google • gprs • neo 1973 • openmoko • opensource • tracking
November 21, 2007 14:49

Comments

7 Comments so far

diego on November 26, 2007 14:37
What about having different software running with different user?

You can have “normal software” that run under unprivileged software. Or you can have software that run with special user, so you can access to gsm or gps hardware.

When you install the software, you should get neo asking you if you want install it as “normal app”, “gsm app” or “gsp app”. And the software will be executed with the right (unix) user.

In this way the kernel itself block unauthorized access to the hardware.

Of course there is always a way to persuade the user to install malicius code as priviledged user (install this new dialer, and you get free call!). But at least the user have a change to think what is going to do…
Erland Lewin on November 26, 2007 16:56
I don’t see the problem with GPRS. Just take the interface down, there won’t a be a route in the routing table, and no program without superuser rights will be able to talk GPRS.
Alex Hortin on November 26, 2007 18:47
interesting, but I think that linux users are well aware of running code that will do something malicious to their system. How many new users ever run someone else’s shell script that is disguised as a legit program that just “rm -rf /”?

I am not too concerned, but it is a really interesting question, and since phone bills are already large enough, its good to see at least someone on the team considering it
ekspiulo on November 26, 2007 19:05
To address the philosophical problem of connecting open source software with a billing contract, it is in the nature of open source software that the most you can realistically, as a developer, protect the user from themselves is by providing them with all the information they need to make their own decisions, but this can be accomplished in more ways than a pop-up dialog.
In the open source world all the various types of user must be constantly accommodated or one of them will change the code for their own benefit. Security lies in a design that doesn’t incite the typical self interested developer to change it. In other words, a secure design that open source developers won’t like isn’t good security. Maybe the best system is a community driven approach to security as well as development. A centralized form of application peer review (website) and a system in place on the phone to alert the user to the “reviews” of a package they’re installing and to warn them if they installing a something that doesn’t provide the proper information about itself to be looked up on the community review website or what-have-you.
Lars Hallberg on November 27, 2007 22:53
Dbus was more or less invented for this. Let the ‘system’ talk to the user. So apps can just ask for the stuff they want (net connection, phone call etc). The system evaluate it (the phone app, ok allow dialing).

If you on Your operators net with flat rate, allow almost anything, if You on pay $/mb allow almost nothing. With help of fw the system should be able to disallow new connections even if the network is up.

When needed, the system ask the user, if any software ask for something they not allowed to i advance, or use too much bandwidth in pay $/mb mode.

Then nothing run as an unprivileged user should be able to do to much bad things. But ipkg is a problem… ipkg must run as root, to install binarys as root (so no other app running as root can manipulate apps that is granted some privilege), but for most app they need only run as unprivileged user. But installing a package will let the script in the package run as root – putting the system at risk.

This is ok for the ‘core’ system, it can be handled by controlled source, signatures etc. But something must be done for 3:d part apps.

Wrote about this a while back… but probably too early:

http://lists.openmoko.org/pipermail/openmoko-devel/2007-March/000695.html
Joshua Layne on December 6, 2007 02:29
The policy versus religon issue (OSS versus M$ or AppHell) shows up a lot and is likely one of the major resons behind lack of FOSS adoption by ‘simple users’. I would love a highly configurable network manager that included gprs (and others) – I don’t believe gnome’s network manager does. I think if done properly, people (and projects/distros) will use it. After that, you have to rely somewhat on user intelligence – the app is replacig my network manager?! maybe that isn’t such a good thing…

I would also love to see the location aware app – any chance of a maemo port?
TrackMe on the Neo : ..the cat came back.. on January 23, 2008 14:53
[…] Here I am, right here […]

Current Electricity Use (15min)

iPhone/Webkit RSS Reader

Twitpic

Graphy Stuff

Nasty Spam Monkeys

56,871

Recently Written

Categories

Archives

Admin

Search

Nov

21