I could do mailling list moderator I already am in front of a computer all day, I could keep an eye on a moderation page :p.
-- Perrito. 2007/11/15, Daniel Drake <[EMAIL PROTECTED]>: > Hi! > > As I've mentioned in a few places, I've been cracking away on a new > project over the last couple of months. It's now open to the public. The > project is called "fprint" and its homepage is here: > > http://www.reactivated.net/fprint > > It's a wiki, but registration is not open to the public. I will > gratefully give out accounts to those who request them (just choose a > username) and I'm also looking for people to help admin it. > > I'm doing fprint as an academic project (3rd year Computer Science at > the University of Manchester, UK). I've been planning it as an open > source project from the start, however, being an academic project I felt > it necessary to implement the fundamentals myself, so I held off on > making it public until I had reached a few early milestones. Sorry about > that - I know that I get a little frustrated when I see people not > making their work public from early on. > > The academic project is ongoing, but I'm now able to run it as an open > source project in the normal way -- contributions encouraged and > reasonable ones accepted! Despite my earlier secrecy, I am very > interested in building a community, gaining adoptance, and hopefully > getting shipped by distributions. > > The objective of my project is both simple and broad: get consumer > fingerprint scanning hardware usable on Linux. "usable" means that the > software actually processes and interprets fingerprints, not just saving > them as images. "usable" means that there is actually software which > uses fingerprint readers in a sensible fashion, and that users don't > have to download obscure package Y and compile it themselves, then come > up with some obscure way of integrating it into their workflow. > > How do we approach this problem? The first thing I want to do is make it > easy for application developers to add support for fingerprinting to > their software. Once application developers can easily add > fingerprinting support to their projects, they can make it easy for > users to use their consumer fingerprint scanning hardware. > > Requirements for making it easy for application developers to support > fingerprinting include: > - Application developers should not care which type of fingerprint > scanner the user has plugged in. > - Application developers should not care that device A is an imaging > device whereas device B does image processing in hardware. > - Application developers should not have to write extra code to > support another fingerprint scanner product. > > So that leads me to the core component of the project: libfprint > libfprint is a library aimed to make it easy for application developers > to do stuff with fingerprint readers. That includes image retrieval, but > also includes finger enrollment, finger verification, storage of > fingerprint data, etc. > At the outset, it generalises all fingerprint scanners into a single > model, and provides an API to manipulate fingerprint readers through > that model. Internally, it includes several drivers to drive different > types of hardware, and a few abstraction layers to hide the vast > differences between these different device types. > > Another aim of libfprint is to support a lot of hardware. After all, > it's not easy to use your fingerprint scanner if it's not supported :) > libfprint defines an "internal API" for drivers, and another objective > is therefore to make it easy to write drivers. All current drivers are > quite small. > > My project also includes working to get libfprint integrated with > existing systems. > > The second component I have developed is called pam_fprint. As you might > guess, it is a PAM module which simply calls a few functions in > libfprint in order to make it possible for you to login to your computer > using your fingerprint rather than a password. pam_fprint is a > proof-of-concept at the moment, but it works. pam_fprint is naturally > driver-agnostic, hardware-agnostic, supports all the hardware that > libfprint supports, and was quite easy to write. > > Some of the devices that libfprint supports are imaging devices, but we > obviously need to be able to process these images to decide if we can > log the user in or not. libfprint handles this internally, it uses > NIST's NBIS code. NBIS caused us some headaches before because NIST > indicate it is export-controlled from the US, however I have determined > that in the context of this project, there are no restrictions. See the > wiki for more details. > > libfprint currently includes 4 drivers: > 1. uru4000 - DigitalPersona U.are.U 4000/4000B > This is based on libdpfp. It supports the Microsoft and DigitalPersona > devices. As we know, these devices simply send images to the host computer. > > 2. upekts - UPEK TouchStrip > This is based on code from thinkfinger and should support all the same > devices. This device does not provide any images, it does image > processing in hardware and gives a boolean result - "match" or "no > match". Despite this device being vastly different from the others, > libfprint abstracts the differences away and provides the same API to > applications (except the image retrieval parts obviously do not work). > > 3. aes4000 - Authentec AES4000 > Another imaging device that uses active capacitance. > > 4. aes2501 - Authentec AES2501 > Another imaging device, active capacitance, swipe-type. > > In terms of being able to login with your finger, uru4000 and upekts are > working almost perfectly. aes2501 works quite well, but works best if > you practice your scanning technique, and aes4000 works if you are > careful about always placing approximately the same part of the finger > on the sensor. There is work that can be done to improve imaging > performance on all 3 of the imaging devices. > > In terms of accuracy, I have yet to see a false acceptance (i.e. scanned > finger doesn't match the original, but computer says it does). On the > AES2501 and AES4000 devices, false rejections (scanned finger does > match, but computer says it doesn't) are quite common until you've got a > good scanning technique. It's quite hard to get a false rejection for > the DP/MS devices unless you are especially trying (finger significantly > rotated, etc). > > I believe that fprint is the first open source project to offer the > capability of using the DigitalPersona/AES2501/AES4000 readers to the > point where you can login with your fingerprint. > > That said, it's a young project, there is plenty to do, and there will > be bugs. The code is all in git repositories but I have made initial > releases (no stability or forwards-compatibility guarantees!). I have > spent quite a bit of time putting content on the website, so I hope that > answers many of the initial questions. > > The website is here: > http://www.reactivated.net/fprint/ > > Please use the mailing list for questions, support requests, and > development. Please don't email me directly without good reason - I > might ignore your email. > > I'm hoping to get people involved with the project, not only development > - there are some admin tasks too. > http://www.reactivated.net/fprint/wiki/Project_needs > Also, I went a little out of pocket purchasing devices for the project, > and would very much appreciate any donations there (or alternatively, > donations solely for future purchases etc). > http://www.reactivated.net/fprint/wiki/Donations > > Quick thankyous to people who have recently been helpful with > relicensing existing driver code etc: Cyrille Bagard, Timo Hoenig, > Vasily Khoruzhick, Pavel Machek. > > Thanks and enjoy! > Daniel > _______________________________________________ > fprint mailing list > [email protected] > http://lists.reactivated.net/mailman/listinfo/fprint > _______________________________________________ fprint mailing list [email protected] http://lists.reactivated.net/mailman/listinfo/fprint
