This is quite an interesting discussion about things I hadn't considered.
I thought I'd describe how my hypothetical device might behave in these
situations. It is typically built of components that I'm familiar with,
and could build today if I wanted. I seem to use Linux for everything, and
spend a lot of time logging into work from home, and home from work, so
my device fits into that environment. Using off-the-shelf components,
it consists of a laptop, a cellphone, wireless modem, and GPS set with
NMEA connection. Or a device like a Blackberry PDA, which I'm told has an
API to obtain its location from the network provider. The GPS receiver
and wireless connection may be inside the laptop on PCMCIA cards. The
laptop (or future multifunction device) is running a multiuser operating
system with authentication and remote access mechanisms.
On Thu, 19 Jul 2001, Alex WANG JiaYi wrote:
> The user wants to find his own location.
The GPS receiver sends location information to the laptop, which displays
it to the user. No other agency is involved.
>
> Things become more complicated when more than one user is involved. Say
> parent wants to know whereabouts of his/her daughter.
Push: At regular intervals, or when the location changes, the daughter's
device sends a message containing the location to the parent. This might
take the form of a public-key encrypted mail message, or the daughter
might have an account on the parent's computer with a trust relationship
established with a cryptographic key. The location could then be written
into a file to which the parent has read access, e.g. with SSH.
Pull: The parent has an account on the daughter's device, which has read
access to the position data. When the parent wants to know the location,
they connect to the daughter's device using SSH and read it.
(currently, as it happens, my daughter has an account on my computer and
she has an account on mine. In view of her age & level of computing
knowledge, I am the administrator on both)
> A guy wants to find
> his buddy.
Not so likely that the user would set up normal accounts for all their
buddies.
Push: The user sets up an account on a trusted server, sets up ACL lists,
and pushes location
data to it with SSH or HTTP/SSL. Their buddies authenticate with the
server using SSL certificates from a PKI.
Pull: The user runs a server on their mobile device, and their buddies
authenticate and connect directly
>Boss wants to know the location of his/her employee.
> For example, an
> employee agrees that his boss can locate him from 9am to 6pm, Monday
> to Friday. But somehow on one Thursday, the employee is allowed to
> knock off at 3pm.
Push: The user pushes location data to the employer's server when they are
working.
Pull: The employer's authentication on the user's device is time-dependant
(this feature is standard on Linux/Unix but I've never used it)
I think this arrangement is likely to go wrong, for human reasons. The
user will forget to change things when they knock off. Maybe the user has
one device that belongs to the employer, which stays at work, and one
which belongs to them. Hmm, if the user is a traveller or driver who works
from home, that wouldn't work.
The "buddy list" seems the most difficult problem. It's not like a group
with a single access control, because you don't trust everyone equally
and you probably don't trust the buddy of your buddy. So it needs some way
to reliably authenticate everyone separately without getting so
complicated that noone will use it. I *think* SSL certificates can handle
this kind of thing, though I haven't tried to set it up. I think one of my
utility companies (electric) tried doing this - set up a CA, then get
customers who wanted online account access to download and install a cert
into their browser - but that was a couple of years back when people were
a bit less experienced with eCommerce etc. and I think it wasn't popular.
The ASP in this case knows everyone's location and name, because real
names are probably required to get a cert from the PKI. THis may not be a
problem - people seem willing to trust their sexual preferences to a
webserver or instant messanging service. Hm; but that's not using real
names. Maybe we need an anonymous PKI.
Andrew Daviel
Vancouver Webpages
Received on Sat Jul 21 05:49:19 2001
This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:22 EST