On Tue, 2008-04-15 at 14:36 +1000, Sridhar Dhanapalan wrote: > On 15/04/2008, Robert Collins <[EMAIL PROTECTED]> wrote: > > On Tue, 2008-04-15 at 14:18 +1000, Martin Visser wrote: > > > Also do they actually need to carry the data with them? It would seem > > > if the ratio of data owners to intelligent devices/readers is so high, > > > you really come back to simply needing a card number ala Medicare - or > > > maybe even something like a "tinyurl" only a little more human > > > rememberable.The client then just needs to recite their number/tinurl. > > > > > > This assumes that the reader device has real-time (or maybe near > > > real-time is good enough, access to the data storage. (And near real > > > -time may be good enough - 1 000 000 users with 10 K data each is > > > "only" 10G - easily replicated on all your reader devices - assuming > > > the data doesn't change all that often. > > > > > > I'm inferring that the scheme being developed is something like the > > following: > > > > * At each village/town there is a single low-capability but functional > > pc. It has no reliable network. > > Not quite. A person will arrive by motorcycle, probably once per week, > with a laptop in tow. They'll have about an hour to sort out the > people there before departing to the next settlement. At the end of > the day/week, they'll return to base and synchronise their laptop with > the central system. > > > * The data owners want to be able to track e.g. taxes, accounts, small > > personal data. > > Mostly simple financial data, like a passbook. > > > * They want to be able to use this data where *they* are, not where a > > specific reader device is. > > As mentioned above, the reader comes to them. > > As mentioned previously, this is for the developing world. The current > system is very manual: paper and pen. It's very laborious, and open to > errors and even fraud. We're looking for a simple and reliable digital > replacement.
Martin's point then about just storing the data in the reader makes a lot of sense to me. Give each data owner their own password. You could even use a crypted loopback fs for each 'account' so that they have their own encrypted audit trail which can be used to double check the central records in the case of suspected fraud. -Rob -- GPG key available at: <http://www.robertcollins.net/keys.txt>.
signature.asc
Description: This is a digitally signed message part
-- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
